Ejecutar un comando de PowerShell copiado de Internet sin revisar el código debería dar más miedo del que da. En el mundo Windows se ha normalizado demasiado abrir una consola con privilegios de administrador, pegar una línea con iex apuntando a un servidor externo y confiar en que todo saldrá bien. A veces la herramienta es conocida, otras veces el repositorio parece fiable y, muchas veces, el usuario solo quiere dejar el sistema limpio cuanto antes.
El problema es que esa comodidad tiene un coste. Cuando un script modifica servicios, políticas, tareas programadas, telemetría, paquetes del sistema, configuración de red o componentes de seguridad, ya no hablamos de una “utilidad” menor. Hablamos de tocar partes sensibles del sistema operativo. Para un usuario doméstico puede ser una forma rápida de quitar bloatware. Para un administrador de sistemas, un desarrollador o alguien que prepara nodos de computación local, ejecutar herramientas sin leerlas es una mala costumbre que tarde o temprano pasa factura.
En ese contexto aparece Manolito 2.8.1, un proyecto que se presenta como optimizador modular y desatendido para Windows 11 Pro, Enterprise y Education. Su planteamiento se aleja del típico script monolítico con un menú enorme de opciones genéricas y apuesta por una arquitectura guiada por datos, donde los payloads y la validación quedan desacoplados de la lógica principal mediante un archivo manolito.json.
Menos navaja suiza, más intervención controlada
Herramientas como la de Chris Titus han ganado popularidad porque resuelven muchos problemas de golpe: instalación de programas, ajustes rápidos, limpieza, cambios de configuración y una interfaz fácil para usuarios que no quieren entrar en detalles. Tienen sentido en ciertos escenarios. El problema aparece cuando se usan igual en un portátil personal, en una estación de trabajo de desarrollo, en un equipo corporativo o en una máquina destinada a servir modelos locales de IA.
No todos los sistemas necesitan lo mismo. Un optimizador cargado de funciones puede acabar aplicando cambios demasiado amplios, instalar utilidades que no se han pedido o tocar componentes que una empresa sí necesita mantener. En administración de sistemas, menos puede ser más si el objetivo es saber exactamente qué se modifica, por qué y con qué posibilidad de reversión.
Manolito intenta ocupar ese espacio. Según la documentación del proyecto, ha evolucionado de un script de limpieza a un “framework de aprovisionamiento declarativo” bajo principios de Zero Trust. La expresión puede sonar ambiciosa, pero la idea práctica es clara: separar configuración, payloads y motor; facilitar auditoría; permitir runlevels; detectar hardware específico; y guardar una fotografía técnica del equipo antes de aplicar cambios para habilitar rollback.
La versión 2.8.1 incorpora una interfaz WPF asíncrona basada en runspaces y ConcurrentQueue, de forma que la interfaz no se bloquee mientras se ejecutan tareas pesadas. También introduce auditoría WMI en tiempo real para detectar elementos como NVMe, GPUs NVIDIA, batería o máquinas virtuales, y bloquear automáticamente payloads incompatibles.
| Elemento de Manolito 2.8.1 | Qué aporta |
|---|---|
Motor guiado por manolito.json | Payloads y lógica desacoplados |
| Interfaz WPF asíncrona | Ejecución en segundo plano sin bloquear la UI |
| Auditoría WMI | Detección de hardware y bloqueo de ajustes incompatibles |
| Runlevels | Modos LITE, DEV-EDU, DEEP OP, ROLLBACK y NVME FIX |
| Manifest Time-Machine | Captura técnica previa para facilitar reversión |
| Enfoque | Telemetría, bloatware, identidad cloud y ajustes de rendimiento |
| Plataforma objetivo | Windows 11 Build 22000 – 26200+ |
| Framework | PowerShell 5.1 |
Qué toca y por qué importa
Manolito no se presenta como una herramienta neutra. Su documentación deja claro que su objetivo es reducir telemetría, eliminar bloatware, limitar componentes no deseados y ajustar el sistema para mejorar rendimiento y consumo. El proyecto menciona protección frente a telemetría de Microsoft, cloud identity, restos de activadores KMS y componentes de bloatware.
Ese tipo de cambios puede ser útil en escenarios muy concretos. Un equipo de laboratorio, una máquina antigua, un portátil con pocos recursos o un nodo local dedicado a inferencia pueden beneficiarse de reducir procesos en segundo plano, widgets, servicios innecesarios y capas de telemetría. En máquinas con 2 GB o 4 GB de RAM, cualquier proceso residente cuenta.
La documentación del proyecto afirma que Manolito permite operar Windows 11 con recursos muy reducidos, con un “RAM Challenge” sobre máquinas de 2 GB, consumo base de hasta 1,4 GB y CPU en reposo estabilizada entre el 0 % y el 7 %. Son cifras del propio proyecto y conviene tratarlas como resultados de laboratorio o casos concretos, no como garantía universal. El rendimiento real dependerá del hardware, la edición de Windows, drivers, servicios instalados, actualizaciones y uso posterior.
Lo interesante no es prometer milagros, sino la filosofía de ajuste fino. Manolito organiza su ejecución por niveles. LITE se centra en bloatware esencial y telemetría básica. DEV-EDU apunta a redes, publicidad y limpieza de restos de KMS. DEEP OP entra en ajustes más sensibles, como latencia de entrada, MSI en GPU/NVMe y desactivación de VBS. ROLLBACK permite reversión granular. NVME FIX aplica tuning específico para almacenamiento sólido cuando detecta hardware NVMe físico.
Esta separación es importante porque no todos los ajustes son igual de seguros. Quitar una app preinstalada no tiene el mismo riesgo que modificar VBS, tocar caché de escritura NVMe o ajustar servicios de red. Un buen optimizador debería dejar claro qué nivel de intervención se está aplicando y qué impacto puede tener.
La transparencia como requisito, no como adorno
La parte más relevante para administradores y desarrolladores no es que Manolito tenga una interfaz llamativa. Es que el proyecto permite revisar el código y los payloads antes de ejecutarlos. En sistemas Windows, donde muchas herramientas se distribuyen como scripts largos y poco documentados, esta transparencia es una ventaja práctica.
Eso no significa que haya que confiar ciegamente. Al contrario. Un script que requiere permisos de administrador debe auditarse siempre. Hay que leer el .ps1, revisar el manolito.json, entender qué claves de registro modifica, qué servicios desactiva, qué tareas toca, qué paquetes elimina y qué cambios son reversibles. La confianza no debe venir del nombre del proyecto, sino de la capacidad de comprobar lo que hace.
También conviene tener presente la licencia. Manolito Engine se distribuye como software libre bajo GNU GPLv3 para uso personal y educativo, pero el propio README advierte de que el uso en entornos corporativos o por parte de MSP con fines lucrativos requiere una licencia comercial para eximirse de las obligaciones copyleft de la GPLv3. Este punto es importante para empresas que quieran incorporarlo a procesos internos, imágenes base o servicios de soporte.
En entornos profesionales, además, cualquier optimización debería probarse antes en máquinas de laboratorio. No basta con que el script funcione en el PC del autor o en un equipo doméstico. Hay que validarlo contra imágenes reales, políticas de dominio, soluciones EDR, VPN, software corporativo, actualizaciones, drivers, impresoras, herramientas de virtualización y requisitos de soporte.
Optimizar Windows no debería ser un acto de fe
La crítica de fondo no va contra una herramienta concreta, sino contra una mala práctica del sector: ejecutar scripts de optimización como si fueran recetas universales. Windows 11 puede venir cargado de componentes innecesarios para ciertos usos, pero también integra dependencias que no siempre se entienden a primera vista. Tocar a ciegas puede romper Windows Update, autenticación, red, búsqueda, Microsoft Store, drivers, políticas de seguridad o aplicaciones empresariales.
Por eso un optimizador útil para perfiles técnicos debería cumplir varias condiciones: código auditable, cambios documentados, ejecución modular, posibilidad de rollback, detección de hardware, separación entre ajustes seguros y agresivos, y ausencia de dependencias opacas. Manolito intenta cubrir buena parte de ese enfoque.
Su valor está en asumir que no todos los usuarios quieren una navaja suiza llena de botones. Algunos quieren un bisturí: menos funciones decorativas, más control, menos automatismo ciego y más posibilidad de entender qué ocurre en el sistema.
Eso no lo convierte en una herramienta para cualquiera. Precisamente por su capacidad de modificar partes sensibles de Windows, Manolito debería usarse con criterio técnico. Para usuarios sin experiencia, un optimizador potente puede ser tan peligroso como el problema que intenta resolver. Para administradores, desarrolladores y perfiles avanzados, puede ser una base interesante si se revisa, se prueba y se adapta al entorno.
La lección es sencilla. Optimizar Windows no debería consistir en pegar un comando encontrado en redes. Debería consistir en saber qué sobra, qué se toca, qué se conserva y cómo se vuelve atrás si algo falla. Manolito 2.8.1 apunta en esa dirección: menos fe en scripts remotos y más control sobre el sistema.
Preguntas frecuentes
¿Qué es Manolito 2.8.1?
Manolito 2.8.1 es un optimizador modular para Windows 11 Pro, Enterprise y Education basado en PowerShell, con interfaz WPF, runlevels y motor guiado por manolito.json.
¿En qué se diferencia de otros scripts de optimización?
Su documentación destaca una arquitectura data-driven, auditoría WMI, ejecución asíncrona, runlevels diferenciados y rollback mediante manifest técnico previo.
¿Es recomendable ejecutarlo sin revisar el código?
No. Cualquier herramienta que requiera permisos de administrador y modifique servicios, registro o políticas del sistema debe revisarse antes y probarse en un entorno controlado.
¿Puede usarse en empresas?
El README indica que el proyecto está bajo GPLv3 para uso personal y educativo, y que el uso corporativo o por MSP con fines lucrativos requiere licencia comercial.
Fuentes:
