Barrapunto

Bien, ha llegado el momento de recordar a Ballmer, CEO de Microsoft, las palabras que dijo sobre la disponibilidad de Windows para Itanium simultanea al lanzamiento del chip, segun C|Net. Y quizá ahora se pregunten muchos peces gordos de las compañías del mundo de la computación se pregunten como es posible que Linux esté antes que Windows sobre Itanium. Y para que hablar de la disponibilidad sobre los 64 bits de AMD, donde SuSE ya está preparando a Linux. El software libre comienza a demostrar que es más competitivo que el cerrado.

Aunque no dudo que el software libre es competitivo creo que esta batalla se ha ganado por otro motivo.

Y ese motivo es que Win nunca se creó para ser portable. Sus APIs son monstruosas y supongo que
portar Win es mucho más laborioso que recompilar los programas.

Razón de más para que MS se concentre sobre .NET.
Las aplicaciones .NET son interpretadas, por lo que con portar la máquina virtual .NET correctamente a Itanium, todas las aplicaciones desarrolladas para esa plataforma funcionarán sin problemas sobre cualquier nueva arquitectura.

Pero el kernel y los drivers... Eso es otra cosa.
Me temo que el kernel de Win es muy poco portable,
y los primeros ports serán burdas adaptaciones a 64 bits como Win95 lo fue del Win3.11.

Conseguirán tener un WinNT sobre Itanium, pero por dentro tendrá demasiado código en 32 bits que no sacará el rendimiento esperado, y el .NET lo hará muchísimo más lento.

Quizás sea eso lo que AMD e Intel desean. Que la gente se acostumbre a .NET con la excusa de una gran integración con la red, para que se requieran procesadores realmente poderosos.

Yo creo que las máquinas virtuales, o sea Java o .NET, abren el mundo de los microprocesadores de una forma que seguro que ni AMD ni Intel quieren. Recuerda que AMD e Intel no paran de sacar extensiones propietarias para lograr mayor rendimiento e intentar lograr mercados cautivos que usen esas extensiones. Las máquinas virtuales quitan protagonismo a los chips, algo contra lo que lucharán tanto AMD como Intel.

Más que mostruosas, incoherentes ( lo digo porque llevo programando en API de Windows unos días a pelo). Tiene cosas muy sencillas para ciertas cosas y muy bien resultas PERO la incoherencia que tiene en algunos puntos las hacen ... bueno.

Fundamentalmente las funciones ....Ex, y luego que las funciones hay en versiones ASCII y MultiByte, lo cual en función de un define y unos oscuros juegos con typedefs en los include _se supone_ que debe de funcionar una cosa yu otra. A eso le sumas, que el API que expone NT no es el suyo Nativo ( que ese si que se retuerce a niveles impensables, www.sysinternal.org para más info).

Por cierto, eso de que el kernel de NT es poco portable ... recuerda que NT corría en MIPS, Alpha, PowerPC e Intel. Con lo cual, si corre en ALpha el kernel es ya de 64 bits.

En realidad la poca confianza de Intel en M$ puede poner de otro motivo: no confían en M$ para un compilador que optimice en condiciones ( siempre fue mucho mejor por ejemplo Watcom), aunq el gcc tampoco es para tirar flores en otros aspectos.

Creo que NT 4.0 y posteriores ya no corren ni en MIPS ni en Alpha. De PowerPC no tengo ni idea.

Pero, efectivamente, NT era portable, al menos en tiempos.

Exacto, NT se diseñó para ser portable, y poder tener distintos subsistemas sobre la capa del kernel, subsistema de 16 bits, 32 bits, y algunas más que no recuerdo.

Linux se diseñó para hacer un UNIX sobre 386, se diseñó un SO monolítico sin pensar en su portabilidad.

Sin embargo, con el tiempo el NT se ha centrado en una única arquitectura (supongo que a una empresa le resulta muy dificil tener grupos de desarrollo especializados en distintas arquitecturas) y Linux por el contrario se ha ido adaptando a una cantidad de arquitecturas increible (corre desde en una S/390 hasta sistemas empotrados, pasando por 68000, PowerPC, Alpha, Sparc...), y además creo que por este mismo motivo, actualmente es muy modular y fácilmente portable a otra plataforma.

En resumen, NT fue pensado para ser portable, pero con el tiempo su kernel se ha convertido en un monstruo caótico difícil de portar, y Linux fue pensado de una forma más sencilla, pero con el tiempo y el trabajo de miles de personas se ha convertido en un kernel muy bien diseñado y facilmente adaptable a cuantas arquitecturas se desee.

Ya hace bastante tiempo que recuerdo haber leido que MS abandono todo lo no-Intel excepto MIPS creo, es más, creo que el último NT que soporto todas esas plataformas que dices fue el 3.51, más que nada porque casi nadie hacía aplicaciones para el en esas plataformas ( M$ había puesto las herramientas de desarrollo a precios monstruosos al ser un entorno "muy profesional" y además tenían muy pocas instalaciones y no interesaban a terceros ) y porque el rendimiento era bajo comparado con los UNIX tradicionales que utilizaban.

NT 4.0 si que corre bajo Alpha, en mi trabajo lo tuvimos una temporada. Nunca obtuvimos el mismo rendimiento en Alpha que en Intel. Parece que no era una aplicación Alpaha nativa, sino que M$ ponía una capa de emulación entre el S.O. y el hardware

En resumen, NT fue pensado para ser portable, pero con el tiempo su kernel se ha convertido en un monstruo caótico difícil de portar

No solo de portar, sino de trabajar con el. De ahi los grandes retrasos de MS en sacar nuevas versiones de NT.

Después de leer los interesantes comentarios previos,lo que ssí se saca en conclusión es que Linux es mucho más flexible a la hora de portarse a diferentes arquitecturas,lo cual es una muestra evidente de su potencia.Ahora mismo,cuando aparezcan los micros de 64 bits de AMD e Intel,habrá un Linux para ellos,cosa sumamente importante ya que jugando a dos bandas es difícil fallar.Y también deja en evidencia a M$,más si cabe viendo el tamaño de esta empresa.

¿Seguro que es el kernel?. Creo que no, sino todo lo que tiene por encima. Los componetes básicos de NT ( el executive, el gestor de objetos y demás) no son tan pesados.

Yo creo que la cosa viene más por el propio API WIn32, las funciones de traslación y otra fauna, que lo que es el diseño del kernel en sí mismo.