Barrapunto

No se que problema le achacas a la arquitectura cliente servidor, cuando eso al ususario le pasa totalmetente desapercibido

Para continuar, no tienes ni idea de lo que significa memoria virtual.

Pfff, a ver por donde empiezo...

a) El software de sistema se escribe en C, un ensamblador portable de 1970 conocido tanto por su flexibilidad ( lo que me encanta ) como por su tendencia a esconder errores y sus librerías parcheadas mil veces ( rápido: diferencia entre los distintos exec* )

El kernel está escrito en C y algo de ensamblador, ¿y? En Amiga casi todo el software estaba escrito en ensamblador de 68k y nunca fallaba. No culpes al lenguaje de que haya malos programadores. Si sabes lo que haces usa C, y si no, pues usa Java/python/C#/ruby

b) El sistema jerárquico de archivos, bien pensando en su momento, se vuelve casi inmanejable en discos de uso personal con más de 100.000 archivos, que es lo que viene en una distribución cualquiera

Ahí si tienes algo de razón. El sistema de ficheros de BeOS permite añadir metadatos para solventar este problema. Lo que está haciendo MS ahora con WinFS también es interesante.

c) El empeño en hacer de cada S.O. el sistema total, ignorando tércamente la realidad. Para sistemas de uso personal, la arquitectura cliente-servidor ( ej. sistema X ) sólo es fuente de problemas.

Ahí te equivocas de nuevo. Primero porque X no es la única alternativa, y segundo porque me temo que has hecho caso de los comentarios que dicen que X es un protocolo lento. En modo local X utiliza sockets de dominio unix que, como sabrás, son tan rápidos como usar memoria compartida. Y si, somos unos cuantos los que aprovechamos la transparencia de red de las X cada día.

d) Otras partes básicas del sistema se ven influenciadas por puntos de vista fundamentados en necesidades de hace 3 o 4 décadas. Por ejemplo, cuando puedo tener 2GB de RAM en una máquina a precio razonable, no veo por qué empeñarse en soportar memoria virtual, pensada para que máquinas con 64Kb pudiesen ejecutar seis u ocho procesos.

La posiblidad de guardar páginas de memoria en el área de swap es sólo una parte. La memoria virtual permite que cada proceso viva en su propio espacio de direcciones. Mírate cualquier libro de diseño de sistemas operativos.

Mucho mejor hacer sistemas adaptados a cada necesidad que pretender, como he dicho antes, que cada nuevo sistema sea el mega-sistema super-servidor hiper-escalable total.

Esto que dices tampoco es cierto. Mira como escalan hacia abajo Linux y NetBSD.

e) Peaje de entrada demasiado alto: aún cuando alguien quisiese innovar, olvidarse de las viejas reglas y hacer algo distinto, tendría el problema de las aplicaciones. Cuesta años escribir un buen procesador de textos, por ejemplo.

Te pondré un buen ejemplo de innovación: Plan9 de los Bell Labs. Por cierto, no sé si lo sabes, pero Unix se hizo para que la gente del departamento de patentes gestionara las susodichas. Muchas veces la innovación viene de una necesidad.

f) Cuestión cultural: las nuevas generaciones han aprendido a programar sobre un colchón de una docena de capas. Con semejantes ligaduras, es imposible pensar cosas nuevas.

Tampoco estoy de acuerdo, conozo gente muy joven con la inquietud suficiente para meterse en el meollo. Mira la historia de Ken Silverman, el autor del motor build del Duke3D, hizo algunas cosas muy interesantes sobre voxels antes de la llegada de las aceleradoras 3D, y era bastante joven por aquel entonces.

Miguel