Xinuos reactiva en corte su disputa histórica contra IBM por la propiedad de Unix. npm 12 bloquea por defecto los scripts de instalación. NVIDIA prueba un formato de firmware pensado para su driver Nova escrito en Rust.
La segunda versión preliminar de npm 12, publicada el 29 de junio, ya bloquea los scripts que dispararon los mayores ataques a la cadena de suministro de JavaScript en los últimos dos años.
npm publicó el 29 de junio de 2026 la versión 12.0.0-pre.2, según el registro de cambios oficial de GitHub. La actualización desactiva por defecto los scripts `preinstall`, `install` y `postinstall` que corren automáticamente al instalar una dependencia, y bloquea salvo activación explícita con las banderas `--allow-git` y `--allow-remote` las dependencias que apuntan a repositorios Git o a URLs remotas. La versión estable de npm 12 tiene fecha firme para julio de 2026, aunque GitHub no publicó todavía el día exacto de lanzamiento. El cambio responde directamente a incidentes como el ataque a Nx en agosto de 2025, donde un token de publicación robado permitió distribuir versiones maliciosas con un script `postinstall` que robaba tokens de GitHub, credenciales de npm, llaves SSH y billeteras cripto, y a la campaña de más de 170 paquetes comprometidos que esta misma edición cubrió el 2 de julio. No todos celebran el cambio sin reservas. NodeSource publicó un análisis titulado "Blocking Install Scripts Is Not a Silver Bullet", donde advierte que bloquear scripts no resuelve el problema de fondo: la toma de cuentas de mantenedores. Si un atacante controla las credenciales legítimas de un mantenedor, el código malicioso se publica como una versión firmada y confiable, y ningún bloqueo de scripts lo detiene. Cybernews recogió críticas similares de otros investigadores de seguridad bajo el título "Experts say it's not enough". Los equipos de DevOps en zonas francas y empresas de outsourcing en Costa Rica —que ya empezaron a auditar sus pipelines tras el incidente de julio— deben ahora además activar explícitamente los scripts legítimos que sus builds necesitan antes de que el bloqueo definitivo llegue con la versión estable.
cat /feed/kernelrust.md
> El ingeniero Timur Tabi, de NVIDIA, publicó el 5 de julio de 2026 parches que migran el firmware del driver Nova-Core hacia un nuevo formato binario Tag-Length-Value (TLV), según reportó Phoronix. Nova-Core es el controlador experimental de código abierto para GPUs de NVIDIA escrito en Rust, y el nuevo formato busca ser más fácil de analizar desde ese código, que impone verificaciones de tipos y de límites de memoria más estrictas que el C usado en los drivers propietarios de la compañía.
> Un script llamado `extract-firmware-nova.py` genera los archivos TLV a partir de las imágenes de firmware originales de NVIDIA, empaquetando cada pieza de metadata por separado para que el driver la recorra como una secuencia de campos tag/length/value. El formato todavía está en iteración y Phoronix no reportó fecha de fusión a la rama principal del kernel Linux.
> Nova es el intento más ambicioso de reemplazar el módulo propietario `nvidia.ko` con una implementación abierta y segura en memoria, en la misma línea que llevó a los mantenedores del kernel a declarar en 2025 que Rust "llegó para quedarse". Sin impacto local conocido al cierre de esta edición: el desarrollo de drivers de kernel es un nicho muy reducido en Costa Rica, aunque el grupo Rust CR —mencionado en ediciones anteriores de El Pisuika— sigue de cerca el avance de Nova en sus reuniones mensuales.
Xinuos, la sucesora legal de SCO Group, reabrió en una corte de Estados Unidos el reclamo de dos décadas contra IBM sobre quién es el dueño real del código de Unix.
Xinuos, la empresa que heredó los derechos de litigio de SCO Group, alcanzó el 22 de junio de 2026 un nuevo hito en su demanda contra IBM ante el Tribunal de Distrito de EEUU para las Islas Vírgenes, según reportó The Register el 6 de julio. La demanda acusa a IBM y a Red Hat de usar código de Unix copiado indebidamente y de incurrir en conducta anticompetitiva para dominar el mercado de sistemas operativos de servidor tipo Unix y Linux. La raíz del caso está en la alianza de 1998 entre IBM y Santa Cruz Operation (SCO), junto con Intel y Sequent, para crear el "Proyecto Monterey": un esfuerzo por construir una versión unificada de Unix capaz de correr en múltiples arquitecturas de procesador. Hacia 2001, ese proyecto estaba cerca de entregar una versión que mezclaba código de IBM y de SCO. Xinuos argumenta que IBM nunca tuvo licencia para usar ese código de SCO; IBM sostiene que no hizo nada indebido. El punto que definirá el caso, según The Register, ni siquiera es de fondo: es si Xinuos todavía tiene derecho legal a litigar el asunto, dado que cláusulas del acuerdo original podrían haber vencido el plazo para reclamar. El caso revive uno de los pleitos más largos de la historia del software libre —la saga SCO contra Linux de los años 2000, que muchos daban por cerrada tras la quiebra de SCO Group en 2007—. IBM mantiene en Heredia, Costa Rica, uno de sus mayores centros de servicios compartidos y desarrollo fuera de Estados Unidos; el litigio se ventila en una corte estadounidense y no representa, al cierre de esta edición, una exposición operativa directa para esa sede, pero firmas costarricenses que ofrecen soporte y migración de sistemas Linux para clientes en EEUU siguen el caso de cerca por la incertidumbre que reabre sobre licenciamiento de código heredado.
Un desarrollador reabrió el 29 de junio de 2026 un reclamo antiguo en el repositorio oficial `dotnet/core` de GitHub, registrado como el issue #10448, según reportó The Register. El planteamiento: la ventana de soporte a largo plazo (LTS) de .NET —tres años para las versiones pares— es demasiado corta para los ciclos reales de adopción de las empresas. .NET 8 y .NET 9 llegan a su fin de soporte el 10 de noviembre de 2026, según el blog oficial de .NET. Bajo la política vigente, Microsoft alterna una versión LTS de tres años con una versión de soporte estándar (STS) de dos años, en lanzamientos anuales. El issue señala que ese calendario queda corto frente a Java —cinco años de soporte más extensiones— y Python —cinco años de parches de seguridad para cada versión—, lo que obliga a empresas con bases de código grandes a actualizar con más frecuencia de la que permiten sus ciclos de pruebas, certificación y presupuesto, sobre todo cuando hay dependencias de terceros que también deben moverse de versión. Microsoft no había respondido públicamente al reclamo reabierto al cierre de esta edición. La discusión llega mientras el ecosistema se prepara para .NET 11 —cuyo lanzamiento final se cubrió en la edición del 3 de julio de El Pisuika—, lo que sumaría una versión mayor más al calendario de mantenimiento. Para el sector bancario y de servicios compartidos en Costa Rica, donde .NET tiene presencia fuerte según ediciones anteriores, cada ventana de soporte más corta significa horas de ingeniería adicionales para certificar cada migración a tiempo.
— Un ingeniero reabrió en GitHub el reclamo de que tres años de soporte no alcanzan para los ciclos de actualización de las empresas que usan .NET.
Databricks presentó LTAP (Lake Transactional/Analytical Processing) en su Data + AI Summit del 16 de junio de 2026, una arquitectura que promete unificar cargas transaccionales (OLTP) y analíticas (OLAP) sobre una sola copia de almacenamiento en el lake, según el blog oficial de la compañía. El componente transaccional se apoya en Lakebase, la base de datos PostgreSQL totalmente administrada de Databricks construida sobre tecnología de Neon —adquirida en 2025—, que ya procesa 12 millones de arranques de base de datos por día en la plataforma. El diseño evita el patrón tradicional de duplicar datos con pipelines de captura de cambios (CDC) hacia un almacén analítico separado: los datos operativos se guardan una sola vez en formatos columnares abiertos tipo Parquet, que tanto Postgres como el motor de Lakehouse leen directamente. Según Databricks, eso permite que las consultas analíticas corran sobre los mismos datos que una transacción acaba de escribir, sin retraso ni segunda copia. The Register, en su cobertura del 3 de julio, cuestionó esa promesa de "una sola copia": según su análisis, Lakebase mantiene una capa de caché transaccional distinta de la representación columnar final, por lo que la unificación depende de qué se defina técnicamente como copia y qué como una transcodificación derivada. Para los equipos de datos costarricenses que atienden clientes bancarios y de telecomunicaciones —sector donde Databricks ya tiene despliegues regionales—, la promesa de eliminar ETL es atractiva, pero migrar arquitecturas OLTP tradicionales hacia Lakebase exige revisar de cerca esa letra pequeña.
Supabase discontinuó el soporte de Postgres 14 el 1 de julio de 2026, según su registro oficial de cambios. Los proyectos que seguían en esa versión fueron actualizados automáticamente a la versión de Postgres más reciente disponible en la plataforma; los que dependen de extensiones ya no soportadas quedaron pausados y dejaron de servir tráfico. La semana del 6 de julio, Supabase cambia además la configuración por defecto de `API_EXTERNAL_URL` en instalaciones autoalojadas para incluir el prefijo `/auth/v1` —de `http://localhost:8000` pasa a `http://localhost:8000/auth/v1`—, alineando ese comportamiento con la plataforma administrada y su CLI. La variable `GOTRUE_JWT_ISSUER` y las rutas de inicio de sesión único con SAML también cambian de dirección, lo que puede romper integraciones que codificaron URLs de forma manual. En paralelo, la compañía introdujo Multigres v0.1 alpha, un "sistema operativo" de código abierto para Postgres que gestiona sharding, connection pooling y failover automático, tras cerrar en junio una ronda Serie F de 500 millones de dólares. Para las startups costarricenses que usan Supabase como backend —una combinación común con Next.js y Vercel dentro de la comunidad de desarrollo local—, la salida de Postgres 14 y el cambio de URL obligan a revisar variables de entorno antes de que cierre la ventana de julio.
La primera semana completa de julio de 2026 conecta tres hilos que parecen ajenos entre sí pero comparten un mismo trasfondo: la tensión entre lo heredado y lo nuevo en el software de infraestructura. Xinuos reabrió en corte estadounidense una disputa de veinte años sobre quién es dueño del código de Unix, recordando que las decisiones de licenciamiento tomadas en los años noventa todavía pueden litigarse hoy. NVIDIA, mientras tanto, sigue empujando Rust hacia territorio antes reservado a C en el kernel Linux, con un nuevo formato de firmware para su driver Nova. Y npm 12 empieza a cerrar, por defecto, la puerta que los atacantes de cadena de suministro más han usado en los últimos dos años. El hilo conductor para los equipos de desarrollo es la gestión de deuda técnica y de riesgo heredado: contratos de licenciamiento de hace dos décadas, drivers de kernel que todavía dependen de binarios propietarios, y un ecosistema de paquetes que sigue confiando por defecto en scripts que se ejecutan sin supervisión. Ninguno de los tres frentes se resuelve esta semana, pero los tres avanzan. Para los equipos costarricenses de tecnología —desde los centros de servicios compartidos de multinacionales como IBM en Heredia hasta las startups que corren su backend en Supabase—, julio de 2026 llega con una misma lección: la infraestructura que se da por sentada, ya sea un contrato legal de 1998 o un script de instalación de npm, es la que más silenciosamente acumula riesgo.