Probando Windows 11 para desarrollo Java durante 2 semanas

Escribo esta bitácora luego de utilizar Windows 11 durante dos semanas como mi sistema operativo principal. Busco relatar la experiencia desde el punto de vista de un usuario «UNIX» de la no tan vieja guardia, las cosas me parecieron interesantes, que recomendaciones puedo dar a las personas y en general lo que creo que aun le falta a Windows para ser atractivo hacia usuarios Linux, especialmente programadores.

Antecedentes

Me considero un usuario de sistemas *NIX. Utilizo Linux casi a tiempo completo desde el año 2006 y MacOS aproximadamente desde el año 2015. A partir del año 2006, a excepción de una que otra consultoría, he utilizado Windows únicamente como un sistema operativo para juegos.

Team red

Con la pandemía evitando seguir mi vida nomada, decidí que era momento de rearmar un gaming rig y entre otras cosas aproveché una licencia educativa para instalar la versión Beta de Windows 11 como miembro del programa insider. Imaginé que en algún momento iba a necesitar compilar programas, conectarme a ssh, y otras cosas típicas de mi trabajo por lo que preparé mi instalación de Windows 11 con lo básico para trabajar, incluyendo:

  • Java Developer Kit 11
  • Node JS 16
  • Git
  • IDE (IntelliJ IDEA) y editor de texto (Visual Studio Code)
  • Docker (Desktop)
  • Kubernetes (Minikube)
  • Navegador web (Firefox)

En este post no comentaré algunos errores que he encontrado en Windows 11, porqué estaba advertido que seria Beta, al contrario les puedo confirmar al 100% que todo driver de Windows 10, funciona bien en Windows 11.

Winget vs Chocolatey

Una de las cosas que nunca me gustó de Windows es la necesidad de buscar y descargar los paquetes de software desde la tienda de cada uno de los fabricantes, gracias a esto nacieron tiendas tan infames como Softonic o Mocosoft, o los discos de PC Magazine que traian un metainstalador junto a varios tantos troyanos.

Luego de usar tantos años gestores como Homebrew o Portage hacer esto es algo arcaico, por lo que decidí configurar el sistema utilizando un gestor de paquetes. Al día de hoy existen al menos cuatro formas principales de instalar aplicaciones en Windows (sin contar las tiendas/launchers de juegos que son otro mundo por si solo).

Microsoft Store es la ideal para instalar aplicaciones con interfaz gráfica pero su mayor inconveniente es que si o si se necesita tener una sesión de Microsoft iniciada, y era demasiado tardado buscar paquetes, asi que la descarté.

Winget es al día de hoy un canal oficial de Microsoft para herramientas en línea de comandos, en el pasado este universo era totalmente comunitario con aplicaciones como Chocolatey, Scoop y AppGet. Este último de acuerdo a su creador murió porqué Microsoft le «morfó» la idea, lo contrató y luego tiró todo su esfuerzo.

Mi principal problema con Winget fue que al ser el más nuevo, aun padece la falta de paquetes importantes, por ejemplo al día de la escritura de este post, no tiene una versión moderna de Maven, por lo que lo descarté desde el inicio.

Consecuentemente exploré Chocolatey y Scoop, la principal diferencia es que Chocolatey necesita privilegios de administrador para instalar los paquetes (como la mayoría de instaladores oficiales) mientras que Scoop trata que en su mayoría estos paquetes sean instalables por un usuario normal. Imagino que Scoop es más convenientes para entornos corporativos con usuarios restringidos pero dado que este no era mi problema, la colección de paquetes de Chocolatey terminó siendo la ganadora. Al día de hoy estos son los paquetes que he instalado.

Configurando Java 11 y Maven en Windows 11

Si les interesa conocer el proceso a detalle, preparé un pequeño tutorial para mi canal de Youtube

WSL2 el año de Linux en el escritorio . . . que aun no llega

Mi siguiente tarea durante la preparación de Docker fue instalar WSL 2, que en pocas palabras es un sistema Linux dentro de Windows, especialmente útil para la linea de comandos. Esta fue a su vez mi mayor decepción.

WSL2 es una capa de compatiblidad en donde las llamadas son traducidas desde los ejecutables Linux hacia el Kernel NT los ejecutables ELF corren sobre un kernel Linux real bajo la estructura de virtualización de Windows. Junto con el sistema, Microsoft ha estado promoviendo una terminal denominada Windows Terminal que permite ejecutar CMD Clasico, Powershell y WSL.

