Herramientas de desarrollo on KnightLi Blog

Cómo cambiar el idioma de la interfaz de VS Code: chino, inglés y otros idiomas

Fri, 08 May 2026 13:18:57 +0800

VS Code admite muchos idiomas de interfaz. Lo habitual es instalar primero el paquete de idioma correspondiente y luego elegir el idioma de visualización desde la paleta de comandos. Si necesitas fijar VS Code a un idioma concreto, también puedes modificar manualmente el valor locale en argv.json.

Este método no solo sirve para chino simplificado; también funciona con inglés, chino tradicional, japonés, coreano, francés, alemán, español y otros idiomas.

Instalar el paquete de idioma correspondiente

Si quieres cambiar a una interfaz que no sea inglés, normalmente debes instalar primero un paquete de idioma.

Abre el panel de extensiones de VS Code en la barra lateral izquierda, o usa el atajo Ctrl+Shift+X.
En el cuadro de búsqueda, escribe el idioma objetivo, por ejemplo Chinese, Japanese, Korean o French.
Selecciona el paquete de idioma correspondiente y haz clic en Install.
Cuando termine la instalación, reinicia VS Code si se te solicita.

Para chino simplificado, el paquete habitual es Chinese (Simplified). Para chino tradicional, usa Chinese (Traditional).

Cambiar el idioma desde la paleta de comandos

Este es el método recomendado para la mayoría de los usuarios.

Abre la paleta de comandos: Ctrl+Shift+P.
Escribe Configure Display Language.
Selecciona el comando Configure Display Language.
Elige en la lista el idioma que quieres usar.
Reinicia VS Code si se te solicita.

Después del reinicio, los menús, las páginas de configuración y los mensajes habituales usarán el idioma seleccionado. Si el idioma objetivo no aparece en la lista, instala antes su paquete desde el panel de extensiones.

Especificar el idioma manualmente en argv.json

Si el cambio desde la paleta de comandos no funciona, o si quieres fijar explícitamente el idioma de visualización, puedes editar directamente el archivo de argumentos de ejecución de VS Code.

Abre la paleta de comandos: Ctrl+Shift+P.
Escribe y selecciona Preferences: Configure Runtime Arguments.
Busca o agrega la opción locale.
Cambia su valor por el código del idioma objetivo.
Guarda el archivo y reinicia VS Code.

Por ejemplo, para cambiar a inglés:

1
2
3

{
  "locale": "en"
}

Para cambiar a chino simplificado:

1
2
3

{
  "locale": "zh-cn"
}

Para cambiar a japonés:

1
2
3

{
  "locale": "ja"
}

argv.json es un archivo JSON, así que presta atención a las comas y las comillas. Si la configuración no es válida, VS Code puede no leer correctamente el idioma configurado.

Códigos de idioma de interfaz comunes

Idioma de visualización	locale
English (US)	`en`
Chino simplificado	`zh-cn`
Chino tradicional	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

Qué hacer si el idioma no cambia

Revisa estos puntos en orden:

Confirma que el paquete del idioma objetivo está instalado.
Confirma que locale usa el código correcto. Por ejemplo, chino simplificado es zh-cn, no zh-CN.
Cierra VS Code por completo y vuelve a abrirlo después de cambiar el idioma.
Si editaste argv.json manualmente, comprueba que la sintaxis JSON sea válida.
Si la configuración está desordenada, elimina la entrada locale y vuelve a elegir el idioma mediante Configure Display Language.

En la mayoría de los casos, Configure Display Language es la opción más sencilla. Edita argv.json solo cuando necesites forzar un idioma concreto o cuando el cambio desde la paleta de comandos no surta efecto.

Referencias

VScode: cambiar el idioma de la interfaz de VS Code a chino simplificado y alternar el idioma de visualización

opencode, Claude Code y Codex: diferencias y guía de herramientas open source de programación con IA

Fri, 08 May 2026 08:33:37 +0800

opencode es un AI Coding Agent open source de anomalyco. Su posicionamiento es directo: dar a los desarrolladores un asistente de código programable, extensible y capaz de conectarse a varios proveedores de modelos dentro de la terminal.

Si lo comparamos con Claude Code y Codex, los tres resuelven una misma clase de problema: llevar la IA a bases de código reales para entender contexto, modificar archivos, ejecutar comandos y correr pruebas. Pero su orientación de producto es distinta.

opencode pone más énfasis en open source, soporte de múltiples modelos y TUI de terminal. Claude Code enfatiza el ecosistema de modelos de Anthropic y la colaboración de ingeniería local. Codex es el AI coding agent de OpenAI, disponible desde la terminal, IDEs, Codex app y tareas en la nube.

Para quién es opencode

opencode encaja mejor con estos tipos de desarrolladores:

Quienes quieren completar cambios de código, análisis de proyectos y tareas de ingeniería desde la terminal.
Quienes no quieren que su AI Coding Agent dependa de un único proveedor de modelos.
Quienes prefieren herramientas open source y quieren auditarlas, ampliarlas o construir sobre ellas.
Quienes ya están cómodos con Neovim, TUI y flujos de línea de comandos.
Quienes quieren controlar en el futuro el mismo agente de programación desde una app de escritorio, móvil u otros clientes.

Su objetivo no es crear otra ventana de chat, sino poner capacidades de programación con IA dentro de la terminal y los directorios de proyecto que los desarrolladores ya usan.

Instalación

El README oficial ofrece varias formas de instalación.

# Instalación directa
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS y Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# Otros métodos
mise use -g opencode
nix run nixpkgs#opencode

El README oficial también recomienda eliminar versiones anteriores a 0.1.x antes de instalar, para evitar problemas causados por restos de versiones antiguas.

El script de instalación elige el directorio de instalación con esta prioridad:

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

Si necesitas especificar una ruta, puedes usar:

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

La app de escritorio sigue en Beta

Además de la herramienta de línea de comandos, opencode también ofrece una app de escritorio, actualmente marcada como Beta. Se puede descargar desde GitHub Releases o opencode.ai/download.

La versión de escritorio cubre estas plataformas:

Plataforma	Archivo
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`, `.rpm` o `.AppImage`

En macOS y Windows también se puede instalar la app de escritorio con gestores de paquetes.

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

Dos modos Agent integrados

opencode incluye dos Agent integrados, que se pueden cambiar con la tecla Tab.

build es el modo predeterminado. Tiene permisos completos de desarrollo y sirve para editar código directamente, ejecutar comandos y avanzar en tareas de ingeniería.

plan es el modo de solo lectura. Es más adecuado para analizar bases de código desconocidas, entender la estructura del proyecto y preparar un plan de cambios. Por defecto rechaza ediciones de archivos y pregunta antes de ejecutar comandos bash.

Además, opencode incluye un sub-Agent general para búsquedas complejas y tareas de varios pasos. Los usuarios pueden invocarlo escribiendo @general en un mensaje.

Este diseño es bastante práctico: antes de actuar, usa plan para entender el proyecto; cuando haga falta cambiar código, cambia a build. En repositorios grandes, separar permisos de lectura y escritura ayuda a reducir errores.

Qué es Codex

Codex es el AI coding agent de OpenAI para ayudar a desarrolladores a escribir código, revisar código, corregir bugs y entregar tareas de ingeniería.

A diferencia de una herramienta simple de autocompletado, Codex se parece más a un Agent capaz de operar sobre una base de código. Puede trabajar contigo en herramientas locales y también puede recibir tareas delegadas para ejecutarlas en la nube. Los materiales oficiales de OpenAI describen Codex como disponible desde varias superficies, incluyendo CLI, IDEs, Codex app y flujos en la nube de ChatGPT/Codex.

Para desarrolladores, Codex tiene varios puntos importantes:

Puede leer bases de código, editar archivos, ejecutar comandos y correr pruebas.
Soporta varias interfaces, incluyendo terminal, IDE, app y nube.
Encaja con corrección de bugs, desarrollo de funciones, refactorización, migraciones, revisión de código y generación de pruebas.
Está más ligado a cuentas, modelos y ecosistema de producto de OpenAI.
Las tareas en la nube sirven para ejecutar en paralelo varias tareas de ingeniería relativamente bien definidas.

Si opencode se parece más a un framework abierto de agente en terminal, Codex se parece más a un banco de trabajo completo de programación con IA ofrecido por OpenAI: colaboración local, delegación en la nube y flujos de ingeniería más largos para equipos.

Diferencias principales

opencode, Claude Code y Codex son herramientas de programación con IA, pero la elección se entiende mejor mirando estas dimensiones.

Herramienta	Posicionamiento central	Ventajas principales	Mejor para
`opencode`	AI Coding Agent open source	Open source, múltiples modelos, TUI, arquitectura cliente/servidor	Desarrolladores que quieren una cadena de herramientas abierta, modelos reemplazables y un flujo centrado en terminal
`Claude Code`	Herramienta de programación de línea de comandos de Anthropic	Experiencia con modelos Claude, comprensión de código, contexto largo, colaboración en tareas de ingeniería	Desarrolladores que ya usan el ecosistema Claude/Anthropic y quieren avanzar tareas de código locales
`Codex`	AI coding agent de OpenAI	CLI, IDE, Codex app, tareas en la nube, flujos multi-Agent	Equipos que ya usan ChatGPT/OpenAI y quieren combinar colaboración local con delegación en la nube

En resumen, las palabras clave de opencode son “apertura y reemplazabilidad”; las de Claude Code son “ecosistema Claude y agente local de ingeniería”; y las de Codex son “ecosistema OpenAI y colaboración desde múltiples entradas”.

Diferencias con Claude Code

El FAQ oficial de opencode lo compara directamente con Claude Code. Ambos son muy parecidos en capacidad, pero las diferencias principales son estas.

Primero, opencode es un proyecto 100% open source, alojado en GitHub y publicado con MIT license.

Segundo, opencode no depende de un único proveedor de modelos. Recomienda los modelos ofrecidos a través de OpenCode Zen, pero también puede trabajar con Claude, OpenAI, Google o modelos locales. Para desarrolladores, esto significa que cuando cambien el costo, la capacidad o la disponibilidad de los modelos, no quedarán atados a una sola plataforma.

Tercero, opencode incluye soporte LSP opcional. Para autocompletado, navegación, diagnósticos y comprensión del proyecto, LSP es una base muy importante.

Cuarto, opencode pone más énfasis en TUI. Está creado por usuarios de Neovim y los creadores de terminal.shop, así que el foco del producto está claramente en la experiencia de terminal.

Quinto, opencode usa una arquitectura cliente/servidor. Esto significa que opencode puede ejecutarse en tu computadora y, en el futuro, controlarse desde una TUI, una app de escritorio, una app móvil u otros clientes. La TUI es solo una de las posibles interfaces.

Cuándo elegir opencode, Claude Code o Codex

Si ya usas Claude Code o Codex, opencode no tiene por qué reemplazarlos de inmediato. Una forma más razonable de verlo es que ofrece una opción abierta, con modelos reemplazables y orientada a la terminal.

Conviene considerar primero opencode cuando:

Quieres que tu herramienta de programación con IA sea lo más open source posible.
No quieres atar tu flujo de trabajo a un proveedor de modelos.
Quieres probar Claude, OpenAI, Google o modelos locales con la misma herramienta.
Te gustan los flujos TUI y no quieres que una app de escritorio o web interrumpa tu flujo principal.
Te interesa el potencial de control remoto de una arquitectura cliente/servidor.

Conviene considerar primero Claude Code cuando:

Usas principalmente modelos Claude.
Te importan el contexto largo, la comprensión de código y la colaboración en tareas de ingeniería complejas.
Quieres avanzar cambios, pruebas y refactorizaciones dentro de un repositorio local.
Confías más en la experiencia predeterminada de Claude Code diseñada por Anthropic.

Conviene considerar primero Codex cuando:

Ya usas ChatGPT o el ecosistema de cuentas de OpenAI.
Quieres un mismo coding agent en terminal, IDE, app de escritorio y tareas en la nube.
Quieres delegar en la nube correcciones de bugs, desarrollo de funciones, migraciones o generación de pruebas relativamente claras, en paralelo.
Necesitas revisión de código, tareas en segundo plano, colaboración de equipo y flujos multi-Agent.

Si priorizas una experiencia oficial de extremo a extremo, configuración predeterminada de modelos, administración empresarial e integraciones listas, Claude Code o Codex pueden ser más cómodos. Si priorizas control, apertura y enfoque provider-agnostic, opencode merece atención.

Puntos a tener en cuenta

opencode, Claude Code y Codex avanzan rápido. Los releases de GitHub, comandos de instalación, nombres de archivos de escritorio, disponibilidad de modelos y permisos de planes pueden cambiar. Antes de instalar o elegir, conviene revisar directamente el README, la documentación y las páginas de releases oficiales de cada herramienta.

Además, la app de escritorio de opencode sigue marcada como Beta, así que no conviene tratarla por defecto como una herramienta estable de producción. Para tareas de ingeniería diarias, la versión de terminal sigue siendo la entrada principal.

Visto como tendencia de herramientas, opencode representa la dirección de cadena de herramientas abierta para AI Coding Agents: modelos reemplazables, clientes reemplazables y una capacidad central de agente lo más abierta posible. Codex y Claude Code se parecen más a modelos convertidos por sus empresas en superficies de producto completas para coding agents. Para desarrolladores, ambas rutas probablemente coexistirán durante mucho tiempo.

Referencias

opencode GitHub: https://github.com/anomalyco/opencode
sitio oficial de opencode: https://opencode.ai
documentación de opencode: https://opencode.ai/docs
opencode Releases: https://github.com/anomalyco/opencode/releases
OpenAI Codex: https://openai.com/codex/
Using Codex with your ChatGPT plan: https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started: https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Guía de instalación de uv: cómo elegir entre macOS, Linux, Windows, pipx, Homebrew y WinGet

Thu, 07 May 2026 23:23:58 +0800

uv es un gestor de toolchain de Python creado por Astral. Sirve para gestionar versiones de Python, entornos virtuales, dependencias, scripts, proyectos y herramientas. Tiene muchas formas de instalación. La documentación oficial ofrece instaladores independientes y también admite PyPI, Homebrew, WinGet, Scoop, Docker, GitHub Releases y Cargo.

Si solo quieres instalarlo rápido, da prioridad al instalador independiente oficial. Si prefieres mantener la versión mediante el gestor de paquetes del sistema, usa Homebrew, WinGet o Scoop. Si ya acostumbras instalar herramientas de Python en entornos aislados, puedes usar pipx.

Elección rápida

Escenario	Método recomendado	Comando
Instalación rápida en macOS / Linux	Instalador independiente oficial	`curl -LsSf https://astral.sh/uv/install.sh \| sh`
macOS / Linux sin curl	Script oficial + wget	`wget -qO- https://astral.sh/uv/install.sh \| sh`
Instalación rápida en Windows	Instalador de PowerShell	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`
Instalación aislada de herramientas Python	pipx	`pipx install uv`
Instalación temporal o tradicional de Python	pip	`pip install uv`
Gestión de paquetes en macOS	Homebrew	`brew install uv`
Usuarios de MacPorts en macOS	MacPorts	`sudo port install uv`
Gestión de paquetes en Windows	WinGet	`winget install --id=astral-sh.uv -e`
Usuarios de Scoop en Windows	Scoop	`scoop install main/uv`
Usuarios de Rust	Cargo	`cargo install --locked uv`

Las opciones generales más recomendables son:

macOS / Linux: instalador independiente oficial;
Windows: instalador oficial de PowerShell o WinGet;
si ya gestionas herramientas CLI de Python con pipx: pipx install uv.

macOS y Linux: instalador oficial

El método oficial más directo consiste en descargar el script con curl y ejecutarlo con sh:

`1`	`curl -LsSf https://astral.sh/uv/install.sh \| sh`

Si el sistema no tiene curl, puedes usar wget:

`1`	`wget -qO- https://astral.sh/uv/install.sh \| sh`

Si quieres instalar una versión concreta, coloca el número de versión en la URL. Por ejemplo, el ejemplo oficial usa 0.11.11:

`1`	`curl -LsSf https://astral.sh/uv/0.11.11/install.sh \| sh`

Este método encaja con la mayoría de entornos personales de desarrollo. Es simple, multiplataforma y funciona mejor con el mecanismo oficial de actualización de uv.

El instalador coloca binarios como uv y uvx bajo el directorio del usuario, y puede modificar el shell profile para que los comandos puedan usarse directamente desde la terminal. Si no quieres que el instalador modifique PATH, revisa las opciones oficiales del installer, por ejemplo configurando UV_NO_MODIFY_PATH=1.

