Lento pero seguro: Windows 11 se está convirtiendo en el Windows con el diseño más consistente en años

Algo se parece pero w11 está en un nivel muy superior a estos 2

Al igual que los cientos de millones de capas de personalización de Android, que para nada es un fracaso.

¿Los has probado o hablas por hablar? (Pregunta real, no troll)

Por ese tipo de usuarios es que Windows nunca lograba avanzar, los que querian que todo se quede igual en lugar de mejorar.

Que se queden en Windows 10

Creo que no entiende el concepto de mejorar el amigo, o el de eficiencia.

Cada vez hay menos cosas en el panel de control, hay muchas que se pueden encontrar en el otro lado, pero sigue siendo trabajar lento así y ni siquiera está todo.

Es como si de repente cambiasen el editor de políticas de grupo o de dominio por otra cosa parecida a la aplicación de configuración. Pobres administradores de sistemas...

Pues no se, yo uso la app de configuración mucho y no soy precisamente un usuario cualquiera...lo que pasa es que la uso para lo que fue diseñada: para modificar configuraciones del SO cotidianas. Resolución, HDR, temas, sonido, colores, aplicaciones, almacenamiento,...

Si lo que estoy buscando es EWT, Servicios, particiones. Esas cosas están donde están y donde cualquier sysadmin sabe que están(y donde seguirán)

La app de configuración NO suplanta al Panel de Control ni lo duplica. La app de configuración mejora el SO en el sentido de que una persona normal puede configurar sus movidas sin llegar a un sitio donde se queda: "WTF! Pero esto que es?!". Que es el problema del panel de control, que hay opciones que o tienes conocimientos técnicos o no te enteras de que se puede hacer ahí y antes de la app de configuración a cualquiera en Windows solo le podías decir que fuese a configurar cosas al "Panel de control"

Estoy de acuerdo en que cada cosa es para lo que es, y aun así agradezco mil que haya puesto una barra de búsqueda en la aplicación para configuración porque me pierdo por ahí a veces (puede ser personal, pero creo que hay cosas que están donde no deberían).

Con buscar X y que te lleve al sitio, perfecto, como en su suite ofimática, búsqueda para cosas específicas a las que prefiero no navegar, o ni sabría cómo.

Me da igual que me vayan a cocer a negativos, pero ultimamente se nota que el trabajo de sysadmins no es lo tuyo.

IT profesionales y sysadmins usan mas PowerShell que es mas flexible para gestionar precisamente los sistemas en Windows, sin importar la capa que sea.

Los power users cada vez les importa menos lo que venga en Panel de Control, ya que ven que tambien lo pueden encontrar en Configuración, y mi experiencia en los Insiders de Windows 11 esto ha sido mas facil.

Ya ves Linux y sus caoticas interfaces distintas entre si para configurar el sistema. De eso no hablamos, verdad?

De verdad, aqui hay muchos para jubilacion con los resistentes a los cambios que son.

Pues claro que no soy administrador de sistemas (por conocimientos y experiencia podria perfectamente), pero tengo una familia grande y amigos, ademas de varios equipos propios, así que a lo largo del año me toca andar configurando equipos o arreglando problemas diversos bastantes dias. Power Shell esta muy bien si como dices haces un trabajo diario con muchos equipos, que normalmente ya estan de por si minimamente limitados.

Si no, no solo no te sabes de memoria todos los comandos necesarios para cualquier posible configuracion, en cuyo caso lo mas sencillo es acudir directamente al panel de control ya conocido, sino que ademas te encuentras con errores que ningun sysadmin ha visto en su vida, ya que suelen responder a un uso totalmente aleatorio del sistema.

No entiendo que cambia lo que dices: no he dicho nada sobre que quiten Power Shell, ni siquiera que quiten el nuevo menu de configuracion. Pero seria absurdo quitar el panel de control, que no cuesta nada, y aporta mucho por el simple hecho de ser como ha sido casi siempre.
A partir de ahi no me he quejado de ninguna cosa nueva, aunque se espera que las mejoras sean eso: mejoras, y no cambios sin sentido.

El problema es q con Win8 y 10 han armado una pollada de "Configuraciones", cuando solo debieron hacerle una actualización grafica manteniendo la misma estructura del panel de control de Win7.

A mí me falta por ver 11 en mi máquina principal, porque lo probé en un equipo que estaba metido en Insider y hay un montón de procesos de diagnósticos y métricas brutales; pero en sí mismo no me desagrada, sobre todo según se va refinando.

De momento no veo tanta diferencia con 10 a decir verdad (en cuanto a flujo de trabajo me refiero), hay cosas que me gustan, cosas que no y cosas que bueno, me podría acostumbrar. En estos momentos, usar 10 u 11 me daría un poco igual la verdad, en 11 ya estoy pasando al menos 4 horas al día.

———————

Pero sí, el problema de cambiar de una arquitectura a otra es todo el código heredado que tienen. Hay mucho ensamblador en zonas críticas de cuando se trataba de esgrimir lo máximo posible del hardware y "código de autor", nada de eso es portable. De ahí los retrasos en aplicaciones de terceros nativas para el M1 en macOS por ejemplo, y que Windows para ARM siga siendo algo que ni siquiera he probado (¿podría ejecutarlo en una Pi?, ni me lo planteé).

Pasa con emuladores también, cuando los núcleos estaban escritos en ensamblador puro fue una fiesta con el boom de Android y querer emular consolas ahí, de repente ya no era x86 haha.

Si es que aunque una aplicación estuviese escrita en uno de los lenguajes de más bajo nivel que hay, C, (salvo la interfaz y eso que lo dé el sistema), siempre que uno se ciñese al estándar, cambiar a otra arquitectura sería "trivial": con tener un compilador de C para esa arquitectura, listo. Sería más o menos eficiente, en función del optimizador del compilador, pero ese es otro tema.

Quizás tener que cambiar algunas variables a otras que fuesen acorde al tamaño de un puntero en esa arquitectura, pero vamos, chuminadas comparado con entender código en ensamblador escrito hace decenas de años y, o bien pasarlo a algo de más alto nivel, o desecharlo y reimplementar esa funcionalidad.

El desarrollo de la interfaz no va a pasar lo que dices porque básicamente Microsoft desarrolla sus propias UI en UWP y .NET. Ahora mismo más .NET que otra cosa: la razón es simple, menos tiempo de desarrollo que usar la WinAPI.

Al final la WinAPI es una API de bajo/medio nivel en C/C++(compilación estática, sin administración de memoria), no es exactamente la panacea del desarrollo de UI, y no lleva trazas de ser una API con componentes UI porque la misma Microsoft está huyendo en todos los sentidos de desarrollarlos con los paradigmas de WinAPI.

En IOS no hay oferta de bajo/medio nivel para programar: usas los lenguajes y APIs de alto nivel que te proporcional Apple y caminando.

Son ofertas y planteamientos diferentes: si tu hicieses lo que hace Microsoft también buscarías diferenciar tu API de bajo nivel(WinAPI), centrada en dar control al desarrollador y rendimiento elevado, de tus API de alto nivel(MAUI, WPF, UWP, WinForms) que buscan automatizar las cosas para sacar aplicaciones como churros. Y desde luego para desarrollar UI usarías las APIs de alto nivel: el desarrollo de UI consume ya bastante tiempo aun en API de alto nivel.

Claro que no va a pasar, pero me gustaría poder ver una interfaz más o menos homogénea en todos lados, aunque fuese simplemente en cuanto a colores.

Pero no me había metido a hablar de bajo nivel, alto nivel, etc. Recuerda lo que pasó con ComCtl32 en época de XP, un manifiesto (que podía ni siquiera estar embebido en el programa) y listo, los controles de esa biblioteca pasaban a usar temas.

No había que recompilar nada, no había que cambiar la forma de programar (salvo añadirlo) ni tener que pintar usando primitivas o usar cosas de más alto nivel. Un simple manifiesto hacía que el sistema pintase un botón (por ejemplo) acorde al tema en uso sin ser un simple rectángulo.

¡Y ni siquiera lo han hecho por defecto a día de hoy! Abres su IDE de desarrollo por excelencia, creas un nuevo proyecto normal (no de consola) en C++ y sigues teniendo que habilitar manualmente que se usen temas para controles comunes (vía pragmas para el enlazador, añadiendo un manifiesto, etc.)

Entre otras cosas por eso no veo que hubiese importancia real en que tener una interfaz homogenea. Igual que hicieron eso, ¿por qué no hacer públicas y documentar las APIs que usan sus aplicaciones Win32 para que el sistema pinte los controles en oscuro cuando se usa un tema así? Sería muy útil para otros desarrolladores y seguro que muchos añadirían opciones para temas oscuros al no tener que complicarse la vida. ¡Hasta la gente que parcheaba la validación de temas para usar temas de terceros podía tener interfaces más congruentes!

Incluso hubo gente que esbozó prototipos de las aplicaciones que vienen con el sistema que se veían increíbles cada varios meses, pero al no trabajar para Microsoft y quién llevase esos temas allí no tener interés (¿o autorización?), se quedaron en eso: dibujos y prototipos.

Y en usabilidad también la liaron bastante a lo largo de los años, y no es que las heurísticas de diseño sean algo nuevo o hayan cambiado, siguen siendo las mismas desde hace más de 30 años (Nielsen).

Sin embargo hay otras aplicaciones que sin tener que tirar de código gestionado hay sacado interfaces muy bonitas, han preferido hacer el trabajo bien (con, o sin frameworks), no es que todo Win32 sea vetusto. Lo mismo pasa en código gestionado, la tienda está llena de aplicaciónes de mierda, incluso UWP, pero también hay perlas de gente que realmente valora el paquete completo y no solo la funcionalidad. A bote pronto me viene Dopamine (C# & WPF) a la cabeza, un reproductor de música que no estaba nada mal (aunque la siguiente versión creo que pasará a ser TypeScript con Electron).

Y aunque WinUI 3 es nativo, está escrito en C++ y se puede usar desde Win32 (ahí tienes al explorador de ficheros en 11), no solo desde .NET, hace falta que los desarrolladores escriban así su interfaz. Había XAML Islands en WinUI 2 y ni Dios lo usó, si es que no hay interés (no solo en Microsoft, entre devs) y Visual Basic hizo mucho daño :D.

Pero no consume tanto tiempo desarrollar interfaces basadas en XAML, recuerdo incluso en la uni cuando todavía no estaba incluído en el paquete de Visual Studio que existía Expression Blend. Y hoy en día de prototipado de alta definición a aplicación no se tarda tanto como antaño con las herramientas que hay.

De cara al futuro… ¿quién sabe? Yo sigo viendo la web muy presente incluso en Windows. WebView ya está separado, TypeScript entre otras cosas da tipado fuerte y WASM está avanzando muy bien, no me sorprendería que se comiese a muchas cosas. Con un poco de suerte Teams dejará Electron de lado, por pedir... :D

Pero sí, desde hace muchos años lo que prima es la facilidad para hacer las cosas más que la eficiencia, que no lo veo mal per se, pero creo que la parte de test, perfilar y optimizar una vez ya funciona se deja un poco de lado; que las cosas tienen que salir ya, siempre con prisa.

Blend sigue existiendo, aunque a día de hoy es simplemente una versión recortada del Visual Studio centrada solo en el diseño de interfaz(misma idea, pero más fácil de mantener solo cargando un subset de dependencias de VS).
Aun así para hacer bien una UI en XAML tienes que ir por algo similar a lo que hay en HTML/CSS: no es simplemente arrastrar cosas, hay que trabajar los posicionamientos para que se adapte a diferentes tamaños...eso es lo que lleva tiempo y la razón por la que dreamweaver aun hoy es mencionado humorísticamente como HTML/CSS de poca calidad. Es también el que los criterios de lo que es una buena UI han cambiado.

Deja el explorador de archivos tranquilo xD. Es una de las pocas UI que quedan que es lo suficientemente compleja, funcional y con el caso de uso adecuado como para que siga siendo 100% nativo(el ahorro de tiempo al lanzarlo es significativo y se ejecuta muy a menudo) a pesar de recibir evolutivos con cada versión de windows. Si lo pasan a APIs de alto nivel y tienes que esperar 1s o más a que se cargue toda esa interfaz hecha en XAML(p.ej), por mucho que me quieran vender que se ahorran [escribir] miles de líneas de código y complejidad de desarrollo voy a Redmond a ponerles una bomba xDDD.

Las WPA probablemente vayan a cargarse unas cuantas cosas a la larga, al menos en el espacio de uso cotidiano. Tienen demasiadas ventajas y honestamente centralizar todo en el navegador tiene sentido en vez de usar Electron por aquí, CEF por allá y demás movidas para ejecutar una web en un contenedor de app de escritorio...para eso gracias, prefiero que invoques a mi navegador preferido que todos ya tienen optimizado compartir recursos entre distintas instancias y pestañas.

La documentación hasta 2010 por lo menos ha sido siempre asignatura pendiente de MS. Afortunadamente se han puesto las pilas y hoy encuentras mucha documentación para todo: SQL, WinAPI, .NET e incluso acceso al código fuente de unas cuantas cosas...pero antes de 2010 era parca cuando no inexistente...cierto.

La homogeneidad de interfaz recae mucho en los desarrolladores de todos modos. Al final cada uno quiere dar sus propios estilos...es que lo máximo que puedes forzar eso yo creo que es como se hace ahora mismo: el SO tiene un punto de configuración de tema de usuario(claro o oscuro) y tu te haces al menos un par de temas que vayan bien con eso en tu app. No uso IOS, pero hasta en Android cada App pone el tapiz que le sale de los huevos: la única constante es que si tu configuras modo oscuro en el SO, las App por defecto usan su propio modo oscuro que se integra con el estilo de las app pre-instaladas de Google. No creo que puedas pedir más que eso: aun hay por ahí mucho material en la web desde cuando salió XAML de gente completamente ocultando(e incluso forzando a no renderizar) los marcos de la ventana nativa proporcionada por Windows(hasta el punto de que MS construyó una clase en .NET para estandarizar eso sin que básciamente perdieses toda la funcionalidad de ventana del SO: drag&drop, resize y más interacciones con el marco que están programadas en la ventana nativa) y poniendo el suyo propio con todos los estilos imaginables.

Creo que estás pidiendo mucho a los desarrolladores a no ser que probablemente vayas por la opción Apple: ellos controlan todo y tu programas exclusivamente sobre sus APIs de alto nivel.

Deja el explorador de archivos tranquilo xD.

Me has hecho sonreír :), yo por mí lo dejaba tranquilamente como está, pero siento decirte que ya lleva trocitos avanzados :P. La parte... grande, la vista de carpetas y eso está montada sobre Direct UI (a lo WPF pero para aplicaciones nativas) y la parte superior en 11 es XAML directamente, la clase es Windows.UI.Composition.DesktopWindowContentBridge (así que supongo que será parte de WinUI 3), es la misma clase que usaron para lo que antes era la bandeja del sistema.