La terminal sinceramente está muy bien acabada y supera por mucho a todas las terminales de Windows anteriores, para un usuario Linux sin embargo la experiencia seria similar en Gnome Terminal y para un usuario MacOS es bastante parecido a iTerm sin tantas posibilidades de personalización.

Mi principal problema con WSL es que diferente de lo que pasa con una terminal con MacOS o Linux, WSL aún es un sistema «alienígena», y tiene varias cosas que vale la pena destacar.

Primero, su sistema de archivos es un universo aparte, y se integra en sus propias unidades de red virtuales en Windows Explorer.

El hecho que sean unidades de red presenta bastantes inconvenientes, especialmente bajo desempeño. Entre los que me ocurrieron en esta aventura puedo mencionar dos:

  • IntelliJ tiene varios errores reportados, colocar un proyecto «dentro de Linux» implicaba que IntelliJ no funcionara más. Al día de hoy usar el sistema de archivos de WSL causa más problemas que soluciones a usuarios de IntelliJ como es mi caso.

Se supone que esto es IntelliJ sobre WSL pero yo veia un cuadro gris

Adicionalmente si se desea tener Java, Node o cualquier otro compilador en Powershell y WSL, es necesario instalarlo dos veces. Y en casos como Maven o Node esto significa mantener dos inventarios de dependencias descargadas, una para la instalación en Windows y otra para la instalación en WSL.

Aunque las soluciones están en desarrollo y espero que en un futuro mejoren, sinceramente es más fácil instalar un Ubuntu en dual boot o comprar una Macbook. Sin embargo, creo que WSL si es ventajoso bajo los siguientes casos de uso:

  • Terminales SSH
  • Docker Desktop
  • Como un entorno de compilación cruzada
  • Como un entorno de pruebas/certificación en Linux

Mi recomendación al día de hoy es seguir utilizando Powershell.

Powershell, Cygwin y otros IDE Java

Dado mi estrepitoso fracaso con WSL 2 como terminal principal, decidí que lo más sano era utilizar directamente Powershell y Cygwin.

Antes de la existencia de WSL 2, lo más parecido a una terminal bash en Windows fue Cygwin, en el cual se compilan y adaptan binarios típicos de un userland POSIX para ejecutarse sobre Windows.

Mi principal motivación para utilizar Cygwin fue que para una consultoría debía validar entornos de desarrollo basados en NetBeans, y al querer utilizar la terminal en NetBeans obtuve el siguiente resultado:

Y ya en la experimentación, decidí probar Eclipse, el cual parece trabajar mejor con cualquier terminal en Windows.

Mi único inconveniente con Powershell es que estoy demasiado acostumbrado a hacer tareas simples en zsh, por ejemplo hacer commits en git, realizar busquedas con find, o editar directamente un archivo de texto.

Mi solución en el mediano plazo fue agregarle algunos complementos a Powershell, incluyendo:

Neovim

posh-git y Git Credential Manager Core para trabajar con llaves ssh y no con usuario y contraseña

Un detalle menor con Neovim es que no puedo utilizar la tecla Esc en IntelliJ Idea, lo cual debe corregirse manualmente.

El panorama general en Windows 11

Como bien notara el amigo Cajas, mi principal problema con Windows es que estaba encarándolo como usuario UNIX porque «¿que usuario Windows normal se quejaría porqué no puede usar Vim?», y creo que tiene un punto valido. En otras palabras estaba reaccionando como un usuario de Windows la primera vez que usa Ubuntu y no le funciona la impresora.

Mi experiencia previa con Windows ha sido la siguiente:

  • Windows 3.11 (Cyrix 686)
  • Windows 95 (Pentium 2)
  • Windows 98
  • Windows ME (Pentium 4)
  • Windows XP (acá me despedí de Windows a nivel domestico)
  • Windows 7 como videoconsola (Core i7)
  • Windows Server 2000
  • Windows Server 2003

Con un equipo no tan modesto fue relativamente fácil instalar Windows 11, a pesar de las restricciones artificiales es posible instalarlo sin Secure Boot y TPM utilizando un par de hacks en el registro. Eso si, las personas que quieran actualizar desde Windows 10 y tengan dual boot con Linux la van a pasar mal.

Todos los drivers que instalé son Drivers de Windows 10 y hasta el momento todos funcionan, incluyendo:

  • Receptor bluetooth
  • Wifi
  • Webcam
  • GPU Radeon RX 6600 XT
  • Impresora Canon en red con SMB (Samba)