Windows: instalador de PowerShell

El método oficial en Windows es ejecutar el script de instalación con PowerShell:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`

Para instalar una versión concreta, también puedes poner el número de versión en la URL:

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.11.11/install.ps1 \| iex"`

Aquí ExecutionPolicy ByPass permite obtener y ejecutar el script de instalación desde internet. Como hábito de seguridad, puedes revisar el contenido del script antes de ejecutarlo:

`1`	`powershell -c "irm https://astral.sh/uv/install.ps1 \| more"`

Si estás acostumbrado a gestores de paquetes de Windows, también puedes priorizar WinGet o Scoop.

Instalar con pipx

La documentación oficial indica que uv se publica en PyPI. Si lo instalas desde PyPI, se recomienda ponerlo en un entorno aislado, por ejemplo con pipx:

`1`	`pipx install uv`

Este método es adecuado si ya usas pipx como gestor de herramientas CLI de Python. Evita mezclar uv con el entorno del proyecto actual.

Si no tienes pipx, también puedes usar pip directamente:

`1`	`pip install uv`

Pero ten en cuenta que uv ofrece wheels precompilados en muchas plataformas. Si una plataforma no tiene un wheel compatible, se construirá desde código fuente, y en ese caso necesitarás una toolchain de Rust.

Mi recomendación: en una máquina personal, pipx install uv es más limpio que pip install uv; dentro de un entorno de proyecto, no recomiendo instalar uv como dependencia del proyecto.

Homebrew, MacPorts, WinGet y Scoop

Si prefieres gestores de paquetes del sistema, uv también admite canales comunes.

En macOS, usa Homebrew:

`1`	`brew install uv`

Los usuarios de MacPorts pueden usar:

`1`	`sudo port install uv`

En Windows, usa WinGet:

`1`	`winget install --id=astral-sh.uv -e`

Los usuarios de Scoop pueden usar:

`1`	`scoop install main/uv`

La ventaja de estos métodos es que delegan el mantenimiento en el gestor de paquetes del sistema. La desventaja es que el ritmo de actualización depende del origen de paquetes correspondiente, no del instalador oficial de uv.

Docker, GitHub Releases y Cargo

uv también ofrece imágenes Docker en GitHub Container Registry:

`1`	`ghcr.io/astral-sh/uv`

Esto sirve para CI, Dockerfiles, creación de imágenes y entornos temporales de ejecución. En uso real, conviene revisar también la documentación oficial de integración con Docker.

Si quieres descargar binarios manualmente, puedes hacerlo desde GitHub Releases. Cada página de release suele incluir binarios para las plataformas compatibles y explicar cómo llamar al instalador independiente usando una URL de GitHub.

Los usuarios de Rust también pueden instalar desde crates.io:

`1`	`cargo install --locked uv`

Pero este método compila desde código fuente y requiere una toolchain de Rust compatible. A menos que necesites instalarlo explícitamente desde el ecosistema Rust, los usuarios normales no tienen por qué elegir Cargo primero.

Actualizar uv

Si uv se instaló mediante el instalador independiente oficial, puedes usar el comando de autoactualización:

`1`	`uv self update`

La documentación oficial indica que actualizar uv vuelve a ejecutar el instalador y puede modificar el shell profile. Si no quieres que la actualización modifique PATH, configura:

`1`	`UV_NO_MODIFY_PATH=1`

Si lo instalaste de otra forma, debes actualizarlo con el gestor correspondiente. Por ejemplo, si lo instalaste con pip, usa:

`1`	`pip install --upgrade uv`

Homebrew, WinGet, Scoop y MacPorts también deben usar sus propios comandos de actualización.

Activar autocompletado de shell

uv admite autocompletado de shell. La documentación oficial recomienda comprobar primero cuál es tu shell actual:

`1`	`echo $SHELL`

Bash:

`1`	`echo 'eval "$(uv generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uv generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uv generate-shell-completion fish \| source' > ~/.config/fish/completions/uv.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uv generate-shell-completion powershell) | Out-String | Invoke-Expression'

Si también usas uvx con frecuencia, puedes activar el autocompletado de uvx por separado.

Bash:

`1`	`echo 'eval "$(uvx --generate-shell-completion bash)"' >> ~/.bashrc`

Zsh:

`1`	`echo 'eval "$(uvx --generate-shell-completion zsh)"' >> ~/.zshrc`

fish:

`1`	`echo 'uvx --generate-shell-completion fish \| source' > ~/.config/fish/completions/uvx.fish`

PowerShell:

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uvx --generate-shell-completion powershell) | Out-String | Invoke-Expression'

Después de configurarlo, reinicia el shell o recarga el archivo de configuración correspondiente.

Desinstalar uv

Para desinstalar uv, primero puedes limpiar la caché y los datos gestionados por uv:

1
2
3

uv cache clean
rm -r "$(uv python dir)"
rm -r "$(uv tool dir)"

Después elimina los binarios.

macOS / Linux:

`1`	`rm ~/.local/bin/uv ~/.local/bin/uvx`

Windows:

1
2
3

rm $HOME\.local\bin\uv.exe
rm $HOME\.local\bin\uvx.exe
rm $HOME\.local\bin\uvw.exe

La documentación oficial también recuerda que antes de 0.5.0, uv se instalaba en ~/.cargo/bin. Si actualizaste desde una versión antigua, es posible que los binarios viejos sigan allí y debas eliminarlos manualmente.

Qué hacer después de instalar

Después de instalar, conviene confirmar primero la versión:

`1`	`uv --version`

Luego puedes empezar con algunas tareas comunes:

uv python install
uv venv
uv pip install requests
uvx ruff --version

Si es un proyecto nuevo, puedes seguir aprendiendo:

uv init: inicializar un proyecto;
uv add: añadir dependencias;
uv sync: sincronizar el entorno;
uv run: ejecutar comandos dentro del entorno del proyecto;
uvx: ejecutar temporalmente herramientas CLI de Python.

Mi recomendación

En una máquina personal de desarrollo, prioriza el instalador independiente oficial, porque es el método más alineado con la documentación oficial de uv y admite uv self update.

Si usas Windows y no quieres ejecutar un script remoto, puedes usar WinGet o Scoop. Si usas macOS y prefieres que todas tus herramientas las gestione Homebrew, puedes usar directamente brew install uv.

Quienes ya gestionan herramientas CLI de Python con pipx pueden usar pipx install uv. Pero no recomiendo ejecutar pip install uv dentro del entorno virtual de un proyecto concreto, porque eso mezcla la toolchain con las dependencias del proyecto.

Si se trata de CI o construcción de contenedores, revisa primero Docker y GitHub Releases, y fija la versión según el flujo de creación de la imagen.

Enlaces relacionados

Documentación de instalación de uv: https://docs.astral.sh/uv/getting-started/installation/
uv First steps: https://docs.astral.sh/uv/getting-started/first-steps/
Integración de uv con Docker: https://docs.astral.sh/uv/guides/integration/docker/
uv GitHub Releases: https://github.com/astral-sh/uv/releases

Awesome Codex Skills: un catalogo comunitario para ampliar Codex CLI

Thu, 07 May 2026 20:19:15 +0800

awesome-codex-skills, de ComposioHQ, es un catalogo comunitario de skills para Codex CLI. Su valor no esta en ser otra pila de plantillas de prompts, sino en ofrecer una forma de empaquetar flujos repetibles como Skills instalables, reutilizables y mantenibles.

Si ya usas Codex como parte del desarrollo diario, este tipo de repositorio resulta util de inmediato: reglas, comandos, materiales de referencia y pasos operativos que antes tenias que explicar una y otra vez pueden escribirse una vez y reutilizarse cada vez que se invoque la Skill correspondiente.

Que resuelve este repositorio

Las Codex Skills pueden entenderse como modos de trabajo especializados para Codex CLI. Un prompt normal sirve bien para una instruccion temporal; una Skill encaja mejor con algo que quieres reutilizar durante mucho tiempo.

Por ejemplo, puede que a menudo necesites:

generar mensajes de commit con un formato fijo;
consultar una familia especifica de documentacion de API;
ejecutar comandos de pruebas y despliegue propios de un proyecto;
reescribir articulos, traducir documentos u organizar notas segun reglas del equipo;
llamar herramientas externas para tareas de desarrollo repetitivas.

Escribir estas instrucciones cada vez se convierte rapidamente en sobrecarga. Una Skill coloca las reglas en un directorio independiente. El nucleo suele ser un archivo SKILL.md, a veces acompanado de scripts, plantillas, documentos de referencia o assets. Cuando Codex se activa, lee las instrucciones y sigue el flujo descrito alli.

En que se diferencia de un prompt

Un prompt se parece mas a una instruccion puntual: “haz esta tarea de esta forma”. Una Skill se parece mas a un pequeno manual operativo: “cuando aparezca esta clase de tarea, trabaja de esta manera”.

Sus principales ventajas son:

Reutilizable: los flujos comunes ya no necesitan preparacion por copy-and-paste.
Revisable: los archivos de skill suelen ser Markdown locales que pueden abrirse, editarse y versionarse.
Extensible: las skills complejas pueden incluir scripts, plantillas y referencias, no solo instrucciones en lenguaje natural.

Por eso catalogos como awesome-codex-skills son utiles: ayudan a descubrir skills existentes y luego adaptarlas a tu propio flujo de trabajo.

Instalacion y uso

El repositorio ofrece un script de instalacion y tambien soporta instalacion manual. Un flujo tipico es:

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

Si solo quieres probar algunas skills, lee primero el SKILL.md de cada directorio. Revisa que lee, que scripts puede ejecutar, que archivos puede editar y si los valores por defecto encajan con tu entorno local.

Despues de instalar, Codex puede detectar skills cuando la tarea las necesita, o puedes nombrar una skill de forma explicita. Para uso a largo plazo, el enfoque mas practico suele ser instalar primero una skill comunitaria y despues reescribir sus instrucciones alrededor de las convenciones de tu proyecto.

Que skills merece la pena observar

Las skills mas valiosas no son necesariamente las que tienen los nombres mas llamativos. Son las que eliminan trabajo repetido de forma fiable.

Yo miraria primero:

Skills de flujo de desarrollo: review, pruebas, commits, releases, comprobacion de dependencias.
Skills de documentacion: reescritura, traduccion, resumen, organizacion estructurada.
Skills de integracion de herramientas: conectar Codex con servicios externos, APIs y herramientas CLI.
Skills de convenciones de proyecto: codificar reglas del equipo, estructura de directorios, convenciones de nombres y pasos de despliegue.

Si una skill solo envuelve un prompt de una frase, su valor es limitado. Si puede conectar investigacion, juicio, ejecucion, verificacion y salida en un flujo estable, merece conservarse.

Puntos de cuidado

Las skills comunitarias son comodas, pero no deberian tratarse como cajas negras. Esto es especialmente cierto para Skills que incluyen scripts. Antes de instalar una, revisa:

que le pide SKILL.md a Codex;
si incluye scripts que acceden a la red, leen o escriben archivos, o llaman servicios externos;
si las rutas, comandos y permisos por defecto encajan con tu maquina.

Una Skill amplia lo que Codex puede hacer. Bien escrita, hace que Codex se sienta mas como un companero que conoce tu proyecto. Escrita con descuido, puede traer reglas inadecuadas a tu flujo de trabajo. El mejor patron no es instalar muchas skills, sino mantener un conjunto pequeno, ajustarlas con cuidado y conservarlas con el tiempo.

Mi lectura

awesome-codex-skills merece guardarse en favoritos, especialmente si ya usas Codex CLI para desarrollo real, documentacion o automatizacion. No es una capacidad oficial por si misma; es un punto de entrada comunitario para encontrar y adaptar flujos reutilizables.

Para usuarios intensivos, el punto de Codex Skills no es simplemente ayudar a la IA a recordar mas. Es ayudar a la IA a dar menos rodeos en tareas repetidas. Escribir reglas como Skills convierte instrucciones temporales en infraestructura de trabajo reutilizable.

Warp Open Source: de terminal a entorno de desarrollo agentico

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp es el repositorio open source del cliente de Warp. Warp se describe ahora como un “entorno de desarrollo agentico, nacido del terminal”: parte del terminal, pero lleva agentes de programacion con IA, indexacion de codebase, gestion de tareas y flujos de desarrollo a un solo entorno.

No es un repositorio open source ordinario de emulador de terminal. Se parece mas a una respuesta a una pregunta mayor: cuando agentes como Claude Code, Codex y Gemini CLI se vuelven comunes, deberia el propio terminal convertirse en un entorno de desarrollo para planificar, observar y gestionar agentes?

La respuesta de Warp es si.

Estado actual del repositorio

Al 7 de mayo de 2026, warpdotdev/warp es un repositorio publico. GitHub muestra alrededor de 56k stars y 4.1k forks. El README dice que el codigo del cliente Warp ahora es open source y da la bienvenida a contribuciones de la comunidad.

El lenguaje principal es Rust. El desglose de lenguajes de GitHub muestra Rust por encima del 98%, lo que encaja con el posicionamiento de Warp: no es un wrapper web, sino una herramienta de desarrollo nativa y multiplataforma.

Varios detalles del README importan:

Warp es un entorno de desarrollo agentico, nacido del terminal.
Puede usar su agente de programacion integrado y tambien conectar con agentes CLI externos como Claude Code, Codex y Gemini CLI.
OpenAI es el patrocinador fundador del repositorio Warp recien abierto.
Los flujos de gestion agentica del repositorio estan impulsados por modelos GPT.
Los crates del framework de UI de Warp usan licencia MIT, mientras que el resto del codigo usa AGPL v3.

Esto muestra que el movimiento open source de Warp no consiste solo en publicar un terminal. Esta operando el proyecto como un campo de pruebas para flujos de trabajo con agentes.

Warp es mas que un terminal

Los terminales tradicionales hacen principalmente tres cosas:

iniciar una shell;
ejecutar comandos;
mostrar salida.

La diferenciacion inicial de Warp era hacer que el terminal se sintiera mas moderno: bloques de comandos, autocompletado, historial, colaboracion, interacciones con estilo de UI y pulido multiplataforma. Ahora el foco se ha desplazado mas hacia organizar el desarrollo alrededor de agentes de IA.

Segun el README, Warp ya no enfatiza solo “un mejor terminal”. Enfatiza:

agentes de programacion integrados;
soporte para agentes CLI externos;
triage de issues;
escritura de especificaciones;
revision de PR;
coordinacion de contribuidores;
sesiones de agentes observables.

En otras palabras, Warp quiere convertir el terminal de “donde escribes comandos” en “donde trabajas con multiples agentes”.

Oz y gestion de proyectos open source

El README menciona Oz varias veces.

La vista de contribucion de Warp muestra miles de agentes Oz trabajando en triage de issues, especificaciones, implementacion y revision de PR. Esto es interesante porque extiende los agentes de IA desde “ayudar a una persona a escribir codigo” hasta “ayudar a gestionar colaboracion open source”.

La parte mas dificil de muchos proyectos open source no es escribir codigo, sino mantener:

demasiados issues y poca clasificacion;
bugs y feature requests mezclados;
nuevos contribuidores sin saber que tareas son abordables;
presion de revision de PR;
maintainers intentando seguir cada hilo de comunidad.

La idea de Warp es dejar que los agentes asuman primero parte del trabajo de gestion de proyecto y colaboracion. El README tambien menciona Oz for OSS, un programa orientado a maintainers para llevar flujos similares de gestion open source agentica a otros repositorios.

Esto sugiere que la ambicion de Warp no es solo el producto terminal, sino tambien un nuevo modelo de mantenimiento open source en la era de la IA.

Estructura del repositorio y stack tecnico

Por la estructura del repositorio, Warp es un proyecto Rust grande.

La raiz contiene:

app/: codigo principal de la aplicacion.
crates/: crates Rust centrales.
assets/: archivos de recursos.
command-signatures-v2/: contenido relacionado con firmas de comandos.
docker/, script/, resources/, specs/ y otros directorios de ingenieria.
.claude/, .warp/, .agents/skills y otras configuraciones relacionadas con agentes.

WARP.md aporta mas detalle de ingenieria. Describe Warp como un emulador de terminal basado en Rust que usa un framework de UI interno llamado WarpUI.

Los modulos principales pueden entenderse aproximadamente asi:

app/: emulacion de terminal, gestion de shell, integracion de IA, Drive, autenticacion, ajustes, workspace y sesiones.
crates/warp_core/: utilidades centrales y abstraccion de plataforma.
crates/editor/: funcionalidad de edicion de texto.
crates/warpui/ y crates/warpui_core/: framework de UI interno.
crates/ipc/: comunicacion entre procesos.
crates/graphql/: cliente GraphQL y esquema.

WARP.md tambien menciona rasgos arquitectonicos como:

un sistema Entity-Handle;
una estructura modular de workspace;
targets para macOS, Windows, Linux y WASM;
integracion de IA, incluyendo Agent Mode, conciencia de contexto e indexacion de codebase;
sincronizacion cloud Warp Drive.

Esta complejidad esta mas cerca de un IDE completo que de un terminal tradicional ligero.

Comandos de build local

El README da un flujo local conciso:

1
2
3

./script/bootstrap
./script/run
./script/presubmit

Donde:

./script/bootstrap realiza la inicializacion especifica de la plataforma.
./script/run compila y ejecuta Warp.
./script/presubmit ejecuta formato, clippy, tests y otras comprobaciones previas al envio.

WARP.md tambien lista comandos mas detallados:

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

Si quieres contribuir a Warp, ./script/presubmit es practicamente obligatorio.

Flujo de contribucion

El flujo de contribucion de Warp no es simplemente “abre un PR”.

El README describe un proceso ligero desde issue hasta PR:

Buscar primero issues existentes.
Si no hay duplicado, abrir un bug o feature request.
Los maintainers revisan el issue y pueden anadir etiquetas de preparacion.
ready-to-spec significa que el diseno puede expandirse en una especificacion.
ready-to-implement significa que el diseno esta lo bastante claro para empezar un PR de implementacion.
Los contribuidores pueden tomar issues etiquetados.

Este proceso encaja con un proyecto open source grande. Separa ideas, diseno e implementacion, reduciendo el riesgo de que los contribuidores pasen tiempo construyendo en una direccion equivocada.

Tambien encaja bien con agentes de IA. Un agente puede organizar issues, redactar specs, anadir tests y luego pasar a implementacion. Warp usa este patron para demostrar gestion de proyecto agentica.

Licencia: MIT + AGPL v3

Warp usa una estructura de doble licencia.

El README dice:

el framework de UI de Warp, concretamente los crates warpui_core y warpui, usa licencia MIT;
el resto del repositorio usa AGPL v3.

Esto importa. AGPL v3 tiene requisitos open source mas fuertes para servicios de red y distribucion. Si estas aprendiendo, investigando o contribuyendo, normalmente es sencillo. Pero si quieres usar codigo de Warp en un producto comercial o en un derivado closed-source, debes leer la licencia con cuidado y consultar asesoria legal si hace falta.

En resumen, Warp es open source, pero no es open source de “tomalo y cierralo libremente”.

Por que merece atencion

Primero, Warp une terminal, agentes y gestion de proyecto.

Muchas herramientas de programacion con IA siguen siendo CLI o plugins de editor. Warp parte del punto de entrada del terminal e intenta unificar tareas de agentes, ejecucion de codigo, salida de comandos, flujos de PR y colaboracion de equipo.

Segundo, el enfoque open source de Warp es un buen lugar para observar flujos con agentes.

No solo publica codigo. Tambien expone vistas de contribucion, sesiones de agentes, triage de issues y flujos de especificacion. Para cualquiera que estudie como la IA puede participar en colaboracion open source, el propio repositorio es una muestra.

Tercero, Warp es una aplicacion de escritorio Rust compleja.

Si quieres estudiar GUI en Rust, emulacion de terminal, apps multiplataforma, clientes GraphQL, sincronizacion cloud e integracion de IA, el repositorio tiene mucho que leer. Pero no es un proyecto pequeno, asi que los nuevos contribuidores deberian leer primero la documentacion y el proceso de issues.

Cuarto, Warp soporta tanto un agente integrado como un enfoque “trae tu propio agente CLI”.

Esto es realista. Los desarrolladores no usaran un solo agente. Claude Code, Codex, Gemini CLI, OpenCode, OpenClaw y herramientas similares probablemente coexistiran. Si Warp puede convertirse en un banco de trabajo para ellos, se vuelve mas valioso que un terminal de proposito unico.

A quien deberia importarle

Si eres un usuario normal de terminal, Warp importa porque el terminal puede estar cambiando de herramienta de linea de comandos a banco de trabajo con IA.

Si eres usuario intensivo de agentes de programacion con IA, Warp merece seguimiento porque intenta gestionar multiples agentes en vez de actuar como otro punto de entrada de chat.

Si mantienes proyectos open source, la direccion de Oz for OSS merece atencion. Explora triage de issues con agentes, revision de PR, colaboracion comunitaria e incorporacion de contribuidores.

Si eres desarrollador Rust, Warp es una aplicacion de escritorio real y de gran escala que merece estudiarse por organizacion de UI, internals de terminal, sincronizacion cloud, integracion de IA y codigo multiplataforma.

Si solo quieres un terminal que pueda reemplazar al actual de inmediato, es mejor descargar primero la version estable y despues decidir si estudiar el codigo fuente. Compilar desde codigo es mas adecuado para contribuidores y usuarios profundos.

Lectura breve

El punto de que Warp se vuelva open source no es simplemente “un terminal moderno se hizo open source”.

Mas precisamente, Warp intenta actualizar el terminal hasta convertirlo en un entorno de desarrollo agentico: el terminal conecta shell, codebase, ejecucion de comandos, agentes, issues, PRs y flujo de colaboracion.

A medida que los agentes de programacion con IA sigan creciendo, el punto de entrada del entorno de desarrollo puede cambiar. Antes, el IDE dominaba la experiencia del desarrollador mientras el terminal ejecutaba comandos. Ahora el terminal puede convertirse en el centro de colaboracion con agentes. El repositorio de Warp explora esa posibilidad.

Enlaces relacionados

GitHub repository: https://github.com/warpdotdev/warp
Warp website: https://www.warp.dev
Warp documentation: https://docs.warp.dev
Warp build overview: https://build.warp.dev
WARP.md: https://github.com/warpdotdev/warp/blob/master/WARP.md
CONTRIBUTING.md: https://github.com/warpdotdev/warp/blob/master/CONTRIBUTING.md

Primeros pasos con la compilación de programas UEFI: desde uefi-simple hasta su primer .EFI

Thu, 30 Apr 2026 19:53:08 +0800

Compilar su primer programa UEFI no es precisamente sencillo. La configuración del entorno puede llevar tiempo, los errores del vinculador son comunes y un programa .EFI no tiene la misma experiencia directa de edición y ejecución que una aplicación de escritorio normal.

Este artículo organiza el tema desde la perspectiva de un principiante: si sólo desea compilar su primer programa UEFI, ¿por dónde debería empezar, qué conceptos importan primero y qué errores es más probable que aparezcan?

¿Qué es un programa UEFI?

Un programa UEFI suele ser un archivo .EFI.

No es un .exe ordinario en el que se hace doble clic en Windows. Es un ejecutable PE/COFF que se ejecuta dentro del entorno de firmware UEFI. Los casos de uso comunes incluyen:

Gestores de arranque
Herramientas de inicialización de hardware.
Herramientas de actualización de firmware
Herramientas de diagnóstico previas al arranque
Flujos de arranque personalizados

Muchas funciones que ve al principio del proceso de inicio del sistema pueden estar relacionadas con aplicaciones, controladores o servicios de firmware UEFI.

Para los principiantes, no es necesario comprender inmediatamente el desarrollo completo del firmware. El primer objetivo es simple: compilar un archivo .EFI que pueda cargarse mediante un UEFI Shell o un emulador.

¿Por qué no empezar con EDK II?

El desarrollo real de UEFI a menudo implica EDK II.

EDK II es completo y más cercano a la ingeniería de firmware real, pero no es muy amigable para principiantes:

La estructura del proyecto es compleja.
El sistema de construcción tiene una curva de aprendizaje.
Las variables de entorno y la configuración de la cadena de herramientas implican muchos detalles.
Los errores del compilador no siempre son fáciles de entender.
Es fácil quedarse atascado en el entorno antes de escribir cualquier código.

Si el objetivo es simplemente ejecutar un programa UEFI mínimo, un ejemplo ligero es un mejor punto de partida.

pbatard/uefi-simple es uno de esos proyectos. Su objetivo es sencillo: proporcionar un ejemplo UEFI Hello World sencillo para que puedas compilar un archivo .EFI primero.

¿Para qué sirve `uefi-simple`?

uefi-simple es un buen primer paso para los principiantes en UEFI.

Resuelve tres problemas prácticos:

Le brinda una estructura de aplicación UEFI mínima y compilable.
Evita la complejidad de grandes proyectos de firmware al principio
Le permite verificar que compilar, vincular y ejecutar todo funciona.

El proyecto admite múltiples métodos de compilación, incluidos Visual Studio 2022 y MinGW/gcc. También se puede probar con QEMU y OVMF.

En otras palabras, no es necesario reiniciar repetidamente una máquina real para los primeros experimentos. Ejecutar primero el programa en un emulador es mucho más seguro.

Qué preparar antes de comenzar

Necesita al menos algunas categorías de herramientas.

La primera categoría es la cadena de herramientas del compilador.

En Windows, puedes comenzar con:

Estudio Visual 2022
O MinGW/gcc

La segunda categoría es un entorno de ejecución UEFI.

Hay dos opciones comunes:

Ejecute el archivo .EFI en UEFI Shell de una máquina real
Pruébalo en un entorno virtual con QEMU + OVMF

La tercera categoría es un proyecto de ejemplo.

Los principiantes no deberían empezar escribiendo scripts de compilación desde un directorio vacío. Usar un ejemplo mínimo como uefi-simple ayuda a evitar muchos problemas del sistema de compilación.

Flujo de trabajo básico

Un flujo de trabajo mínimo de un programa UEFI se puede entender así.

Primero, obtenga el proyecto de ejemplo.

`1`	`git clone https://github.com/pbatard/uefi-simple.git`

En segundo lugar, elija una cadena de herramientas de compilación. Si usa Visual Studio, cree con la solución Visual Studio en el proyecto.
Si usa MinGW/gcc, siga el Makefile o las instrucciones proporcionadas por el proyecto.

En tercer lugar, genere el archivo .EFI.

El punto clave aquí es confirmar la arquitectura de destino. Una PC común suele ser x86_64, es decir, un entorno UEFI de 64 bits.

Cuarto, coloque el archivo .EFI en algún lugar al que pueda acceder UEFI Shell.

En una máquina real, esto normalmente significa preparar una partición FAT32 o una unidad USB.
Con QEMU, puede montar un directorio o una imagen de disco.

Quinto, ejecútelo en UEFI Shell.

El resultado suele ser un resultado mínimo, como un mensaje estilo Hola mundo.

Donde los principiantes suelen quedarse estancados

La parte más difícil de compilar un programa UEFI no suele ser el lenguaje C en sí, sino el entorno y el proceso de vinculación.

Los problemas comunes incluyen:

Arquitectura de compilador incorrecta
Formato de destino incorrecto
Parámetros del enlazador incompletos
Falta el punto de entrada UEFI
Generar un ejecutable ordinario en lugar de un .EFI cargable por UEFI
QEMU u OVMF no configurados correctamente
Arranque seguro en una máquina real que bloquea un programa no firmado

Los errores del vinculador son especialmente fáciles de malinterpretar como problemas de código.
En muchos casos, el verdadero problema es la función de entrada, el subsistema, la arquitectura de destino o el script del vinculador.

Entonces, en la primera etapa, no se apresure a entrar en una lógica compleja. Asegúrese de que el ejemplo original se pueda compilar y ejecutar, luego cambie la salida poco a poco.

¿Por qué utilizar QEMU + OVMF para realizar pruebas?

Es posible probar programas UEFI en una máquina real, pero no es conveniente en la etapa principiante.

Es posible que tengas que repetir este ciclo:

compilar
Copiar a una unidad USB
Reiniciar
Ingrese al UEFI Shell
Ejecutar el programa
Registra el error
Regresar al sistema y modificar el código.

Ese bucle es lento.

QEMU + OVMF le permite simular un entorno UEFI directamente dentro del sistema operativo. Puede verificar si un archivo .EFI se carga más rápidamente y es menos probable que afecte sus entradas de arranque reales.

Una vez que el programa funciona básicamente, probarlo en una máquina real es mucho más manejable.

¿Qué deberían modificar primero los principiantes?

Si ya ha compilado su primer .EFI con el proyecto de ejemplo, no salte a funciones complejas de inmediato.

Un mejor orden es:

Cambie primero el texto de salida para confirmar que la recompilación realmente surte efecto.
Intente leer información sencilla proporcionada por UEFI.
Comprender la función de entrada, protocolo de salida y servicios básicos.
Luego considere funciones más complejas, como sistemas de archivos, salida gráfica o administración de entradas de arranque.

Este enfoque hace que cada paso sea verificable.
Si cambia demasiado a la vez, resulta difícil saber si el problema está en el código, el proceso de compilación o el entorno de ejecución.

¿En qué se diferencia de un programa C normal?

Aunque los programas UEFI se pueden escribir en C, su entorno de ejecución es completamente diferente al de los programas C normales.

Un programa C normal normalmente se ejecuta dentro de un sistema operativo y puede depender de la biblioteca, el sistema de archivos, el modelo de proceso y las llamadas al sistema estándar.

Un programa UEFI se ejecuta antes de que se inicie el sistema operativo. Se basa en los servicios proporcionados por el firmware UEFI. Muchas cosas a las que está acostumbrado en los programas normales no están disponibles aquí automáticamente. Al escribir programas UEFI, es necesario adaptarse a varias diferencias:

La función de entrada es diferente.
La salida funciona de manera diferente
Las bibliotecas disponibles son diferentes.
El acceso a la memoria y a los archivos funciona de forma diferente
La depuración funciona de manera diferente

Es por esto que partir de un ejemplo mínimo es mejor que escribir código como si fuera un programa C normal.

Un camino de aprendizaje práctico

Para principiantes, un camino realista es el siguiente:

Paso 1: compilar uefi-simple
Paso 2: Ejecútelo con QEMU + OVMF
Paso 3: Modificar la salida de Hola Mundo
Paso 4: Comprenda cómo UEFI Shell carga .EFI
Paso 5: aprenda la función de entrada UEFI y el protocolo de salida básico
Paso 6: Luego lea EDK II o material de desarrollo UEFI más completo

El objetivo de este camino es construir primero un circuito de retroalimentación que funcione.

Una vez que pueda generar un .EFI desde la fuente y ver el resultado en un entorno UEFI, ya habrá cruzado el primer umbral más difícil.

Referencias

-pbatard/uefi-simple

[Zhihu: material de compilación del programa UEFI] (https://zhuanlan.zhihu.com/p/643704056)

Pensamiento final

La parte difícil de compilar su primer programa UEFI generalmente no es escribir un poco de código C, sino conectar la cadena de herramientas, el formato de enlace y el entorno de ejecución.

No se apresure a utilizar funciones complejas.
Comience con un ejemplo mínimo como “uefi-simple”, obtenga primero un “.EFI” ejecutable y luego comprenda gradualmente los puntos de entrada, protocolos y métodos de compilación de UEFI.

Notas más recientes sobre la compilación desde el código fuente de GoAccess: desde la instalación del código fuente hasta los informes HTML en tiempo real

Wed, 29 Apr 2026 00:08:00 +0800

Esto está organizado para el 2026-04-29.
En este punto, la última versión estable que figura en el archivo README oficial es “1.10.2”.

1. Instale primero las dependencias de compilación

1
2
3

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

2. Descargue el paquete fuente más reciente

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2

3. Configurar las opciones de compilación

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib`

Si también desea compatibilidad con TLS para informes HTML en tiempo real:

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl`

4. Construir e instalar

1
2

sudo make
sudo make install

5. Verificar la versión

1
2

goaccess --version
which goaccess

6. Ver informes directamente en la terminal

Para registros combinados comunes de Nginx o Apache:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED`

Si la ruta del registro es Apache:

`1`	`goaccess /var/log/apache2/access.log --log-format=COMBINED`

7. Generar un informe HTML estático

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html

También puedes escribirlo en el directorio actual:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o report.html

8. Genere un informe HTML en tiempo real

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

Para cambiar el puerto:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --port=7891

Para vincularse solo a localhost:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --addr=127.0.0.1

9. Siga los registros continuamente

`1`	`tail -f /var/log/nginx/access.log \| goaccess --log-format=COMBINED -`

Desde el principio del archivo y mantenlo activo:

tail -f -n +0 /var/log/nginx/access.log | goaccess \
  --log-format=COMBINED \
  -o report.html \
  --real-time-html -

10. Mire solo ciertas solicitudes

Por ejemplo, solo solicitudes que contengan firefox:

1
2

tail -f /var/log/nginx/access.log | grep -i --line-buffered 'firefox' | goaccess \
  --log-format=COMBINED -

Por ejemplo, sólo 5xx y 3xx:

1
2
3

tail -f -n +0 /var/log/nginx/access.log | awk '$9~/3[0-9]{2}|5[0-9]{2}/' | goaccess \
  --log-format=COMBINED \
  -o out.html -

11. Analizar varios registros juntos

`1`	`goaccess /var/log/nginx/access.log /var/log/nginx/access.log.1 --log-format=COMBINED`

Lea registros comprimidos y sin comprimir juntos:

`1`	`zcat --force /var/log/nginx/access.log* \| goaccess --log-format=COMBINED -`

12. Habilitar subprocesos múltiples

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4

Aumentar el tamaño del trozo:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4 \
  --chunk-size=8192

13. Procesamiento incremental

Primero persista en un registro antiguo:

`1`	`goaccess /var/log/nginx/access.log.1 --log-format=COMBINED --persist`

Luego agregue el registro actual:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED --restore --persist`

Solo lectura de datos persistentes:

`1`	`goaccess --restore`

14. El conjunto de comandos que ejecutaría primero

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2
sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl
sudo make
sudo make install

goaccess --version

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

Básicamente eso es todo.
Si su objetivo es claro, instalar la última versión fuente y hacer que --log-format=COMBINED más --real-time-html funcione primero suele ser suficiente. Después de eso, la mayoría de los cambios se refieren solo a rutas de registro, archivos de salida y puertos.

Cree imágenes de Docker en VS Code en Windows: desde la configuración hasta la compilación

Thu, 16 Apr 2026 10:20:00 +0800

Si desea crear imágenes de Docker directamente desde VS Code en Windows, el flujo de trabajo es sencillo. Solo necesitas tres partes: preparar el entorno, crear un Dockerfile y luego ejecutar la compilación.

01 Requisitos previos

Asegúrese de que estos dos elementos estén listos:

Instale y ejecute Docker Desktop.
Instale la extensión oficial de Microsoft Docker en VS Code.

En Windows, usar el backend WSL 2 en Docker Desktop (Configuración > Recursos > Integración WSL) suele ser más estable y rápido.

02 Preparar un archivo Docker

Si tu proyecto aún no tiene uno, VS Code puede generarlo:

Abra la carpeta de su proyecto en VS Code.
Presione F1 o Ctrl+Shift+P para abrir la paleta de comandos.
Ejecute Docker: Agregar archivos Docker al espacio de trabajo.
Elija su plataforma (Node.js, Python, .NET, etc.) y siga las indicaciones.

Normalmente obtendrá al menos:

-Dockerfile

.dockerignore

Esto le proporciona una base de trabajo que podrá perfeccionar más adelante.

03 Tres Maneras de Construir la Imagen

Método A: haga clic con el botón derecho en Dockerfile

En el Explorador de archivos, haga clic derecho en “Dockerfile”, seleccione “Crear imagen…” e ingrese una etiqueta de imagen.

Método B: Paleta de comandos

Presione F1, ejecute Docker: Build Image, luego seleccione el contexto y la etiqueta.

Método C: Terminal integrado

`1`	`docker build -t your-image-name .`

Este comando crea una imagen a partir del contexto del directorio actual con la etiqueta tu-nombre-de-imagen.

04 Comprobaciones rápidas para problemas comunes

Docker Desktop no se está ejecutando: verifique que esté iniciado.
La compilación es muy lenta: verifique si el backend de WSL 2 está habilitado.
La compilación no puede encontrar archivos: asegúrese de que su terminal esté en la raíz del proyecto y que los archivos estén dentro del contexto de compilación.
Los recursos de Docker no se muestran en VS Code: reinicie VS Code y verifique Docker CLI (versión de Docker).

Resumen

La creación de imágenes de Docker en VS Code en Windows es principalmente un problema de configuración. Una vez que Docker Desktop y la extensión VS Code Docker estén implementados, puede generar archivos Docker rápidamente y crear imágenes desde la interfaz de usuario o el terminal.

Guía de recursos CH347: controladores, herramientas y programación SPI Flash

Fri, 03 Apr 2026 10:00:00 +0800

Esta publicación resume los recursos de CH347 que uso con más frecuencia, con un objetivo: pasar de la configuración a la depuración/programación lo más rápido posible.

Si es nuevo en CH347, prepare su entorno en este orden:

Consulte primero la página oficial del producto.
Instale el controlador correcto para su caso de uso
Prepare una herramienta SPI Flash y verifique la conectividad

Entrada oficial

Página del producto CH347: https://www.wch.cn/products/CH347.html

Es mejor descargar primero desde la página oficial para evitar paquetes de controladores obsoletos o de origen desconocido.

Controladores comunes

1) `CH341PAR.EXE`

Propósito:

Controlador de interfaz USB a JTAG / SPI / I2C / Paralelo / GPIO

Uso típico:

Comunicación multiprotocolo y depuración de interfaz de bajo nivel con CH347

2) `CH343SER.EXE`

Propósito:

Controlador de Windows del proveedor para USB a serie de alta velocidad

Uso típico:

Utilizar CH347 principalmente como herramienta en serie, especialmente a velocidades de baudios más altas

Herramienta de programación SPI Flash

ComoProgramador: https://github.com/nofeletru/UsbAsp-flash

Tareas comunes:

Detectar SPI NOR Flash
Leer identificación del chip
Copia de seguridad del firmware original
Borrar / escribir / verificar firmware

Flujo de trabajo recomendado (para evitar errores comunes)

Después de instalar los controladores, vuelva a conectar el dispositivo y confirme la detección en el Administrador de dispositivos.
Antes de escribir por primera vez, realice una lectura completa + copia de seguridad del contenido original.
Ejecute siempre verificar después de escribir. No confíe únicamente en un mensaje de “escritura exitosa”.
Si no se detecta el chip, verifique la alimentación, el nivel de voltaje y el cableado antes de verificar la configuración del software.

Solución rápida de problemas

El dispositivo está enchufado pero no es visible en las herramientas: generalmente hay problemas de carga del controlador o un cable USB de solo alimentación.
Se detecta el dispositivo pero falla la lectura/escritura: primero verifique el orden del cableado, la tierra compartida y la estabilidad de la energía.
Comportamiento inestable a alta velocidad: primero reduzca la velocidad de lectura/escritura y luego aumente gradualmente una vez confirmada la estabilidad.

Resumen

CH347 no es difícil de usar. La clave es hacer bien cuatro cosas: controlador, herramienta, cableado y verificación.

Los recursos anteriores cubren la mayoría de los escenarios de mantenimiento diarios y para principiantes, y deberían permitirle alcanzar rápidamente un flujo de trabajo estable.

Explicación de FFmpeg `-map`: seleccione con precisión transmisiones de video, audio y subtítulos

Thu, 02 Apr 2026 23:14:03 +0800

En flujos de trabajo de múltiples audios y subtítulos, -map es una de las opciones más importantes y más frecuentemente mal utilizadas de FFmpeg.

Si no especifica explícitamente -map, FFmpeg selecciona automáticamente las transmisiones usando reglas predeterminadas y, a menudo, el resultado no es el esperado. Por ejemplo:

Los subtítulos desaparecen después de la exportación.
Se seleccionó la pista de idioma incorrecta
Se incluyen flujos de datos no deseados.

Este artículo utiliza escenarios comunes del mundo real para explicar cómo funciona “-map”.

Primero, comprenda qué es una “transmisión”

Un archivo contenedor (como mp4 o mkv) generalmente contiene múltiples secuencias, que incluyen:

Secuencias de vídeo (v)
Flujos de audio (a)
Secuencias de subtítulos (s)
Archivos adjuntos/flujos de datos (fuentes, portadas, capítulos, etc.)

Puedes inspeccionar transmisiones con ffprobe:

`1`	`ffprobe -hide_banner input.mkv`

Sintaxis básica de `-map`

Patrón más común:

`1`	`-map input_index[:stream_type][:stream_index]`

Ejemplos:

0:v: todas las transmisiones de video desde la primera entrada
0:a:0: la primera secuencia de audio desde la primera entrada
1:s:1: la segunda secuencia de subtítulos desde la segunda entrada

Notas:

input_index comienza desde 0, según el orden -i
stream_index también comienza desde 0

Ejemplos prácticos

1) Vídeo de A, audio de B

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0:v:0 -map 1:a:0 \
  -c:v copy -c:a aac \
  french.mp4

Significado:

Utilice la primera transmisión de video de english.mp4
Utilice la primera secuencia de audio de french.mp3
Fusionar en french.mp4

2) Mantenga todas las transmisiones desde la entrada 1, luego agregue una pista de audio más

ffmpeg -i english.mp4 -i french.mp3 \
  -map 0 -map 1:a:0 \
  -c copy \
  english-french.mp4

Significado:

-map 0 mantiene todas las transmisiones desde la primera entrada
Luego agregue la primera secuencia de audio de la segunda entrada.

Dos trucos avanzados útiles

1) Mapeo negativo: excluye transmisiones no deseadas

Por ejemplo, mantenga todo lo de la entrada 1 pero elimine su segunda secuencia de audio:

`1`	`ffmpeg -i input.mkv -map 0 -map -0:a:1 -c copy output.mkv`

2) Mapeo opcional: no falle cuando falte una transmisión

Si es posible que algunos archivos no tengan subtítulos, utilice ?:

`1`	`ffmpeg -i input.mp4 -map 0:v -map 0:a -map 0:s? -c copy output.mp4`

0:s? significa: subtítulos del mapa si están presentes; de lo contrario, salte sin error.

Errores comunes

Una vez que usa -map, FFmpeg detiene la selección automática de secuencias, por lo que debe mapear todo lo que necesita.
-c copy solo remuxes sin transcodificación. Si el contenedor de destino no admite un códec, igualmente falla.
Con múltiples entradas, los errores de índice son comunes. Los índices de entrada están determinados únicamente por el orden “-i”.
Para scripts robustos, inspeccione primero con ffprobe y luego genere -map dinámicamente.

Resumen

La idea central de -map es simple: decirle explícitamente a FFmpeg qué entrada usar, qué tipo de flujo elegir y qué índice de flujo seleccionar.

Una vez que domine esto, podrá manejar de manera confiable casos complejos como composición de múltiples audios, múltiples subtítulos y transmisiones entre archivos.

Cómo solucionar problemas de uso elevado de CPU de VS Code causado por extensiones

Wed, 01 Apr 2026 00:00:00 +0000

Cuando VS Code de repente se siente lento, el ventilador gira y el uso de la CPU se mantiene alto, la causa más común generalmente no es el editor en sí, sino conflictos de extensiones o un comportamiento anormal de las extensiones.

Esta guía le brinda un flujo de trabajo directo y práctico para identificar el problema rápidamente.

Comience con el método más rápido: iniciar la extensión en bisección

Start Extension Bisect utiliza un enfoque de búsqueda binaria: En cada ronda, VS Code desactiva temporalmente la mitad de tus extensiones y se reinicia. Según si el problema persiste, reduce rápidamente la lista de sospechosos.

Pasos:

Presione Ctrl+Shift+P (macOS: Cmd+Shift+P) para abrir la paleta de comandos.
Ejecute Iniciar extensión bisect.
Después de cada reinicio, verifique si todavía hay un uso elevado de la CPU y un retraso, luego elija “Bien ahora” o “Esto es malo”.
Después de varias rondas, VS Code mostrará las extensiones probablemente problemáticas.

Qué hacer después de encontrar al sospechoso

Una vez que identifique la extensión, manéjela en este orden:

Actualice la extensión a la última versión.
Si el problema persiste, desactívelo durante 1 o 2 días y observe.
Si existen alternativas, cambie a una extensión más ligera.
Si debe conservarlo, revise la configuración avanzada y desactive las funciones innecesarias de análisis, indexación o visualización de archivos en tiempo real.

Dos “amplificadores” comunes que quizás pases por alto

Incluso si una extensión es la causa principal, estas configuraciones pueden amplificar la carga de la CPU:

El alcance de la búsqueda es demasiado amplio
Si los resultados de la compilación, las carpetas de dependencia y los registros se incluyen en la búsqueda global, las extensiones y los indexadores pueden permanecer bajo una carga pesada y continua.
La visualización de archivos incluye carpetas o enlaces simbólicos enormes
Los enlaces simbólicos, los directorios de caché y las carpetas generadas pueden desencadenar una gran cantidad de eventos de archivos y forzar que las extensiones se reprocesen repetidamente.

Puede recortar el alcance en settings.json, por ejemplo:

{
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true
  },
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true
  }
}

Consejo post mortem

Después de aislar el problema, registre tres cosas: nombre de la extensión, escenario desencadenante y solución final.
Esa nota le ahorrará tiempo cuando migre su entorno o reconstruya su máquina más adelante.

Resumen

Para un uso elevado de CPU de VS Code, la ruta más eficaz es utilizar primero “Iniciar extensión Bisect” y luego ajustar el alcance de búsqueda y observación de archivos.
Localice primero, optimice en segundo lugar. Es más rápido y confiable que deshabilitar aleatoriamente muchas extensiones.

Herramientas de desarrollo on KnightLi Blog

Cómo cambiar el idioma de la interfaz de VS Code: chino, inglés y otros idiomas

Instalar el paquete de idioma correspondiente

Cambiar el idioma desde la paleta de comandos

Especificar el idioma manualmente en argv.json

Códigos de idioma de interfaz comunes

Qué hacer si el idioma no cambia

Referencias

opencode, Claude Code y Codex: diferencias y guía de herramientas open source de programación con IA

Para quién es opencode

Instalación

La app de escritorio sigue en Beta

Dos modos Agent integrados

Qué es Codex

Diferencias principales

Diferencias con Claude Code

Cuándo elegir opencode, Claude Code o Codex

Puntos a tener en cuenta

Referencias

Guía de instalación de uv: cómo elegir entre macOS, Linux, Windows, pipx, Homebrew y WinGet

Elección rápida

macOS y Linux: instalador oficial

Windows: instalador de PowerShell

Instalar con pipx

Homebrew, MacPorts, WinGet y Scoop

Docker, GitHub Releases y Cargo

Actualizar uv

Activar autocompletado de shell

Desinstalar uv

Qué hacer después de instalar

Mi recomendación

Enlaces relacionados

Awesome Codex Skills: un catalogo comunitario para ampliar Codex CLI

Que resuelve este repositorio

En que se diferencia de un prompt

Instalacion y uso

Que skills merece la pena observar

Puntos de cuidado

Mi lectura

Warp Open Source: de terminal a entorno de desarrollo agentico

Estado actual del repositorio

Warp es mas que un terminal

Oz y gestion de proyectos open source

Estructura del repositorio y stack tecnico

Comandos de build local

Flujo de contribucion

Licencia: MIT + AGPL v3

Por que merece atencion

A quien deberia importarle

Lectura breve

Enlaces relacionados

Primeros pasos con la compilación de programas UEFI: desde uefi-simple hasta su primer .EFI

¿Qué es un programa UEFI?

¿Por qué no empezar con EDK II?

¿Para qué sirve uefi-simple?

Qué preparar antes de comenzar

Flujo de trabajo básico

Donde los principiantes suelen quedarse estancados

¿Por qué utilizar QEMU + OVMF para realizar pruebas?

¿Qué deberían modificar primero los principiantes?

¿En qué se diferencia de un programa C normal?

Un camino de aprendizaje práctico

Referencias

Pensamiento final

Notas más recientes sobre la compilación desde el código fuente de GoAccess: desde la instalación del código fuente hasta los informes HTML en tiempo real

1. Instale primero las dependencias de compilación

2. Descargue el paquete fuente más reciente

3. Configurar las opciones de compilación

4. Construir e instalar

5. Verificar la versión

6. Ver informes directamente en la terminal

7. Generar un informe HTML estático

8. Genere un informe HTML en tiempo real

9. Siga los registros continuamente

10. Mire solo ciertas solicitudes

11. Analizar varios registros juntos

12. Habilitar subprocesos múltiples

13. Procesamiento incremental

14. El conjunto de comandos que ejecutaría primero

Cree imágenes de Docker en VS Code en Windows: desde la configuración hasta la compilación

¿Para qué sirve `uefi-simple`?

1) `CH341PAR.EXE`

2) `CH343SER.EXE`

Sintaxis básica de `-map`