Windows para el escritorio, Linux para ejecutar

El punto de partida era bastante corriente: preparar un equipo de trabajo basado en Windows que iba a utilizarse para desarrollo, pero que debía seguir sirviendo también para otras tareas profesionales. No se trataba de construir una estación dedicada exclusivamente a programar ni de llenar el sistema de herramientas técnicas, sino de incorporar un entorno de desarrollo sin convertirlo en el centro de todo lo demás.

Al principio, las decisiones parecían las habituales: instalar un editor, configurar Git y preparar una base desde la que trabajar. Pero en cuanto apareció la necesidad de utilizar herramientas y proyectos cuyo entorno natural era Linux, la pregunta dejó de ser qué más había que instalar y pasó a ser otra bastante más interesante: qué responsabilidad debía asumir Windows y cuál debía asumir Linux.

WSL permitía incorporar un entorno Linux sin sustituir el sistema principal, pero eso no resolvía automáticamente cómo organizarlo. Podíamos utilizarlo como una terminal adicional, intentar reproducir dentro de él todas las herramientas que ya existían en Windows o repartir responsabilidades de una forma más deliberada.

La tercera opción terminó siendo la más útil.

Linux como entorno, no como terminal auxiliar

Una de las primeras decisiones importantes fue no convertir la incorporación de WSL en una migración encubierta.

Windows seguía teniendo sentido como entorno de escritorio. El editor gráfico y las aplicaciones de trabajo podían continuar allí. Linux, en cambio, podía asumir terminal, herramientas de línea de comandos, runtimes y proyectos cuyo ecosistema natural fuese Linux.

Visual Studio Code encajó especialmente bien en esa separación. La interfaz sigue ejecutándose en Windows, pero al abrir un proyecto dentro de WSL el servidor del editor, la terminal, Git, los runtimes y el filesystem pueden pertenecer realmente a Linux.

Eso evita una ambigüedad bastante frecuente. Ver una ventana de una aplicación Windows no significa necesariamente que el proyecto esté ejecutándose en Windows.

Cuando todo funciona, esa frontera casi desaparece. Cuando algo falla, saber dónde se encuentra cada pieza resulta mucho más importante.

Dos instalaciones de Git no son necesariamente una duplicación

La incorporación de WSL produjo una situación que inicialmente puede parecer redundante: Git estaba instalado tanto en Windows como en Linux.

Pero un repositorio trabajado desde Windows y otro que vive dentro de Linux no tienen por qué depender de la misma instalación. Cada Git pertenece a su entorno y mantiene su propia configuración.

La cuestión entonces no era conseguir que ambas instalaciones fueran idénticas, sino decidir qué debía ser coherente entre ellas.

La identidad utilizada en los commits o determinadas políticas de trabajo pueden representar decisiones comunes. Otras opciones dependen por completo del sistema operativo y no tiene sentido trasladarlas de un entorno al otro.

Esa diferencia evitó copiar configuraciones enteras simplemente porque ya habían funcionado antes.

Compartir una política no obliga a compartir todo el estado.

La misma idea se aplicó a las credenciales. Si una capacidad ya estaba resuelta en el sistema anfitrión y podía reutilizarse limpiamente desde Linux, no había una razón inmediata para introducir otro mecanismo independiente únicamente porque ahora existiera un segundo entorno.

El proyecto debería vivir donde realmente se trabaja con él

WSL permite acceder al filesystem de Windows con facilidad, así que técnicamente es posible mantener allí los repositorios y utilizar herramientas Linux sobre ellos.

Pero que algo sea posible no significa que sea siempre la ubicación más natural.

Cuando un proyecto utiliza principalmente herramientas Linux, se prueba dentro de Linux y depende de runtimes Linux, mantener también el repositorio en ese entorno simplifica bastante las cosas. Filesystem, Git, terminal y runtime dejan de cruzar constantemente la frontera entre sistemas.

No es una regla universal. Hay proyectos que pueden tener buenas razones para permanecer en Windows.

La pregunta útil es otra: ¿dónde vive realmente este proyecto?

No necesariamente donde sea más cómodo encontrar su carpeta, sino donde se construye, se ejecuta y se mantiene.

Configurar no es comprobar

Durante la preparación del entorno apareció además una diferencia que después ha resultado útil en muchos otros contextos: seleccionar una opción o escribir una configuración no demuestra todavía que el sistema esté utilizando exactamente eso.

Puede existir una opción más específica, otra instalación de la herramienta o un repositorio con configuración propia. En un entorno híbrido, además, una misma interfaz puede ocultar que el comando termina ejecutándose en un sistema diferente al que imaginábamos.

Por eso cada capa se fue validando antes de añadir la siguiente.

Primero se comprobó el funcionamiento local del entorno inicial. Después la interacción con los repositorios remotos. Más tarde se incorporó Linux y se repitieron las validaciones desde allí.

Ese orden tenía una ventaja sencilla: si algo nuevo fallaba, ya sabíamos qué parte anterior funcionaba correctamente.

También permitió utilizar pruebas que no modificasen estado real cuando existían. Si únicamente queremos comprobar que una operación podría realizarse, una simulación resulta más limpia que introducir un cambio solo para borrarlo después.

No es una técnica específica de Windows o WSL. Es simplemente una forma de reducir variables durante el diagnóstico.

El entorno creció cuando apareció una necesidad

Otra consecuencia de trabajar por capas fue que muchas herramientas quedaron fuera del entorno inicial.

No porque fueran malas opciones, sino porque todavía no resolvían ningún problema concreto.

Contenedores, nuevos mecanismos de acceso, runtimes adicionales o capas de infraestructura podían añadirse más adelante si algún proyecto los requería. Instalarlos desde el principio habría aumentado capacidad, pero también configuración, estado y mantenimiento antes de saber si iban a resultar necesarios.

Esta parte del proceso terminó cambiando bastante la forma de preparar entornos nuevos.

En lugar de intentar anticipar todo lo que podría hacer falta, resulta más fácil empezar con una base pequeña, utilizarla y permitir que sean los proyectos reales los que justifiquen la siguiente capa.

La arquitectura final puede acabar siendo igual de sofisticada, pero cada componente llega acompañado de una razón para existir.

Una integración buena no elimina todas las fronteras

Al final, el entorno resultante no consistía en tener Windows y Linux haciendo las mismas cosas.

Windows conservaba las responsabilidades que encajaban con el escritorio. Linux asumía las herramientas y proyectos que necesitaban un entorno Linux. El editor conectaba ambas capas y algunas decisiones se mantenían coherentes entre ellas, pero no se intentó ocultar que seguían siendo sistemas distintos.

Eso terminó siendo una ventaja.

Cuando las fronteras son claras resulta más fácil saber qué Git se está utilizando, dónde vive el proyecto, qué runtime lo ejecuta y qué configuración pertenece a cada entorno.

La integración deja de significar que todo parezca una única cosa y empieza a significar que las distintas partes colaboran sin confundirse.

El aprendizaje estaba en la separación

El objetivo inicial era bastante práctico: disponer de un entorno desde el que desarrollar software utilizando herramientas de Windows y Linux cuando fuese necesario.

Lo interesante apareció durante el proceso.

Dos instalaciones de una misma herramienta podían ser correctas si cada una pertenecía a un entorno distinto. Algunas decisiones podían mantenerse coherentes sin copiar configuraciones completas. Los proyectos podían ubicarse según su entorno real de trabajo y no únicamente por comodidad. Y cada nueva capa podía esperar hasta que existiese una razón concreta para incorporarla.

No son ideas especialmente nuevas. Son principios que aparecen continuamente en desarrollo de software: responsabilidades claras, bajo acoplamiento, estado explícito y cambios incrementales.

Lo curioso es que también funcionan al diseñar el propio entorno de trabajo.

Un entorno híbrido no mejora porque Windows y Linux hagan las mismas cosas.

Mejora cuando resulta claro qué debe hacer cada uno, qué necesitan compartir y qué conviene mantener separado.

Cuando esa frontera está bien definida, dejan de parecer dos sistemas compitiendo por hacer el mismo trabajo.

Pasan a ser dos capas de un mismo entorno.