[sobre las aplicaciones web] … prefiero que invoques a mi navegador preferido que todos ya tienen optimizado compartir recursos entre distintas instancias y pestañas.

¡Y yo! ¿Te puedes creer que ejecuta mejor Discord si lo abro en una ventana de Opera (por ejemplo, podría ser Edge u otro navegador) a usando el cliente propio? Pierdes alguna funcionalidad, como la de Krisp, pero es que compartir pantalla a la vez que transmites es taxante de cuidado y no tanto si lo hago desde el navegador. De locos... cuando me di cuenta lo primero que hice fue buscar si podía acceder a Teams así también :D.

Creo que estás pidiendo mucho a los desarrolladores a no ser que probablemente vayas por la opción Apple

Bien podría ser, si no surgió nada más o menos aceptable en estos términos hasta ahora no creo que vaya a surgir, pero quién sabe. Yo al menos tengo ganas de experimentar con las nuevas tecnologías y ver qué se puede hacer con ellas, cómo rinden, etc. Como siempre, me falta tiempo… necesito a un mecenas, que me libre del trabajo para tener más tiempo libre, ¡si es que cada vez hay más que aprender!

Con XAML empezaron los problemas de rendimiento en Windows 8 ya, aplicaciones lentas por casi ser interpretadas las interfaces en vez de compiladas.

Vamos para atrás.

XAML es naturalmente más lento(o consume más recursos) que Winforms por la cantidad de cosas de rendering que hace a mayores: estilos en cascada y con diccionarios, posicionamientos elaborados(stackpanel, grid, dockpanel), dependency properties(generalizan muy bien el poner datos en la interfaz y el data binding: pero implican boxing y compilación dinámica de CIL), el binding engine ahí permitiendo definir enlaces de datos abstrayéndote de controlar directamente la actualización de datos.
También puedes hacer interfaces responsive con el mientras que con Winforms ya puedes empezar a escribir tu mismo la lógica para algo responsive.

No me meto a contar florituras como arquitectura MVVM, que cumple perfectamente su cometido(aislamiento por capas y reusabilidad) pero que trae cola la cantidad de tránsito de datos que mete.

XAML es de hecho compilado estáticamente a BAML(binary application markup language) y después al igual que HTML se genera una estructura de doble árbol(logic+render trees) para modelar funcionalidad y renderizado de esta interfaz en tiempo de ejecución.

Es básicamente comparar un mechero con un lanzallamas. Y dicho sea de paso es ignorar algo que se lleva haciendo mucho tiempo en programación de alto nivel(empezó de hecho con los compiladores JIT), que básicamente es decir: "No importa comerse un tiempo extra de espera en la primera ejecución para compilar código y llenar cachés. Las siguientes irán como si fuese algo compilado estático."

Todas las APIs de alto nivel lo hacen: MVC(ASP.NET), MVVM, XAML, ORM. La primera ejecución compila una traca de código dinámicamente y llena cachés que alimentan todas las cosas que hacen los frameworks automáticamente por ti.

Tal cual, mis pluses, no podría haberlo dicho mejor.

Y lo mismo sucede en Android pero con otras tecnologías.

Estoy sola en ésto, a muchos parece que os gusta XAML como tecnología, pero me hubiera gustado que siguieran con tecnologías o por lo menos que mejoraran esa para que no fuese tan lenta.

Qué se le va a hacer 😔, no es tan bruto como cuando se pasó de XP a Vista pero sí que rinden mejor las cosas sin tanto .NET / Java / Intérprete que sea.

Haz cosas verdaderamente arcanas en .NET(cosas por las que la mayoría de los programadores te tacharían de hereje) p.ej: aritmética de punteros, código sin seguridad de tipos. Y luego me cuentas la diferencia que tiene ese compilador JIT con el de C++, pero la respuesta es clara: casi nula.

Ya lo dije en más de un comentario: la diferencia está en las APIs: como están construidas en la mayoría de los casos y a que se orientan.
También en lo que saben los programadores: hay verdaderos atropellos del runtime y el lenguaje de C# sueltos en montones de aplicaciones en producción porque simplemente alguien cacharreó sin documentarse(y sin tener ni idea de los cimientos) y funcionó como esperaba. Por nombrar:

-Uso sin sentido e indiscriminado de async/await
-DoStuffAsync().Result para "hacer" versiones síncronas en vez de construirlo bien(1 puta miserable línea de código que cuesta):

public object DoStuff();
public TaskDoStuffAsync()=>Task.Run(()=>DoStuff());

-Gente que no sabe hacer código paralelizando ni siquiera con Task, que ya es una abstracción de muy alto nivel. Ya no hablemos de entender Thread.

-Malabares inmensos con Array y LinQ para buscar un tipo concreto en vez de typeof(Type) o Type.GetType("AssemblyQualifiedName") y usar los algoritmos internos del runtime que oye, igual en un runtime con un sistema de tipado fuerte los que lo hicieron se dedicaron horas y horas a hacer profiling de como buscar un tipo concreto de forma eficiente.

-public static readonly int ConstValue = 5; cuando "const" es la palabra reservada específica para hacerlo. Hay diferencia aunque ambas funcionen. Ni el compilador de C# ni el JIT opinan lo mismo de algo "static readonly" y algo "const". Y es algo tonto que trae cola al optimizar código, precisamente por el distinto trato de los compiladores.

-¿Eh, que es eso de "struct"? :/

Y más...

Y en mi experiencia HTML y JS no cambian mucho. No se otros lenguajes, pero no necesitar un background técnico profundo en lenguajes de muy alto nivel crea el problema de desinteresados tirando líneas de código: mientras funcione da igual como llegue al resultado. En contraposición el lenguaje se hace popular...así que una por la otra supongo.

Los compiladores como .NET y Java importan poco porque son muy capaces de generar ensamblador de muy buena calidad. Las cosas están en el propósito de las APIs(esto es planeado) y los "No se exactamente lo que estoy haciendo, pero funciona"(los compiladores optimizan detalles de código de CPU, no tapan boquetes lógicos de lo que un programador escribe).

Yo simplemente pensaría 2 veces antes de culpar a los compiladores de código lento sea la que sea la estrategia que usen. Las APIs según el nivel de automatización: pero usar una API es una elección. Aún así construir un WPF/MAUI/... casero para acabar en algo igual de automático va a dar igual en reglas generales: las grandes empresas de software escriben buen código y si aún encima tienen por el chat interno a mano a los desarrolladores del runtime y el compilador ya no te cuento.

Claro que hacer una aplicación de contabilidad en XAML es una locura

Aquí difiero, aunque creo entender porqué lo dices. XAML puede hacer interfaces muy sexys(y usando aceleración por hardware!) y es cierto que para una App de contabilidad eso no es exactamente relevante.

Ahora piensa en DataBinding y la capacidad que proporciona XAML para generalizar mostrar datos en una ventana.

Al final da un poco de todo para todos los gustos. Quieres hacer una interfaz bonita o una app que pinta datos en pantalla y hacerlo todo abstracto en función de tus entidades de negocio. XAML pone ambas fácil.

¿Cual es el beneficio de que las interfaces sean consistentes? Que se entienden mejor y son más fáciles de aprender a usar. Quizas para alguien que viene usando Windows desde W95, que los menúes contextuales no hayan cambiado sea una ventaja. Pero para alguien que está empezando a usar una computadora, es importante que las cosas sean agradables y fáciles de usar.
Habrá gente que le haya molestado que los autos se dejaron de arrancar con manivela para pasar al encendido con la llave, pero para el que empezó a conducir con llave, aprender a arrancar con manibela hubiese sido un impedimento.
Si Windows no quiere perder mercado frente a macOS, y mas que nada Chrome OS en los colegios, tiene que mantenerse moderno, consistente y fácil de usar, y no parecer un Windows Vista con un tema puesto encima.
Sobre las herramientas terribles, te doy la derecha. El software preinstalado de Windows da pena. Desde las herramientas de administración del sistema hasta el set de aplicaciones multimedia incluido.

En la práctica, es meterse de lleno en temas de usabilidad, y es un tema grande e intricado (incluso incluye accesibilidad), con distintos tipos de consistencia (visual, funcional, interna y externa, ...).

Podría enlazarte a varios sitios donde te lo explicarían mucho mejor que yo, si te interesa échale un ojo a una explicación de las heurísticas o guías sobre usabilidad de Nielsen y por qué son relevantes, tiene que haber muchos sitios sobre ello a estas alturas y sería un buen sitio por donde empezar.

Pero, por ejemplo, algo que tenemos aquí en los comentarios, si te fijas a la derecha hay un apartado en el que se puede elegir si quieres recibir respuestas por correo electrónico. ¿Ves qué tipo de controles son?, ¿son círculos al lado de cada opción verdad?

¿Qué pasaría si fuesen cuadrados en vez de círculos?, ¿qué evocaría ver eso en tu mente? Para mí indicaría selección múltiple, que podría elegir más de una opción. Eso es parte de la consistencia en una interfaz, usar controles adecuados para cada cosa, puede parecer una tontería por el ejemplo que puse, pero es que lo tenía ahí a huevo como quien dice.

También tiene que ver con la consistencia (visual y funcional quizás) cómo se nos presentan los botones de responder y cancelar, o el de escribir un comentario. Ya te digo, es un tema complicado y falta gente formada en ello, o que ponga el foco en la usabilidad, no solo como algo que va después.

Sobre el rendimiento... no sé, no puedo quejarme la verdad, tengo con Core 2 Duo móvil de 2007 con Windows 10 y va muy bien. En Linux a veces me toca las narices Nouveau, pero es lo que es al ser ingeniería inversa. Si ese equipo puede con 10, tampoco es que haya que jubilar equipos rápidamente... (pero es solo un caso, una experiencia personal que para nada tiene por qué ser representativa de la mayoría).

Todo se resume a que parece ser la ultima version que tiene un balance entre lo que es y lo que pretenden que sea. Un sistema operativo demasiado amigable.

Y no esta mal, eso podría ayudar a que muchas personas con conocimientos básicos puedan operar un PC mas fácilmente.

El problema es para los profesionales, powerusers, etc.
En lo personal no me gusta esa sensación de poco control o que todo esta demasiado resumido, incluso configuraciones "avanzadas".

Es llamativo si, pero en la vida real rara vez se alcanza un balance entre funcionalidad y diseño. Obviamente Windows 11 no es la excepción.

Eso aunado a los ridículos requerimientos de TPM, Secure boot y UEFI, dejan a Windows 11 completamente fuera de mi interés, aun teniendo equipos que cumplen perfectamente con los requerimientos.

Sistemas basados en Linux demuestran ser 10 veces mas seguros sin tanto requisito de harware.
Menciono eso por que parece ser el estandarte y única justificación de Microsoft.

Parecen ser incapaces de desarrollar un sistema operativo seguro sin apoyarse directamente en el hardware.
Por esto mismo creo que Windows 11 es una clara movida comercial mas que una necesidad real.

Me quedare con Windows 10 mientras sea posible. Eventualmente solucionaran los problemas que están causando con Windows 11 y si no es así, pues buscare alternativas.

Es mi punto de vista muy personal. Windows 11 me es completamente irrelevante y no estoy ni a favor ni en contra.

Simplemente no es para mi.

Una pregunta... ¿usas una cuenta estándar en Windows igual que haces en Linux, o usas una con privilegios administrativos?

Porque en Windows la primera cuenta que se crea en OOBE es administrativa, en Linux a lo sumo te piden una contraseña para root, pero tu cuenta es limitada por defecto.

Si Linux fuese atrayente para los creadores de malware me pregunto cómo saldrían las cosas, no hace mucho (no recuerdo cuándo) hubo un problema de escalada de privilegios que llevaba latente como 10 años. Por mucho que el código fuente sea abierto, tampoco es que sea garantía de infalibilidad.

De todas formas sí, si me preguntasen a mí podrían hacer el sistema más seguro sin hardware adicional y pudiendo usarlo me parece genial (HECI, aislamiento del núcleo, integridad de memoria, secure boot, binarios firmados, ASLR, Control Flow Guard, etc.), no me hace tanta gracia que hayan decidido hacerlo obligatorio, pero me siento ambivalente ante ello (ni a favor, ni en contra).

PS. Y eso que no todos los binarios de Windows están firmados... que ya tiene delito la cosa, me pregunto por qué.

Claro, es que la información importante no suele estar cubierta en zonas restringidas para uno mismo, de ahí que malware como los que cifran ficheros, por ejemplo, no tenga problema en causar estragos en sistemas operativos de escritorio.

Pasaría lo mismo en macOS también, lo que cuelga del home del usuario es de libre acceso una vez está ejecutando el bicho, lo realmente importante es educar a los usuarios a no ejecutar cosas a ton ni son.

En casi todos los sistemas hay verificación de la integridad de los paquetes y/o binarios vía firmas, en Linux directamente al instalar algo desde los repositorios oficiales, por ejemplo. Digo casi todos porque en Windows depende del desarrollador y no todos compran un certificado para firma de código (hay, o había, quién los otorgaba gratuitamente para proyectos de código abierto), pero es que esté o no firmado, si no ejecuta elevado a no ser que haya un ADS indicando que provino de Internet, Windows ni te avisa por defecto. ¡Incluso cuando el binario ha sido manipulado y la firma ya no es válida!

Quizás parezca surrealista, pero es cómo se comporta ahora, dependería del desarrollador verificar que no hubo modificaciones a su binario (se puede, eso sí, hay API en Windows para ello).

Para malware de los que piden rescates tras cifrar archivos, creo (hablo sin saber) que la solución de Microsoft pasa porque se use OneDrive para sincronizar las carpetas de usuarios, por eso de que guarda un histórico de los archivos y se podría volver atrás; aunque también se podría usar heurísticas para monitorizar primitivas criptográficas y pararles los pies antes de que fuese demasiado tarde (me suena que alguna solución antivirus hace eso).

Y para el otro tipo que mencionas, los stealers (malware cuyo objetivo es robar datos), si tienen éxito en su cometido (e.g., si los datos que buscan no están cifrados), apaga y vámonos; como no se detecten a tiempo el daño ya está hecho.

De todas formas nada protege contra ataques a las cadenas de suministros (en inglés), ése sí es un problema gordo y cualquier cosa podría ser susceptible de ello.

La solución de Windows para ransomware es el "Acceso controlado a carpetas" bien visible en seguridad. Por defecto se deniega el acceso a todas las carpetas a todos los programas excepto los que son del propio SO y luego tienes que hacer una lista blanca de programas por carpetas. Es similar a la UAC: si algún programa quiere hacer algo fuera de lo común se te pide confirmación...si la aceptas es tu problema.

Respecto a integridad de programas esta winget en previews. Un gestor de paquetes tipo aptitude, con una capa de UI por encima será usable por cualquiera.
MS ofrece su propio repositorio y es obligatorio incluir un manifiesto para el gestor que comprueba versiones, hashes(MD5, SHA256) y binarios firmados. No se si tendrán algún tipo de medida de seguridad adicional como escaneos antivirus(lo daría por hecho). Aqui se ponen con el resto de SO: si descargas de nuestro repositorio oficial estás más seguro, aunque puedes descargar por tu cuenta o de otros repositorios(bajo tu riesgo, otro host, las normas de ese host)

¡Aja! Como no soy usuario de su solución de seguridad antimalware no lo tenía claro, de ahí el "creo". Encima en la máquina en la que estaba cuando escribí estaba gestionada por la empresa y la sección de ransomware ni siquiera aparece en Windows Security :D

Por defecto se deniega el acceso a todas las carpetas a todos los programas excepto los que son del propio SO …

Huh… así que excepto los que son del propio sistema, tengo curiosidad sobre cómo estará implementado eso, me pregunto, qué, a bajo nivel gestiona eso. Por ejemplo, si algo malicioso se enlazase a Explorer (i.e. un hook desde una biblioteca dinámica), ¿podría saltarse ese control? Espero que no :S

La integridad de WinGet o como se llame al final por el drama que hubo sigue sin convencerme. No porque sea falible, si se usan primitivas criptográficas adecuadas no tiene por qué ser un problema, es más por cómo fueron las instalaciones en Windows tradicionalmente: tienes la opción de "siguiente, siguiente, siguiente" o "personalizar" en alguno de esos "siguientes", y ahí muchas veces te encuentras con cosas del programa que no te interesa tener o que pasas olímpicamente de ellas, etc.

Intuyo que WinGet (y el resto, Chocolatey, Ninite, etc.) harán una instalación estándar y listo. Por poner un ejemplo concretro, Foxit PDF Editor no es un simple editor, tiene desde integración con la shell (varias encima), con distintos programas de 3os, una impresora PDF (que establece como predeterminada por defecto) etc. y todo eso se instala normalmente si no lo desactivas.

Añade eso a los restos que dejan algunos tras su desinstalación... se hace complicado tener un gestor de paquetes real en Windows.

———————

Pero me voy por las ramas, como siempre, autenticación, ¿de qué sirve que el instalador (o el paquete, o los binarios) esté firmado, si después no se valida al ejecutar?

Es decir, en Linux la confianza está depositada en los mantenedores, actualizas un paquete, se valida la clave y si todo es correcto se instala (si hubo algún problema en el código fuente, o algún actor en mala fé ya estás fastidiado, pero ese es otro tema, es parte de los ataques a la cadena de suministro de los que hablaba).

Los binarios en sí no están firmados, en la instalación es donde terminan las comprobaciones de integridad, hay permisos, y contextos de seguridad como en SELinux, pero no hay firmas que validar ni integridad de binarios que comprobar.

En Windows un desarrollador hace su software, (compra y) firma todo binario que produce con su clave y pone el instalador al alcance de los usuarios, sea en su web, en un repositorio, etc. da un poco igual.

Si es un ejecutable y se descarga desde un navegador, se añade al archivo un stream de datos adicional para indicar tal hecho, eso hace que al dar doble clic haya un aviso sobre el binario que tratas de ejecutar, que vino de un sitio no confiable (potencialmente).

Al estar firmado, y ser válida la firma, el cuadro de diálogo te hace saber que está firmado por X y que su firma es válida; si no estuviese firmado el cuadro de diálogo ya tendría un tono amarillo de aviso y te haría saber que no se sabe ni quién es el editor.

¡Pero es que el comportamiento es el mismo estando firmado el binario y habiendo sido modificado! Si algún malware toquetea el binario (y deja la firma, porque podría haberla eliminado) la integridad del archivo estaría comprometida, la firma en sí podría ser válida (no estar caducada y no haber sido revocada), pero no casaría con los valores esperados para el binario.
Pues Windows no hace distinción entre software firmado pero modificado y software sin firmar; te presenta el mismo cuadro de diálogo amarillo. WTF?! (Que a todo esto, no sé cuántas personas se paran a leerlo y cuántas le dan a "Sí, sí, permite que el programa haga cambios en el equipo" (sinónimo de "eleva, eleva, si hace falta, hace falta").

Es responsabilidad del programador, verificar si su binario ha sido modificado y muy, muy pocos lo hacen.

En algún caso es peor aún, he tenido que analizar uno que usaba un lanzador para abrir la aplicación, en función de si tu sistema era de 32 o 64 bits lanzaba el binario apropiado.

Todo firmado, lanzador, binarios, bibliotecas, etc., tenía el típico fallo de inyección de bibliotecas, pero bueno. El caso es que se modifica el programa principal, el exe de 32 o 64-bits, la comprobación usando la firma pasa concluir que el archivo ha sido modificado, pero como quien solicita la elevación es el lanzador, ¡el usuario ni se daría cuenta!

Podría pensar que todo está OK, la integridad del ejecutable (el lanzador) ha sido validada, todo perfecto. Pues seguía adelante, 0 avisos, 0 eventos, nada, cuando en verdad el lanzador debería haber comprobado eso y no ejecutar ese binario, mucho menos con privilegios administrativos.

———————

Si es que es un show, un día de estos tengo que hacer un blog o algo donde contar vivencias y cómo mitigar algunas, pero no me da la vida haha

Hasta donde se hay 2 maneras de hacer hooks:
A)Muy casera: compila o descárgate una dependencia de un programa y abusa de como funciona el cargador de DLL de Windows. Que yo sepa hoy casi no se usa por inseguro.
B)CBT Hooks de la WinAPI: solicitar al cargador de DLL de Windows que inyecte un DLL en un proceso externo.

A) no es viable con explorer.exe a no ser que tu mismo modifiques C:\Windows\system32\. En ese caso es tu problema y probablemente una violación del EULA si dices que lo has hecho

B) imagino que siendo funciones de WinAPI tendrán la decencia de hacer al menos algo básico. Si los pillan que sea una vulnerabilidad remota no un "virus.exe pide que virus.dll se cargue en la memoria de wdm.exe" y pase por el aro.

Oh, explorer.exe no se ejecuta como SYSTEM ni nada todopoderoso. Se ejecuta con el usuario logueado(y pide UAC). Hace ya bastante(desde las primeras versiones de Win10) que desmantelaron eso de que explorer.exe sea la navaja suiza de Windows: le han quitado muchas responsabilidades al punto de que ahora mismo es simplemente un entorno de escritorio esencial(UI del entorno de escritorio+programa explorador de archivos)

Sobre gestores de paquetes que más dará: ni siquiera en SO basados en Linux la gente es necesariamente organizada(imposible si la existencia de ciertas cosas no depende de ti solo). Si solo usas los paquetes y aplicaciones del distribuidor del SO(p.ej aplicaciones que Canonical incluye en Ubuntu,...) entonces tienes dependencias comunes para todos los programas, exactamente igual que con lo preinstalado en Windows. Ambos casos el mismo lo controla todo y pueden perfectamente unificar dependencias.

Para paquetes de terceros puedes acabar con versiones ad-hoc de cualquier binario dependiendo de las dependencias con las que compile el desarrollador igual que en Windows cada programa de terceros tiene sus binarios en sus carpetas y pilla lo que quiera de las globales: en Windows el repo global es C:\Windows\system32\, nadie le impide a nadie usarlo pero por comodidad las cosas más susceptibles de cambiar se meten en la carpeta del programa como dependencias privadas(y hoy que sobra el espacio en disco es casi mejor hacerlo así) y al final solo se pillan del repo global cosas muy del kernel/drivers(ntdll.dll, shell32.dll, rundll32.dll, DirectX, drivers,...)

El no existir opciones de instalación unificadas si es un tema(estilo aptitude instala solo lo mínimo, o elige entre dependencias opcionales o todo) pero al final la mayoría yo sé lo que va a hacer y te lo puedes imaginar: instalar todo y a tomar por saco, no vamos a invertir tiempo en hacer cábalas de que funcionalidades pierdo si omito dependencias.

Las firmas de binarios no solo prueban identidad, son también anti-tamper. Si tienes un binario firmado y lo modificas entonces la firma es inválida(y la UAC te va a decir que la firma del binario no es correcta y es posible que alguien lo haya modificado) porque el hash se genera para un binario concreto para una identidad concreta. Para modificar el desarrollador tendría que volver a firmarlo con su certificado. Esto ya no depende de Microsoft, es una cuestión de protocolo con certificados y de quienes hacen algoritmos de hash.

Las firmas no solo son a nivel de instalador. Los ejecutables también tienen que ir firmados e igual que con los instaladores la firma es inválida al modificarlo. Solo alguien con un certificado válido puede firmarlo de nuevo.

Sobre los lanzadores me parece más que obvio: si confias en el lanzador entonces confías en lo que haga. No es necesario hacer la misma pregunta por cada binario que se carga. Si le das permiso a un lanzador para elevarse, entonces ya ta. Esto va así en cualquier sitio: si un proceso en Unix pide root, una vez que está el sudo hecho, ya tá: tiene suplantación de root y puede hacer cosas incluido lanzar otros procesos con suplantación de root.

No encuentro una relación entre seguridad basada en hardware y el uso de una cuenta root.

En todo caso, no seria mas facil que Microsoft encaminara a Windows a la filosofía de no usar cuentas con privilegios, en vez de forzar una seguridad basada en hardware que a lo mucho demoraran 3 meses en vulnerar?

Todo eso es parte del show. No es absolutamente necesario, pero los fabricantes necesitan vender PCs.

Vamos a ver si hacen lo mismo en el sector empresarial con los Windows server.

En fin, como dije es mi opinion personal.

No encuentro una relación entre seguridad basada en hardware y el uso de una cuenta root.

Es que no lo hay :), solo mencioné los privilegios de las cuentas por ser una diferencia que hay por defecto entre Windows y Linux. No sé qué tal llevarían la mayoría de usuarios de Windows tener que autenticarse con permisos administrativos para hacer según qué cosa.

Ni idea sobre cuánto tardarán en saltarse las protecciones que sean, pero tampoco me preocupa, cuantas más opciones para ponérselo difícil al atacante, mejor (y digo opciones, que aunque yo sí lo prefiero si de mí dependiese podrían obviarse bajo la responsabilidad del usuario sin problema).

Pasa en todos sitios de todos modos, ahora son los requisitos de Windows 11 los que están en el ojo de mira, un pelín antes las limitaciones de macOS Monterrey en equipos que no sean ARM (hay alguna surrealista :D), cada vez que sale una nueva versión de macOS el tema de no poder ejecutarla en Macs de X año hacia atrás (aunque ténicamente sí puedan), no hace mucho las costosas (computacionalmente) mitigaciones para Spectre y timing-based side channel attacks, ¡incluso hay gente que propone vaciar la caché de datos de nivel 1 en cada cambio de contexto en Linux por defecto!

(Si no estás al tanto, es una locura... pero la racionalización viene a ser la misma que la de Microsoft ahora: en aras de mejorar la seguridad, solo que las consecuencias... madre de Dios; no creo que debiese activarse algo así en equipos de propósito general)

Incluso si nos ponemos la protección por defecto a las pilas y demás (hardening, ya sea en código o en binarios), pero al tema, que me pongo a escribir y divago mucho haha

Como quien decide suele ser quien fabrica, o quien produce, la decisión que nos queda a los usuarios es seguir con ello, o dejarlo (bueno, o buscar la forma de saltárselo).

En este caso porque hay quienes entienden que los requisitos son excesivos, artificiales, o sus máquinas no los cumplen, etc. pero razones para cambio hay muchas: mejor opción en la competencia, continuar con lo ya conocido y a lo que se está acostumbrado (e.g., cuando salió GNOME 3, fue otra guerra porque el flujo de trabajo cambió en ese gestor), no estar de acuerdo con la filosofía de alguien, o cancelarle por algo (e.g., ReiserFS tras su creador ser condenado por asesinato, empresa X por hacer (o no hacer Y), …

Entiendo que sea un fastidio, por ponerlo suave, para quienes tengan equipos que no cumplan los requisitos que estableció Microsoft para 11 y anhelen instalarlo, pero no es el fin del mundo tampoco, hay más opciones y los equipos no dejan de funcionar por no estar con la última versión.

Para quienes hayan leído hasta aquí, gracias ante todo, pero, he visto más bugchecks (pantallazos azules/verdes/negros) en Windows 11 (6 en total) que en los últimos... ¿10? años juntos, ni recuerdo la última vez que me había saltado alguno. Y fueron fallos que estaban relacionados con el núcleo, no causados por controladores de terceros (un par de ellos al menos tenían que ver con la gestión de memoria, del resto ni idea).

Ahorita te vendrá con la "cantidad de virus y usuarios" ignorando decisiones como la cuenta de administrador por defecto o no, sandboxing del sistema, principios de mínimos privilegios, etc, que son parte de la seguridad de sistemas en sí.

Windows XP tenía los problemas de seguridad que tenía precisamente por tratar a todos sus usuarios como si fueran sysadmins, sí, se agregó el UAC después, pero termina siendo una característica infumable que la mayoría de los usuarios siempre desactivan por ser "irritante" según ellos, y que además elimina todo su propósito ya que por defecto cualquiera puede entrar al sistema y tener derechos de administrador, esto significa que les ahorras a los ciberatacantes tener que explotar alguna vulnerabilidad de escalada de privilegios ya que no hay ninguna barrera que les impida adquirir dichos privilegios, y en caso de ser lo contrario, sería tan fuerte como la mantequilla, si bien el usuario también tiene la culpa por ejecutar algún programa que no debe o por no crear una cuenta de usuario estándar por ya sabes, flojera, sigue siendo humillante que el resto de sistemas operativos sí lo hagan por si solos mientras que Microsoft siga estancado en los 90, si en Windows 11 no solucionan este problema milenario estará para cortarse lo que se tiene en la entrepierna.

La obligación de Secure Bot y TPM 2.0 también son un completo despropósito, pero bueno, es su sistema, solo ellos pueden modificarlo y se reservan todo el derecho a controlar su plataforma, tú como usuario aceptas el acuerdo de licencia de Windows y por ende debes aceptar todas las cosas que te imponga Microsoft y tú como usuario no puedes decir ni hacer nada, menos si Microsoft se niega a escuchar a sus usuarios y están decidido con lo que van a hacer
Después de Windows 11 saldrá Windows 12, 13 y hasta el infinito, y nadie debería de esperar que sean más livianos sino todo lo contrario, tuvieron suerte con Windows Vista por la forma en la que Microsoft desarrollaba Windows en ese entonces, pero Microsoft dejó ese modelo hace muchísimos años.

Creo que se lo han cargado en 11, ahora hay el tamaño "habitual" y ya, nada de iconos pequeños o de no agrupar instancias de aplicaciones, que por lo que he leído también trae a unos cuantos de cabeza.

Mira que yo les doy su merecido en las áreas que me parece, que procuro ser sensato en mis valoraciones, pero igual les atribuyes cosas que no les pertenecen.

Es como cuando salían (¿salen?) bugchecks por problemas en algún controlador, realmente el problema no es de Microsoft, es de quienes programaron el controlador para ese hardware (generalmente). Es muy positivo el programa para constructores que tienen desde hace unos años (y que se hace más estricto según pasa el tiempo), en ese aspecto, por ejemplo, obligan a que ciertas reglas de CodeQL (un analizador semántico de código) pasen sin avisos si quieren que su controlador sea certificado para Windows tal.

Las interfaces de aplicaciones... a ver, pongamos un supuesto, compañía X (Microsoft) crea un lenguaje de diseño y las empresas desarrollan su software en base a él. Todo es homogeneo (bueno o no es otro tema), las interacciones de los usuarios con las distintas cosas con predecibles e intuitivas (son siempre igual), etc.

Pero llega una empresa Y y quiere diferenciarse cambiando las cosas y obviando el estándar preestablecido por así decirlo, empieza por cambiar su apariencia y la forma en la que interactúas con ella. Quizás sea mejor, quizás su interfaz sea más… intuitiva, para la mayoría de la gente, pero ya es diferente. ¿Qué culpa tendría la empresa X? X hizo su trabajo dando guías de diseño, tonalidades incluso y demás, pero Y decidió ir a su rollo.

Y vayamos a un extremo, ¿qué tipo de aplicaciones casi nunca sigue el lenguaje de diseño, sea la plataforma que sea? Los juegos, cada uno es un mundo, ahí si que no se puede homogeneizar casi nada; pero no por ello es malo.

Otro fallo que tendemos a cometer (me incluyo) es que al no ver, cambios radicalmente distintos concluímos que apenas hay cambios. No podemos evaluar qué cambió en el núcleo por ejemplo, o en la gestión de memoria, o si el planificador tiene más cosas en cuenta, etc. Fíjate que dices que el explorador de ficheros apenas ha cambiado, sin embargo fue causa de multitud de terminaciones forzosas (crashes), algo habrán tocado no solo en la interfaz quizás.

Hay temas, probablemente orientados a ámbitos no tan domésticos, en los que hayan trabajado y no podamos apreciarlo a simple vista. Pero sí, estoy de acuerdo en que hay detalles que sobran y faltan, como todo en esta vida (prácticamente) siempre es mejorable.

Personalmente parezco ser el único que sabía que se podía mantener oculto con el botón de flecha situado debajo del botón de maximizar.

También se puede ocultar/minimizar si haces doble click en cualquiera de sus pestañas.

Desactiva las copias de seguridad: una cosa es el almacenamiento en "la nube". Otra copias de seguridad de las carpetas de tu usuario: si activas eso OneDrive controla las carpetas y guarda backups automáticamente. Tu solo añades ahi los archivos que quieras guardar.

Otra opción es que con unidad externa te refieras a un disco que conectas y desconectas. En ese caso se "desconfigura" con toda la razón del mundo y alguna más. Las carpetas de usuario en Windows tienen que existir siempre porque cualquier programa puede accederlas en cualquier momento: si las diriges a una unidad concreta y luego quitas la unidad entonces al no encontrar la carpeta física en la unidad configurada vuelve a la ubicacion por defecto("C:\Users\{Usuario}") por si algún programa las quiere usar. En este caso almacena tus cosas en otro sitio: hazte tu carpeta de documentos personales...total una carpeta de documentos personales no tiene mucho sentido si despues viene cualquier programa y te mete no se que plantillas, resultados de benchmark o cualquier estupidez con tus documentos. Esto es legado de otras décadas y cambiarlo supone movilizar programas tan viejos como meter basura en la carpeta de "Mis Documentos"

Define sistema operativo anda, que igual con ello te das cuenta de que cumple las condiciones.

Windows ha sido un verdadero SO para usuarios finales desde Windows XP, antes era una interface grafica de DOS