Microsoft ha enterrado este lunes oficialmente Windows Vista. Ha elegido (…) Nueva Orleans para presentar ante más de 9.200 empresarios, su nuevo sistema operativo y dar la bienvenida al Windows 7, el nuevo S.O. del que espera vender 177 millones de unidades preinstaladas en los ordenadores hasta finales de 2010 (40 millones en 2009). La compañía estima que, en un año, el 75% de los clientes que tienen un sistema operativo de Microsoft (Vista o su antecesor XP) migren a Windows 7.

Windows 7, que ahora está en su última fase de prueba, estará disponible para empresas (…) el próximo 1 de septiembre y para el consumidor de a pie el 22 de octubre. Su precio será de 119,99 euros para particulares (en caja) y 285 para la versión profesional, el mismo precio del Vista o por debajo del mismo.

En la demostración de Windows 7, (…) una barra de tareas interactiva, desde la que se puede acceder a cualquier aplicación sin necesidad de abrir y cerrar ventanas como hasta ahora. Preparado para usarse con ordenadores de pantalla táctil, las imágenes se pueden agrandar y rotar, y se puede pasar página, como sucede con los móviles táctiles. Para los que dispongan de un PC o un portátil tradicional, la aplicación que más les llamará la atención será la de que, agitando el ratón, aparecen y desaparecen de un golpe todas las ventanas desplegadas.

Para evitar cometer los mismos errores que con Vista, que se lanzó sin que estuvieran disponibles las aplicaciones, en este momento 16.000 compañías de hardware y software están construyendo aplicaciones sobre Windows 7. En esta línea de compatibilidad, Microsoft ha aclarado que 246 millones de ordenadores en todo el mundo ya podrían instalar Windows 7 sin necesidad de realizar ningún cambio.

¿Hay más S.O. para Pc con capacidades táctiles?

¡Me da a mi que nos queda todavía una temporada de seguir viendo las CAJAS de Windows! ;-))

El ejemplo del CAD es uno de miles y es una industria importante. Un solo usuario profesional de CAD gasta más en software que dos docenas de mojamutos y Autodesk factura más de 20 veces lo que Youtube.

Ya me dirás para que sirve gastarse un pastón creando una aplicación Web que es una mierda pinchada en un palo cuando ya tenemos excelentes aplicaciones de escritorio que pueden funcionar a través de Internet.

Tampoco puedes comparar la velocidad de las comunicaciones en TCP/IP aunque sea local con la de acceder a la tarjeta gráfica a través de Direct X.

Lo que quiero decir con lo de la base de datos es que si conviene ejecutarla en local con Chrome OS ya no podrías.

El pinchar y arrastrar de Google Maps no tiene nada que ver con el de una aplicación CAD.

Google Maps es desesperantemente lento, pero Google Earth funciona mucho mejor.

Eso que dices del 3D es un disparate, los programas de CAD usan aceleración 3D por hardware a través del sistema operativo y sus drivers.

Las objeciones del HD y del MySQL no hacen al caso, dado que estamos hablando de ejecutar en local o en remoto según conveniencias de cada caso. ¿No conviene manejar HD en remoto? Pues lo ejecutas en local, hombre. ¿No conviene ejecutar una base de datos en local? Pues la ejecutas en remoto.

¿Quieres un programa de edición de vídeo con acceso a bases de datos de cine? Pues lo haces como lo haría cualquiera: un programa local hace consultas en red a una base de datos. Que estamos hablando del interface de usuario, hombre, no de si el programa local va a estar usando la red o no. La única cuestión aquí es si el programa va a estar usando como interfaz de usuario el sistema de escritorio, o bien html.

No sólo de CAD vive el hombre. De hecho, menos del 1% de los usuarios, ya sean domésticos o corporativos, usan programas de CAD. Por lo demás, cuando manejo Google Maps, sí que puedo hacer esas mismas operaciones de pinchar en un punto de la imagen, o de pinchar y arrastrar, que se hacen en los programas de CAD y Google Maps responde adecuadamente.

La única objeción que podrías poner es la velocidad de respuesta, que no es instantánea, pero es que Google Maps está en California, y yo estoy en España, y entre medio hay un buen puñado de redes con sus gateways y routers. Un programa como Google Maps volaría a la velocidad del rayo si se ejecutase a través del interfaz de red localhost.

¿Acaso crees que el escritorio de Windows sabe algo de los gráficos 3D de tu programa de CAD? No sabe nada, lo que recibe de la aplicación son gráficos 2D, y eso también lo puede mostrar html. Los verdaderos gráficos 3D se están manejando en otra parte. Tú nunca llegas a ver verdaderos gráficos 3D, el monitor es 2D, si tú te desplazas a un lado la imagen no cambia. Incluso en los cines 3D eso tampoco es una verdadera imagen 3D, son 2 imágenes 2D, una para cada ojo. La única clase verdadera de proyección 3D que existe son las proyecciones holográficas, y eso no lo maneja ningún programa de CAD.

En ese sentido, no hay ningún binomio desde el punto de vista de la aplicación, de la misma manera que tampoco lo hay si una típica aplicación de escritorio llama a funciones GDI o Xlib (Xwindow). Simplemente el programa produce una salida de html y recibe una entrada “desde html” (por ejemplo, método GET de CGI). El binomio servidor/navegador no es más binomio que GDI/User32 en Windows.

En cuanto a optimizar comunicaciones, el interfaz de red localhost puede ser tan rápido como quieras, precisamente porque no es un verdadero interfaz de red. El buffer de escritura en red del servidor puede ser si quieres el buffer de lectura en red del navegador, y que ninguno de los 2 se entere siquiera de lo que está pasando, porque el programar eso no es cosa del servidor ni del navegador (ni aún mucho menos de la aplicación web), sino que es cosa de la pila TCP/IP. Es decir, del sistema operativo.

Igual resulta que los SO ya tienen localhost optimizado, ¿has medido la velocidad de tu conexión localhost? A mí el ping a localhost me sale con una latencia en torno a 31 millonésimas de segundo (varía un poco de unas pruebas a otras) usando un netbook con Linux. Si le añado 65.000 bytes de datos al ping (parámetro -s en Linux, posiblemente el mismo en Windows y Mac) la latencia me sale similar (ya digo que varía un poco según pruebas).

No soy capaz de ver que el ping a localhost vaya más lento metiéndole casi 64KB de datos, no soy capaz de apreciar que la diferencia sea ni siquiera de unas pocas millonésimas de segundo. El tamaño de los datos no parece afectar a la velocidad, por lo cual esta tiene que ser elevadísima, o usar búferes compartidos. Por lo que he visto, no tendría que haber ningún cuello de botella en la “red” (el interfaz virtual localhost).

¿Beneficios? Ya mencioné 2:

- Un único modelo de programación para todo, con independencia de si se va a ejecutar en local o en remoto. Cambiando un único parámetro ya has convertido tu aplicación para PC en una aplicación para servidor remoto, y viceversa. El único parámetro que vas a cambiar es el nombre de dominio, de localhost a mivideo.com, o viceversa.

El SO que permita eso en su instalación por defecto, que esté pensado para que sus aplicaciones nativas sean así, sí que sería un SO pensado para la red. Lo otro, como ya dije en el otro hilo, son sólo sombras en la caverna (incluido Cromos).

- Portabilidad: sin hacer nada especial, el interface de usuario de tu aplicación ya es portable. El interface es precisamente lo que más trabajo de portabilidad supone, porque cada SO tiró por su lado. Windows usa GDI/User32, Linux usa (casi siempre) Xwindow y con frecuencia también GTK+ y Qt por encima, y Mac OSX usa Cocoa.

La situación es tan patética que lo único que tienen en común estos 3 en cuanto a interfaz de usuario es ¡un terminal en modo teletipo! Ya sabes, comandos cuya salida se desplaza hacia arriba cuando la pantalla se ha llenado. Un terminal tonto VT100 de los años 70 era más avanzado que eso. Pero resulta que también tienen otro interfaz en común aunque en principio estuviera pensado para ser usado en red: html. ¿Acaso no tiene sentido que las aplicaciones locales también lo utilicen?

http://www.5min.com/Video/How-to-Edit-an-Audio-and-Video-Clips-in-Adobe-Premiere-Pro-86619400

Y te olvidas del detalle de que un vídeo en HD puede ocupar muchos gigas y si quisieses usar una aplicación Web remota habría que subir todo eso antes de empezar.

Programar la interfaz de usuario de una aplicación CAD en HTML es simplemente impensable, ni a Google se le ocurre. Y casos como estos los hay a miles. No solo de twitear vive en hombre :-)

Y repito que si necesitas bases de datos estás listo porque no vas a poder instalar ni un triste MySQL en tu disco local.

Angel, es mucho mejor ejecutar bytecode del tipo de Java y .Net porque es verificable, seguro y portable.

Sin embargo, si me permites hacer algunos cambios, yo te propondría primero que fuera posible ejecutar en el browser código nativo ( debidamente aislado en su sandbox ) y que el servidor web además tuviera un mecanismo de tubería que permitiera al módulo cliente y al servidor compartir bloques de memoria ( algo mas sofisticado que la actual memoria compartida de linux o los ficheros mapeados en memoria de windows ). Todo esto para quitar al intermediario y entonces el modelo ya me parece mas realizable.

Yo creo que los de Google solo estaban pensando en las aplicaciones estrictamente web, no veo porque pasaría tanto trabajo para implementar una aplicación local. A lo mejor es que los dos mundos pueden coexistir perfectamente en este nuevo shell, las web en su browser y las otras en sus respectivas ventanas.

Veamos de forma sencillita (para que no haya más confusiones) cómo funcionaría ese programa de edición de vídeo (recordemos que el servidor está en localhost, está en el mismo ordenador que el navegador). El usuario pulsa sobre un icono para arrancar el programa llamado Mivideo (me acabo de inventar el nombre). Ese icono no es sino un fichero html que le presenta varias opciones al usuario. Pulsamos sobre el botón que pone “Edición no lineal”, y el navegador lo trasmite al servidor (es decir, el navegador pide localhost/Mivideo/EdiNoLineal.html), el cual devuelve una página estándar de selección de ficheros.

Seleccionamos el fichero de vídeo que queremos editar, y el navegador lo transmite al servidor, el cual devuelve una página que nos permite seleccionar dos posiciones del vídeo para operar. Esto se suele hacer con una barra de desplazamiento, y mostrando en cada momento, según movemos la barra, el fotograma de la posición en la que estamos actualmente. El navegador en realidad no está mostrando ningún vídeo, está mostrando los fotogramas que le envía el servidor (un programa tradicional tampoco estaría mostrando ningún vídeo, mostraría también fotogramas sueltos).

Una vez seleccionadas 2 posiciones del vídeo, pulsamos el botón “Cortar” y el navegador lo transmite al servidor el cual corta en el vídeo la porción especificada. Y ¡zas! ya hemos hecho una tarea básica de edición no lineal de vídeo.

Por supuesto, quien hace todo el trabajo con el vídeo es el servidor, no el navegador. Es más, en realidad el servidor web en sí (supongamos que es Apache) no hace el trabajo, actúa como un intermediario entre el navegador y la aplicación de servidor web alojada en localhost/Mivideo.

Apache no sabe nada de editar vídeos, quien hace el trabajo es el programa (CGI o lo que sea) que está en el directorio localhost/Mivideo, y ese programa puede acceder a todo el hard que sea necesario, hacer cualquier otra cosa que sea necesaria, y puede estar escrito en el lenguaje de programación que se prefiera. Es un programa normal y corriente que se está ejecutando en nuestro ordenador, solo que en lugar de usar el sistema de ventanas de Windows o Gnome lo que hace es interactuar con el usuario vía web.

En definitiva, el interface de usuario se hace con html (ayudándose de Javascript si es necesario), y el resto lo hace la parte servidor de la aplicación. Dependiendo del tipo de aplicación que sea, será conveniente que esté en un servidor remoto (el buscador de Google, tratar de ejecutar eso en un PC sería un disparate), o que esté en localhost (Mivideo, tratar de ejecutar eso en un servidor remoto, aunque se podría hacer, sería mala idea porque significará que no podremos editar vídeos cuando estemos sin conexión a Internet).

Así, cualquier tipo de aplicación se programa igual, y que la parte servidor esté en localhost o esté en servidor remoto ya es una mera cuestión de conveniencias para cada caso. Ya de paso, te olvidas de cualquier problema de portabilidad relativo al interfaz de usuario, que suele ser lo más problemático, porque es precisamente en el GUI donde cada SO ha ido por su lado, mientras que html e incluso Javascript están bastante estandarizados.

Esa es mi visión. Que te guste o no ya es otro tema ;-P

Yo creo que cada sistema tiene su uso, y los minimalistas lo tendrán también, pero no van a poder sustituir a los sistemas de servidores. Eso sin embargo no quiere decir que el browser no llegue a convertirse en el shell preferido como lo son ahora las ventanas, yo no lo veo, pero puede ser. Además el desktop ahora mismo está bastante subutilizado, hay muchas cosas que se pueden hacer y no se hacian ( Aero , usar tecnología de aceleración de video para las tareas del dia a dia ) si todo eso se acaba en favor de páginas web me parece que sería un paso atrás. Una mexcla de las dos cosas sería mejor.

Las facturas, la contabilidad y los datos privados sobre mis clientes no tengo ningún interés en que me los indicen.

Además muchas aplicaciones Web hacen lo mismo. Solo dejan indizar la portada. Y mira Tuenti lo que indiza.

Tienes razón en que el meollo del asunto es si HTML es apropiado o no para las aplicaciones y desde luego que no lo es. No se inventó para recoger datos, eso fue un añadido que se puso después.

Muchas veces no tiene ningún sentido que la interfaz sea un documento.

Casi ninguna de las aplicaciones que uso en el trabajo son páginas Web, solo las que uso para cosas banales.

Muchas empresas grandes han cometido la torpeza de crear aplicaciones Web cuando no debían por seguir modas y lo han pagado caro. Yo conozco casos en los que la productividad de los operarios se desplomó por cambiar de aplicaciones de escritorio a aplicaciones Web, y también pasando de aplicaciones MSDOS a aplicaciones Web.

Con una buena aplicación de escritorio no eres capaz de ver lo que está haciendo un usuario habituado. Con una aplicación Web tienes que esperar para todo y la interactividad es muy pobre.

Yo uso mucho programas p2p y no conozco a nadie que los use a través de una Web.

No basta con sustituir a AJAX. HTML es muy malo para aplicaciones.

Microsoft ha sacado XAML que es bastante mejor y vale para aplicaciones RIA y aplicaciones de escritorio. Y aun así tampoco es que esté muy bien.

Yo en mi trabajo uso aplicaciones de escritorio casi todo el tiempo y el navegador lo uso para buscar información y para hacer pausas para relajarme. Yo no uso Youtube, y menos en el trabajo. Cuando usaba GMail tenía que instalar una aplicación para que me avisase cuando llegaban mensajes nuevos. Ahora usa Thunderbird con IMAP y tiene más posibilidades. Muchas empresas usan cosas del tipo de Lotus Notes.

Oracle tiene muchos programas, no se a cual te refieres, pero desde luego que no puedes usar una base de datos de Oracle en local usando solo un servidor Web, tendrás que instalar también su servidor de bases de datos, y con Chrome OS nanai.

A nadie se le ocurre programar una aplicación de CAD o de edición de vídeo en javascript, es inimaginable. Para empezar no puedes acceder a mucho del hardware que necesitas.

Google tiene un CAD de juguete (Sketchup) y tampoco es una aplicación Web.