De las aplicaciones que instalé ninguna presentó algún fallo (a excepción de WSL 2), en su momento reporté un bug en twitter con Java pero resultó ser un problema con la codificación de mi nombre (problemas de usuario hispano). Otros usuarios me han comentado que lo sienten más pesado que Windows 10, pero como no tengo punto de comparación solo les dire que a mi Linux si me va más fluido pero Windows 11 tampoco me pareció lento.

Me sorprendió lo fácil que me adapté a Windows a pesar de no usarlo frecuentemente, una vez has usado un Windows, cualquier otro Windows va a ser más o menos lo mismo y eso es bueno para la productividad. Incluso pude usar Steamlink hacia mi computadora en la sala (Raspberry Pi 4) sin inconvenientes.

Un punto negativo que no ha cambiado en Windows es que cada dispositivo de hardware por muy pequeño que sea tiene su propia aplicación para hacer tunning, terminé con un monton de bloatware con tal de deshabilitar varias cosas RGB.

Bloatware

Aunque suene gracioso, lo mejor de este Windows para mi fue la herramienta de captura de pantalla. Eso es lo más revolucionario hasta el momento, fue absurdamente facil producir todas las imagenes para este post.

El objetivo de esta instalación sera juegos y conservo un dual boot con Gentoo Linux para trabajo serio. Pero con todo y los inconvenientes, creo que este Windows es un Windows 10 con tacuche nuevo y sera un buen Windows.

Edit 15 de septiembre: En el post original afirmaba que WSL es una capa de traducción, eso es verdad para WSL 1 pero no para WSL 2, WSL 2 ya es un sistema independiente.

5 Replies to “Probando Windows 11 para desarrollo Java durante 2 semanas”

  1. Usando Firefox 92.0 Firefox 92.0 en Android 10 Android 10

    Pinta muy bien Windows 11, gracias por dar un punto de vista desde el lado de los desarrolladores, como siempre, bien puntal y al clavo, execelente. 👏

  2. Usando Opera 78.0.4093.184 Opera 78.0.4093.184 en Windows 10 x64 Edition Windows 10 x64 Edition

    Yo uso windows para dev por temas de licencia gubernamental y la actualización de windows 11 ha sido bastante estable, NodeJS ejecuta de muy buena manera, solo he notado un problema con la multiplicidad de pantallas pero de todo muy bueno, gracias Víctor por el post.

  3. Usando Firefox 91.0 Firefox 91.0 en Mac OS X  10.15 Mac OS X 10.15

    tl;dr experimento nivel adolescente para generar trafico, mejor hubieras hecho un post de java 17 que acaba de salir hoy, seguro Oracle igual pagaria por ello, y seguir usando Windows para lo unico que sirve, jugar 🙂

  4. Usando Mozilla Compatible Mozilla Compatible en iPhone iOS 14.7.1 iPhone iOS 14.7.1

    Muchas gracias por compartir tus hallazgos. En mi caso considero que siempre se debe de utilizar WSL2, más cuando el software open source, ya que por lo general es mucho más fácil y tiene mejor rendimiento un binario en Linux que en Windows. Otra cosa es que WSL2 tiene un Kernel completo de Linux, es decir ya no hay necesidad de hacer traducciones al Kernel NT (windows), como se hacía en WSL1, lo cual es una mejora abismal en términos de rendimiento. El visual code funciona de maravilla y en si todo WSL2 tiene un rendimiento muy bueno.
    https://docs.microsoft.com/en-us/windows/wsl/compare-versions

    En lo personal he probado tanto Linux, MacOs y Windows, pero por el momento Windows con WLS2 considero que es la mejor alternativa. Así que pruébalo otra vez y así dejamos de usar powershell 🤢🤮

  5. Usando Firefox 92.0 Firefox 92.0 en Windows 10 x64 Edition Windows 10 x64 Edition

    Hola Jesús, muchas gracias por el comentario.

    Con tu comentario noté que la información que tenia publicada era incorrecta, efectivamente WSL2 es una capa de virtualización y ya no de traducción, olvidé leer el borrador final del post. Gracias por la observación.

    Respecto a la velocidad al menos en mi opinión si es más lenta en relación a Cygwin/Powershell/Git Bash. No es de muerte pero soy una persona algo desesperada entonces por eso lo consideré lento vs las opciones nativas. Y como podras ver en los screenshots, mi IDE no funcionó o tenia que esperar demasiado a que leyera un proyecto desde el sistema de archivos de WSL, espero que esto mejore en el futuro para popularizar la tecnología.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *