Presentando CRUST

agosto 26th, 2018

Acabo de lanzar CRUST. Se trata de un analizador estático de C que permite disponer en C de una gestión de memoria similar a la de RUST.

Y es que RUST está de moda, pues al ofrecer seguridad en el acceso a memoria dinámica pero sin necesidad de un runtime (como un recolector de basura) o de otras técnicas (como el conteo de referencias), permite exprimir al máximo el rendimiento. El problema es que RUST es un lenguaje nuevo, con su sintaxis propia (que, además, diverge de la de C u otros lenguajes bastante), y que, por tanto, tiene una curva de aprendizaje.

Por otro lado, existen casos en los que no se puede utilizar (todavía) RUST, como el de un microcontrolador PIC, Atmel…, pues hace falta un compilador específico. En otros microcontroladores, como los basados en ARM, es posible utilizarlo, pero sigue teniendo el problema de que no es un compilador oficial, y por tanto hay que hacer algún que otro malabar para integrarlo en la toolchain del fabricante.

Es aquí donde CRUST hace su aparición: como ya dije se trata de un analizador estático de C que permite disponer de (más o menos, claro) las mismas comprobaciones de seguridad que ofrece RUST para la gestión de memoria dinámica, de manera que es más difícil que un programa sufra referencias colgantes o dangling pointers, o pérdidas de memoria.

A la hora de diseñar CRUST tenía una cosa muy clara en mente: no podía crear un nuevo lenguaje parecido a C, sino que tenía que seguir siendo C puro, compilable con absolutamente cualquier compilador estándar. Eso eliminaba cualquier tipo de preprocesador del estilo de Metaobject o similares. También suponía rechazar cualquier tipo de conjunto de macros que pudiese alterar el código de la más mínima manera. Y por supuesto, el uso de bibliotecas estaba completamente descartado.

La solución consistió en crear una serie de calificadores específicos, similares en funcionamiento a los calificadores volatile o const ya disponibles en C, que permitan al analizador saber si un puntero concreto es gestionado o no-gestionado, así como otras propiedades importantes para el analizador. Estos calificadores comienzan todos con el prefijo __crust_ para evitar interferencias con nombres de variables o futuras adiciones al lenguaje C. La clave de estos calificadores es que no son necesarios en absoluto para compilar el código.

Por supuesto, ningún compilador aceptaría un código con dichos calificadores, y por eso es necesario incluir un fichero de cabecera (que se incluye con el analizador estático) que define dichos nuevos calificadores como espacios en blanco para el preprocesador de C. De esta manera, a la hora de compilar estos calificadores simplemente “desaparecen”, y sólo son tenidos en cuenta cuando se utiliza el analizador. Este es un trozo de dicho fichero de cabecera, para que se entienda mejor:

#ifndef ENABLE_CRUST_TAGS

#ifndef __crust__
#define __crust__
#endif

#ifndef __crust_borrow__
#define __crust_borrow__
#endif

#ifndef __crust_recycle__
#define __crust_recycle__
#endif

#ifndef __crust_alias__
#define __crust_alias__
#endif

#ifndef __crust_no_0__
#define __crust_no_0__
#endif

...

Como se ve, se define cada posible calificador como una cadena vacía, lo que hace que el preprocesador se encargue de limpiar el código y dejarlo listo para el compilador, sin necesidad de modificar nada. Esto permite programar como de costumbre, simplemente etiquetando aquellos punteros que deben ser gestionados como un bloque CRUST, y compilando el código normalmente con el toolchain habitual, y sólo de vez en cuando pasar el analizador estático para comprobar si hemos cometido algún error al liberar o utilizar uno de estos bloques. Por supuesto, no es necesario escribir este fichero a mano, sino que se puede generar automáticamente simplemente llamando al analizador estático con el comando crust –headers, con lo que generará dicho fichero en el directorio actual.

La base de las reglas de gestión de memoria de CRUST (y, por extensión, de RUST) es que cada función es responsable de todos los bloques de memoria que genera o recibe. Así, si una función pide un bloque de memoria dinámica (por ejemplo con malloc), es su responsabilidad liberarlo o asegurarse que sea liberado. Esto puede ocurrir de tres maneras diferentes:

  • Puede liberar el bloque directamente ella misma
  • Puede llamar a otra función pasando dicho bloque como un parámetro, de manera que pase a ser responsabilidad de la nueva función garantizar que se libere dicho bloque
  • Puede devolver el bloque a la función llamante, de manera que ésta recibe la responsabilidad de liberarlo

No hay mucho más. Por supuesto existen, a mayores, otros detalles que hacen que la cosa no sea tan sencilla, por lo que para una explicación más en profundidad recomiendo leer como es el modelo de memoria de RUST.

Un ejemplo sencillo de como trabaja CRUST se puede ver en este trozo de código:

// SIEMPRE añadimos crust.h al principio
// El fichero tiene que estar en el proyecto
#include "crust.h"
#include <unistd.h>

// Definimos una estructura como "gestionada"
// simplemente añadiendo __crust__ a su definición
// Utilizamos un typedef para ahorrarnos tener que poner
// __crust__ en todos los sitios donde se utiliza
typedef __crust__ struct {
	int member;
	int p1;
	int p2;
} *un_tipo_t;

// esta función crea un nuevo bloque "gestionado" y lo devuelve

un_tipo_t funcion1();

// esta función recibe un bloque "gestionado",
// pero no lo libera antes de salir

void funcion2(un_tipo_t __crust_borrow__ parametro);

// esta función recibe un puntero a un bloque "gestionado",
// y además lo libera antes de salir

uint32_t funcion3(un_tipo_t parametro);

void main() {

	un_tipo_t bloque = funcion1();

	funcion2(bloque);
	funcion3(bloque);
}

Aquí vemos varias cosas:

  • Primero hacemos un typedef de un puntero a una estructura, y además incluimos el calificador __crust__. Esto significa que absolutamente cualquier variable de tipo un_tipo_t será gestionada, y por tanto sujeta a las reglas de CRUST.
  • Luego tenemos tres definiciones de funciones que “hacen cosas” con tipos un_tipo_t.
  • Finalmente, tenemos el bloque main. En él creamos un puntero de tipo un_tipo_t y le asignamos el bloque que nos devuelve funcion2.
  • A continuación llamamos con dicho bloque a funcion3. Como dicho parámetro está marcado como __crust_borrow__, sabemos que dicha función nunca liberará dicho bloque, por lo que después de llamarla seguirá estando disponible y podemos seguir utilizándolo.
  • Finalmente llamamos también con dicho bloque a funcion1. Como el parámetro de dicha función no está marcado como __crust_borrow__, sabemos a ciencia cierta que ese bloque que estamos pasando va a ser liberado dentro de ella, por lo que a partir de este punto no podemos volver a utilizarlo.
  • Llegamos al final de la función, y como la variable bloque ya no apunta a nada (pues el bloque fue liberado al llamar a funcion3), no hay riesgo de que tengamos una fuga de memoria.

Este código no devolvería ningún error al pasar por el analizador estático CRUST precisamente porque cumple con precisión las reglas de gestión de memoria. Sin embargo, si hiciésemos un cambio tan sencillo como invertir el orden de las llamadas a funcion2() y funcion3(), obtendríamos un error:

ERROR: Argument 1 when calling function 'funcion2' at line 41 was freed at line 40
Total: 1 errors.

El motivo es que funcion2() libera el bloque de memoria que recibe, lo que significa que cuando llamamos después a funcion3() con él, CRUST sabe que ese bloque de memoria ya no existe, y nos avisa.

Algo similar ocurre si sólo llamamos a funcion2() (que sabemos que no libera el bloque) pero no llamamos a funcion3():

ERROR: Memory block 'bloque', initialized at line 38, is still in use at exit point in line 41
Total: 1 errors.

Aquí CRUST se da cuenta de que el bloque que hemos inicializado no ha sido liberado al llegar al final de la función. Si lo dejásemos así tendríamos una fuga de memoria, y por eso nos avisa diligentemente.

Por supuesto CRUST es lo suficientemente inteligente como para seguir las posibles ramas de ejecución del código. Probemos a modificar la función main() anterior y dejémosla así:

void main() {
	// "tmp" tiene un valor que desconocemos
	uint8_t tmp;

	un_tipo_t bloque = funcion1();

	if (tmp == 5) {
		return;
	}

	if (tmp == 8) {
		bloque = NULL;
	}

	if (tmp == 7) {
		bloque = funcion1();
	}

	if (tmp != 3) {
		funcion3(bloque);
	}
	funcion2(bloque);
}

Al pasar este código a través de CRUST obtenemos el siguiente resultado:

ERROR: Memory block 'bloque', initialized at line 42, is still in use at exit point in line 45
ERROR: Assignment to 'bloque' at line 49, which was already assigned at line 42
ERROR: Argument 1 when calling function 'funcion2' at line 59 was freed at line 57
ERROR: Memory block 'bloque', initialized at line 53, is still in use at exit point in line 60
ERROR: Assignment to 'bloque' at line 53, which was already assigned at line 42
ERROR: Memory block 'bloque', initialized at line 42, is still in use at exit point in line 60
Total: 6 errors.

Aquí nos está avisando de todos los errores que hemos cometido, que son:

  • Si tmp vale 5 saldremos en el return de la primera comparación, con lo que el bloque que inicializamos en la línea 42 no se libera y tendremos una fuga de memoria.
  • Si tmp vale 7 u 8 estaremos sobreescribiendo un puntero que apunta a un bloque válido en la línea 49, con lo que tendremos una fuga de memoria.
  • Si tmp tiene un valor diferente de 3 liberaremos el bloque en la línea 49, con lo que al llamar a funcion2() tendremos una referencia colgante.
  • Si tmp vale 3 todo parecerá funcionar correctamente hasta llegar al final de la función, donde nos encontraremos con que el bloque nunca se libera y tendremos una fuga de memoria. Este error nos aparece dos veces porque en una de las ramas de ejecución no liberamos el bloque recibido al principio (línea 42) y en la otra no liberamos el bloque obtenido cuando tmp vale 7.

Por supuesto, CRUST tiene algunas limitaciones. Por ejemplo, sólo recuerda si una variable es NULL (vale 0) o no (valor distinto de 0), pero no valores concretos. Esto significa que este código será analizado correctamente:

void main() {

	un_tipo_t bloque = funcion1();

	if (bloque != NULL) {
		funcion3(bloque);
		bloque = NULL;
	}

	if (bloque != NULL) {
		funcion2(bloque);
	}
}

CRUST sabe que bloque, tal cual es devuelto por funcion1() puede ser NULL o no NULL, pero cuando llega al primer if y analiza ambas posibles ramas, en la de dentro del if marca a bloque como no NULL, y en la de fuera como NULL. Cuando llama a funcion3() el bloque es liberado, y por eso no devuelve un error al asignar NULL a dicha variable. A partir de aquí ambas ramas de ejecución tienen NULL como valor de bloque, y CRUST es capaz de detectar correctamente que jamás se llamará a funcion2(), y por eso no devuelve ningún error.

Sin embargo, este bloque sí daría errores, pues CRUST no llega a tener un nivel de control tan fino de los valores de las variables:

void main() {

	uint8_t tmp;

	un_tipo_t bloque = funcion1();

	if (tmp == 3) {
		funcion3(bloque);
	}

	if (tmp != 3) {
		funcion2(bloque);
		funcion3(bloque);
	}
}

Este código devolvería estos errores:

ERROR: Argument 1 when calling function 'funcion2' at line 48 was freed at line 44
ERROR: Argument 1 when calling function 'funcion3' at line 49 was freed at line 44
ERROR: Memory block 'bloque', initialized at line 41, is still in use at exit point in line 51
Total: 3 errors.

Por supuesto, la forma correcta de hacer lo anterior sería esta:

void main() {

	uint8_t tmp;

	un_tipo_t bloque = funcion1();

	if (tmp == 3) {
		funcion3(bloque);
	} else {
		funcion2(bloque);
		funcion3(bloque);
	}
}

La cual sí sería analizada correctamente por CRUST.

Todo esto no son más que unas pinceladas, pues hay mucho más en CRUST (por ejemplo el prestamo de bloques, igual que en RUST), por lo que lo mejor es leerse la documentación completa, que viene en formato PDF.

Como de costumbre, se puede encontrar en mi página web y en el respositorio de CRUST en GitLab.

Trust Flex Graphics Tablet

agosto 20th, 2018

El otro día me compré una tableta gráfica Trust Flex Graphics Tablet. No es que suela dibujar a menudo, pero de vez en cuando me gusta hacer alguna cosa, y según qué tareas me dejan la muñeca fatal si las hago con el ratón.

Por desgracia ya al principio empezaron los problemas, pues Linux no me la detectaba. Sin embargo, lo raro era que sí había un dispositivo en /dev/input de la tableta, simplemente no se reconocía como un dispositivo digitalizador.

Empecé a rebuscar y encontré, por fin, gracias a una entrada del gitlab de freedesktop, que el problema se debe a que la tableta no entrega la resolución en unidades físicas; esto es, no se puede saber directamente a cuantos milímetros se corresponde unas coordenadas de posición. La solución consiste en añadir estas líneas en el fichero /etc/udev/hwdb.d/60-evdev.hwdb (creándolo si no existe):

#########################################
# Trust
#########################################

# Trust Flex Graphics Tablet
evdev:input:b0003v2179p0004*
 EVDEV_ABS_00=::234
 EVDEV_ABS_01=::328

Estas líneas añaden la entrada EVDEV_ABS_XX a los datos devueltos por el driver, de manera que libinput puede saber la resolución física de la tableta.

Una vez hecho esto hay que compilar el fichero mediante el comando

sudo udevadm hwdb --update

Y finalmente reiniciar para que el sistema aplique los cambios (sí, es necesario). Una vez hecho esto, la tableta funcionará perfectamente, apareciendo en pantalla un segundo cursor que seguirá al bolígrafo.

Migrado a Gitlab

junio 10th, 2018

Tras la reciente adquisición de Github por parte de Microsoft, tomé la decisión de migrar todo a Gitlab, así que si tenías algún enlace a mis repositorios, adáptalo a la nueva dirección.

Cronopete 4

abril 28th, 2018

Acabo de lanzar una nueva versión de Cronopete, la 4.0. Se trata de una versión con muchos cambios internos, aunque externamente puede parecer muy similar.

El primer gran cambio es que ahora tiene un sistema de backends para hacer los backups. Esto era algo que estaba medio hecho desde la primera versión, pero el problema es que, sencillamente, estaba mal hecho: los backends de las versiones viejas sólo daban acceso a un disco, mientras que la lógica de las copias de seguridad estaba por encima. Esto limitaba mucho, porque exigía que donde se hiciesen los backups soportase enlaces a archivo y otras cosas. El nuevo sistema de backend, en cambio, asume completamente TODO el proceso de copia de seguridad; básicamente, cronopete le dice al backend: “quiero que me copies estas carpetas”, o “dame la lista de backups que tienes”, o ” recupera este fichero desde este backup”. Pero no le interesa COMO está hecho el backup. Eso es tarea de cada backend.

Por supuesto es fundamental conservar el sistema viejo de copias de seguridad, por lo que el primer backend funcional que tiene hace copias exactamente igual que el sistema anterior, pero con una diferencia: ahora utiliza la utilidad RSYNC en lugar de código propio, lo que ha permitido eliminar de un plumazo un bug misterioso que hacía que, muy de vez en cuando, apareciesen carpetas con nombres raros en la carpeta personal. Por supuesto, se aprovecha de que RSYNC permite hacer copias de seguridad con la misma estructura que las viejas versiones de cronopete (los ficheros que no han cambiado son enlaces duros al mismo fichero de la copia anterior, lo que permite ahorrar muchísimo espacio).

Con el nuevo sistema, implementar un backend para hacer copias en remoto debería ser relativamente trivial, aunque el problema es cuando tendré tiempo de ponerme en serio con ello (a fin de cuentas, es algo que quiero probar bien antes de lanzar).

Otra novedad, esta vez más sencilla, es que por fin permite que varios usuarios compartan un mismo disco de copias. Por un fallo tonto, las versiones anteriores ponían la carpeta cronopete, en el disco de destino, con permisos de escritura sólo para el usuario que había formateado el disco. Eso significaba que dicho usuario podía hacer copias sin problema, pero en cuanto otro usuario intentase usar el mismo disco para hacer sus copias, fallaría y le propondría formatearlo. Ahora la carpeta cronopete tiene permisos de escritura para todo el mundo, y dentro, igual que antes, hay una carpeta por usuario, en la que sólo dicho usuario tiene permisos de lectura, escritura y atravesado (por motivos obvios: otros usuarios no deberían tener acceso a mis copias de seguridad, pues son MIS datos).

Otro cambio es que ahora borra las copias nuevas después de hacer la copia de seguridad, lo que permite garantizar que si enciendes el equipo sólo un momento, se haga al menos una copia rápidamente. Además, el borrado de copias viejas se hace de manera más segura: antes se borraba directamente el directorio, lo que podía suponer un problema si se apagaba el ordenador o si cronopete fallaba en mitad del borrado, pues una copia quedaría “a medias”. Ahora, sin embargo, primero se renombran las copias a borrar añadiendo una letra justo antes, de manera que las copias que no se deben tener en cuenta están debidamente etiquetadas; luego se sincroniza el disco, y finalmente se procede a borrar las carpetas así marcadas. Esto tiene otra ventaja, y es que una copia de seguridad no válida nunca aparecerá en la interfaz de restauración de ficheros.

Por último hay varios cambios estéticos y menores, sobre todo en la interfaz de restauración de ficheros. Ahora, por ejemplo, la linea de tiempos muestra la fecha correspondiente, lo que da una idea más precisa de por donde andamos y hasta donde podemos llegar que antes.

También se puede ahora filtrar por tipo de archivo, y, además, cronopete recordará entre ejecuciones si se quería ver en modo iconos o en modo lista de archivos.

Nueva versión de Autovala

marzo 28th, 2018

Hoy saqué una nueva versión de Autovala que añade un detalle muy sencillo pero muy importante: el soporte para anotaciones para traductores.

Resulta que xgettext, la herramienta que extrae del código fuente los textos que hay que traducir a las diversas lenguas, tiene una funcionalidad muy importante, que es la posibilidad de añadir como notas para los traductores cualquier comentario del código que se encuentre en la línea inmediatamente anterior a la de una cadena traducible. Hasta ahora yo daba por hecho que eso se realizaba de manera automática, pero hoy descubrí que no, que hace falta pasar un parámetro en la línea de comandos, en concreto –add-comments. Es más, es posible añadir un tag a continuación, y sólo aquellos comentarios que empiecen por dicho tag serán considerados una nota para los traductores.

Como digo, pensaba que era automático, por lo que Autovala no lo tenía en cuenta, pero al descubrir esto decidí que era una funcionalidad lo suficientemente importante como para que estuviese disponible. Así que ahora es posible añadir en la configuración una línea con po_comment_tag, y todos los comentarios previos a una cadena traducible serán añadidos como notas para traductores. Pero también es posible añadirla como po_comment_tag: XXXXXX, en cuyo caso sólo se añadirán aquellos comentarios que comiencen con XXXXXX.

Como de costumbre, es posible bajar Autovala desde mi página web, o bien desde el repositorio Github de Autovala.

dbForge Mysql en Wine

marzo 19th, 2018

Por una serie de circunstancias tengo que usar dbForge. Dado que se trata de un programa de windows parecía que no había otra que meter una máquina virtual, pero es un entorno que siempre supone un engorro porque no es directo conmutar desde ella hasta algún programa en el sistema operativo maestro. Ante esto decidí intentar hacerlo funcionar en Wine.

El primer problema que me encontré al intentar ejecutar el instalador fue que me exigía un entorno de 32 bits. Para no interferir con otros entornos de wine opté por crear uno independiente. Para ello, en la línea de comandos ejecuté:

export WINEPREFIX=~/.wine32
export WINEARCH=win32

Una vez hecho esto ya ejecutaba el instalador, pero me pedía .NET 3.5 SP1 o superior, y aquí empezaron los problemas. Probé a bajar el instalador de dicho .NET, pero no se dejaba instalar. Rebuscando, en varias páginas indicaban que había que usar winetricks para instalarlo. Así lo intenté con:

winetricks dotnet35sp1

Sin embargo, no se instalaba: algo fallaba en winetricks que la instalación fallaba.

Probé a instalar Mono para windows, pero no sirvió tampoco: el instalador no lo reconocía como un entorno .NET.

Tras varias pruebas infructuosas, finalmente se me ocurrió probar a instalar la versión 4.0 de .NET con:

winetricks dotnet40

Y esta vez sí se instaló completamente. Una vez instalado, probé el instalador de dbForge y también funcionó, así como el programa en sí (aunque da un pequeño aviso, indicando que necesita la versión 2.0 de .NET y que si se quiere bajar; basta con decir “No” y funcionará igualmente bien).

Autovala y Multipackager

marzo 7th, 2018

Recientemente saqué versiones nuevas de Autovala y Multipackager.

En el caso de Autovala, se trata de la 1.3.0. El motivo fue que en la última actualización de paquetes de mi sistema operativo se pasó a Vala 0.39. Sin embargo, este compilador busca los ficheros VAPI en el directorio de la versión 0.40. La solución consistió en no deducir el directorio donde están los ficheros VAPI a partir de la versión del compilador, sino preguntarle donde los va a buscar (para lo que basta con hacer “valac –api-version”). Con esto, Autovala puede por fin encontrar dichos ficheros y detectar automáticamente las dependencias del programa.

El cambio en Multipackager surgió, precisamente, para corregir un problema al crear los paquetes de Autovala, y es que, debido al cambio de nombre de una biblioteca desde Debian Estable a Debian SID, el fichero de configuración sólo servía para uno de ellos. La solución fue modificarlo para que sea capaz de detectar alternativas a paquetes (el comando “|” en las dependencias, para indicar que se puede poner un paquete cualquiera de una lista).

Como de costumbre, están disponibles en mi web y en mi repositorio de GIT.

Cuando WiFi y Bluetooth chocan

febrero 16th, 2018

Hace unos días mi padre estaba sufriendo un problema bastante raro: la conexión a internet de su nuevo móvil iba realmente mal y no recibía mensajes, pero sólo cuando usaba la WiFi de casa. Hice algunas pruebas y, efectivamente, con la WiFi era imposible navegar desde el móvil o enviar mensajes: prácticamente no funcionaba. De vez en cuando enviaba algún que otro mensaje, o era capaz de cargar media página, pero enseguida fallaba de nuevo.

Empecé a hacer pruebas y, de casualidad, llegué hasta el Bluetooth: cuando estaba activo la WiFi no funcionaba, pero si lo desactivaba, funcionaba todo perfectamente. Por desgracia, dado que mi padre tiene un manos libres en el coche, desactivarlo siempre no era una opción, y andar conectándolo cada vez que se sube al coche no es una solución práctica, porque, como nos pasaría a todos, o se olvidaría de encenderlo al subir, o se olvidaría de apagarlo al bajar.

En parte tiene sentido que el Bluetooth interfiera con la WiFi, porque ambos trabajan en la misma banda de frecuencia: 2,4GHz. Sin embargo, lo raro es que no ocurriese con el móvil viejo, así que tocó seguir investigando. ¿Era un problema de ese modelo concreto, tal vez?

La solución apareció por sorpresa: el motivo es que el móvil viejo sólo tenía WiFi 802.11g (que da un máximo de 54 megas por segundo), mientras que el nuevo tiene WiFi 802.11n (que puede dar hasta 300Mbps). Parece que el WiFi n es mucho más sensible a las interferencias, y tener un emisor (el de Bluetooth) tan cerca de su antena hace que no sea capaz de transmitir o recibir de manera fiable.

La solución, al final, consistió en ir al router y configurarlo para que sólo aceptase conexiones WiFi 802.11b/g, en lugar del modo por defecto que era 802.11b/g/n. De esta manera nunca se intentará conectar mediante el protocolo más moderno, y todo funcionará correctamente. Es la mejor opción, además, porque mezclar dispositivos 802.11g con 802.11n hace que el rendimiento de ambos baje mucho, con lo que es mejor que todos se conecten con el mismo protocolo.

El problema lo tengo ahora con mi sobrino, porque le pasa algo parecido pero su router, de Vodafone, no deja al usuario normal cambiar los protocolos, sólo el administrador. A ver si desde el servicio técnico nos lo hacen. Si no, tocará capar todos los equipos de casa uno a uno para que sean ellos los que no se conecten en modo 802.11n.

VirtualBox y Windows 10

junio 2nd, 2017

Por circunstancias de la vida he tenido que usar Windows 10 en una máquina virtual sobre Linux, así que, por comodidad, decidí usar VirtualBox. Mi sorpresa fue descubrir lo terriblemente lento que iba. Por algún motivo se pasaba todo el rato accediendo al disco duro, y eso enlentecía el sistema hasta límites exasperantes.

Afortunadamente, rebuscando, encontré la solución:

  • Pulsar “Windows”+R, para ejecutar una aplicación, y lanzar “services.msc”
  • Buscar “Windows Search” y “Superfetch”.
  • En cada uno, ir a Propiedades, detenerlo, y desactivarlo.
  • Profit!

Más Gentoo para MipsEL

diciembre 25th, 2016

Estoy actualizando la distribución de Gentoo para webtv y, como no podía ser de otra manera, hay problemillas. El último ha sido con busybox. Para poder compilarla hay que añadir, además de las opciones que indico en Generando Gentoo para WebTV, hay que añadir las siguientes:

busybox_config_option n NANDWRITE
busybox_config_option n NANDDUMP
busybox_config_option n FLASH_ERASEALL
busybox_config_option n FLASHCP
busybox_config_option n BLKDISCARD

Por otro lado, la variable USE debe contener:

USE="${ARCH} -pam -fortran -sanitize -X -iptables -hardened -seccomp -ipv6 -systemd -mdev internal-glib -caps -gtk -qt -t -boehm-gc -nls -filecaps"

Utilizamos cookies para garantizar que tenga la mejor experiencia en nuestro sitio web.