jueves, 28 de agosto de 2008

Nuevo formato de GoogleDocs: Formularios

No sé si será experimental o no... sólo sé que hoy por la mañana, cuando he abierto el GoogleDocs para redactar un documento me he encontrado con que, además de Documento, Hoja de cálculo y Presentación se había agregado Formulario.

He creado uno para probar y en general parece una sencilla, pero efectiva herramienta para generar formularios para usar en email o web.

No permite grandes cosas, pero es efectivo y fácil de usar, y rápido de generar.

miércoles, 27 de agosto de 2008

La realidad, según Mac (o Apple Inc., según se mire)

He leído esto:

"La semana pasada les comentábamos acerca de la fantasía dentro de los comerciales del iPhone 3G para promocionar las velocidades de una conexión de datos más rápida.

Aunque las conexiones dependerán sobre todo de la operadora, el hecho que Apple no sea claro en su publicidad es bastante reprobable. Otro de los aspectos que se quejan en el Reino Unido es que el comercial asegura que es posible acceder a todo el internet desde el teléfono, cosa que no es realmente cierta, porque no soporta ni Flash ni Java.

No es la primera vez que un comercial de TV de Apple deja de transmitirse en el Reino Unido. En 2003, uno relacionado con la PowerMac G5 fue prohibido por asegurar que es la máquina más rápida del mundo, algo que la compañía no podía probar.

xDDDD hombre... los ingleses no se dejan lavar el tarro... esto aumenta mi respecto por sus organizaciones institucionales, frente a unas españolas que descienden en picado.

Sobre lo de PowerMac G5 -sinceramente tampoco me extraña tanto:

Es la misma historia, la misma imagen que se está proyectando con el iPhone: lo de Apple es lo más rápido, lo mejor. No hay nada que les haga sombra. xDDDD como la gente se lo siga creyendo algún día será verdad (no en vano el otro día superaron en valor a Google).

El iPhone tiene una campaña con ese toque picante-mentiroso, un tanto "curioso". Un móvil bueno, sí, desde luego, pero de ahí a que sea el mejor... afirmar eso es cosa que como mínimo es dudosa y probablemente una trola como una casa. Yo no tengo todos los móviles. Pero sin ir más lejos, por ejemplo... el otro día LG sacó un nuevo móvil: el KC910 que así como quien no quiere la cosa hace picadillo al iPhone:conectividad HSDPA, DivX, cámara de 8 megapíxeles, graba vídeo en 640x480 30fps... entre otras muchas cosas, que dejan al iPhone a la altura del betún, no más bajo.

Pero claro ¿qué es eso del HDSPA? ya nos enteraremos que existe el HDSPA cuando a Apple se le dé por sacar el móvil iPhone HDSPA, antes no, no existe, no puede ser!!! nooooooooooo (mi lado fan de Apple acaba de despertar de una pesadilla... ohhh... mmmm... si yo no soy fan de nadie xDDD).

Esto demuestra dos cosas: la tontería de la gente y el poder del dolar. Este tipo de cosas me aclaran las razones de que más de uno viva con el coco lavado- y que era la máquina más rápida del mundo xDDDDDDDDD hay que tenerlos bien puestos para afirmar o insinuar semejante barbaridad.

Volviendo al caso del G5:

Digo yo que habrá superordenadores algo más potentes, un poquitín, pero casi nada ehhh... Es como decir que tu ferrari es la máquina más rápida del mundo... la realidad es que hasta ahora creo que ese record lo tiene el cohete de las misiones Apolo de la NASA. Que lo diga un particular, no hay problema, pero que lo diga Apple y dentro de su publicidad! jejeje.

Mi opinión es que la diferencia más "notable" de un Mac y cualquier otra máquina es su sistema operativo, MacOSX. Desde el punto de vista del hardware un Mac y un PC u otra máquina de las mismas características hardware quiero creer -sino alguien me está timando!!- que serán casi exactamente igual de rápidos (aunque se puede tener fe, claro... ohhh santo Jobs... haz que mi ordenador sea sobrenaturaaaaal)... la CPU es la CPU!! y las CPU's de los Mac a día de hoy son las de los PCs. Como decía mi abuela: "No se puede sacar de donde no hay".

Pero... es que si les creo, estos fulanos, que no tienen ni un ápice de decencia, me lo ponen más fácil... aún: cuando se pasaron de la arquitectura PowerPC a la Intel afirmaron: ahora va a ir todo más rápido como lema de campaña. No se si será verdad o no... pero si lo es... bueno... eso quiere decir que antes iba todo más lento no??? Obviamente la realidad es que Intel era más barato por una razón: estaba más disponible (esta segunda fue la razón real, según tengo entendido).

Otro detalle, y aquí viene quizás el quiz de lo que podemos ver (todo en esta vida es una ilusión!!!) supongo que tiene que ver con:

En un ordenador -o cualquier aparato interactivo- siempre tenemos dos medidas de velocidad. Por un lado tenemos la velocidad real o de proceso y por otro lado la velocidad de interactividad o de respuesta. Hay que reconocer que en esta segunda Mac es muy, muy bueno. De cara a los usuarios esta segunda velocidad da sensación de estar frente a un goliath. Pero... el disponer de una velocidad de respuesta mejor implica más ciclos de CPU a ello y... mmmm... esto hace que la velocidad de proceso baje. Así que la conclusión es que los Mac son más lentos... ummm... pues sí.

Mmmmm... ya sabeis chicos: alavad a Jobs. La filosofía de Jobs es... tratemos a todos como tontos, que así me compran. Yo personalmente tengo claro que si me compro un Mac es por su diseño y porque me gusta más o menos el MacOSX...

Fuente del texto comentado: http://alt1040.com/2008/08/comercial-del-iphone-prohibido-en-reino-unido/

sábado, 23 de agosto de 2008

Computación y OpenGL 3

He encontrado esto: http://en.wikipedia.org/wiki/OpenCL (supongo que lo conoceréis, pero por si acaso).

Open Computing Library, promovida por Apple, gestionada por el Kronos y defendida por otros fabricantes, va a ser introducida en el MacOSX 10.6.

Esto... elimina uno de los contras del OpenGL 3 -antes mencionados- y deja sólo el tema de no tener OO, que más que una solución sería un problema, y el modelo deprecated.

En general OpenGL no debe ser OO (si se quiere un OpenGL OO, siempre se puede hacer otra librería) y tampoco tiene porque ocuparse de computación en paralelo, para eso está OpenCL.

Sólo queda el tema de los deprecated, que sigue siendo una cagada por varios factores:
  • En primer lugar, creo que se han pasado un poco: esto puede ser una opinión personal, y, sinceramente, es el menor de los problemas: cualquier programador se puede adaptar en seguida al nuevo modelo.
  • PEEEEERO... el verdadero problema viene de la posibilidad de que un ordenador con OpenGL 3 instalado no soporte aplicaciones que usen OpenGL 2.1 o anteriores. Eso SÍ es un problema: al menos debe proveerse una retrocompatibilidad entre ambos sistemas, ya sea a la hora de programar una aplicación o ejecutarla. OpenGL 3 debe estar en "otra" librería compartida del sistema.
Es probable que los sistemas con OpenGL 3 instalado puedan seguir ejecutando aplicaciones basadas en OpenGL 2, ya veremos. No he logrado encontrar información sobre el tema aún, si bien es cierto que no he tenido mucho tiempo. Actualizaré esta entrada si veo algo.

Así que resumiendo, OpenGL 3 no es tan malo, si bien es cierto que apenas aporta nada nuevo que no aportaran las extensiones.

jueves, 21 de agosto de 2008

OpenGL 3.0... ese engendro...

OpenGL 3.0... ese engendro... -_- que tiene en pie de guerra a toda la comunidad de desarrolladores. Escuche alguna vez que la indiferencia era lo malo, que hablaran de ti mal, no era tan malo. Por lo que yo entiendo, los detalles que mosquean a la gente en general:

* Que el core de la librería no integre maneras para soportar las nuevas features de las tarjetas... es una buena cagada, se supone que toda librería que se precie debe soportar todas las últimas features... pese a ello si aparecen extensiones estándar, mejor, sino se implementarán en extensiones los fabricantes... no estoy muy puesto en el tema, que conste. Quizás todas estas nuevas features tengan que madurar hasta que CUDA, Larrabee... se conviertan en algo más estandarizado y para entonces entren con más fuerza.

* Lo que parece que más indigna a la gente es que no se halla incluido un modelo orientado a objetos, al parecer pensando en la gente que desarrolla para CAD. Hasta parece que hay alguno que quiere que quiten todo el sistema tradicional de OpenGL basado en funciones e implanten OO (orientación a objetos).

* En general la gente comenta que casi todo se limita a coger algunas extensiones y moverlas al núcleo. A mi también me lo parece leyendo la spec.

Y lo que yo opino o me cuestiono:

* No tiene tanto sentido una comparación OpenGL y DirectX, ambas tienen arquitecturas demasiado distintas:

* DirectX se basa en sucesivas versiones de objetos. Cuando sacan un nuevo DirectX, las versiones antiguas "siguen ahí". En DirectX tenemos al alcance features antiguas con tal de usar objetos antiguos -eso creo, porque hace mucho tiempo que no hago nada para DirectX y puede ser que empezaran la "caza de brujas" de versiones antiguas pero me suena que por lo menos se emulaban...-. Por tanto DirectX está más encaminada a "romper" cada vez que sale nueva versión.

* Por otro lado OpenGL tiene una estructura basado en core+extensiones. La compatibilidad está en que dicho core es siempre el mismo o que versiones nuevas incluyen a las antiguas... En ese sentido lo que no sé es que ocurrirá con OpenGL 2.x cuando llegue OpenGL 3.x: ¿será soportado por otra .DLL o .SO? O será borrado del mapa?? Eso sería una cagada: hay aplicaciones antiguas que dejarán de funcionar?... por lo menos deberían emular los sistemas antiguos... que será lo que hagan en el peor de los casos no??

* A mi personalmente me parece mucho más potente la estructura core+extensiones... hubo un tiempo en que, por lo menos me da esa sensación, OpenGL estaba mucho más a la última con este tipo de arquitectura, puesto que los fabricantes sacaban extensiones en sus implementaciones de OpenGL; esa velocidad no se puede / podía alcanzar con un sistema similar a DirectX... que está más orientado a revisiones. En OpenGL luego salían las extensiones ARB, que estandarizaban aquellas extensiones de features comunes, pero para entonces ya podías haber programado versiones modificadas de tu renderer para las distintas extensiones.

* Lo de dejar sólo OpenGL orientado a objetos (OO)... no creo que... ó sólo puedo decir que el OpenGL de toda la vida ha sido así y en parte eso es lo que le confiere su sencillez: se pueden publicar secuencias de ordenes, a modo recetas, no sé si esto sería así con OO, supongo que también, si se cumplieran algunos requisitos. Estaría bien que hicieran "otra" librería gemela o un subset orientado a objetos y __directamente contra los drivers__ por eso de la velocidad, pero quitarle a OpenGL su estructura de funciones "gl" y estados, no sé ¿sería OpenGL? A mi me parece un poco salvajada esa posibilidad. ¿No os parece tanta fijación con el tema del OO un poco "snob"? Que conste que el OO está muy bien, pero desarrollar en OO tiene sus cosas buenas y malas como todo. A mi personalmente me resulta más rápido no usar OO en determinadas zonas, aunque tengo que reconocer que OO con OpenGL podría estar bien, pero también es cierto que creo que es más portable usar C (no C++).

* Lo que no entiendo es porque se ha dejado de segundo plano el modo de hacer de ir estandarizando las extensiones de fabricantes más o menos comunes y se ha emprendido esta cruzada en el core. Es cierto que había cosas que tenían telas de araña... de lo poco que se usaban... modos de 256 colores y tal, pero soy de la opinión que el core no debería de tocarse teniendo esta arquitectura core+extensiones, como mucho marcar deprecated algunas cosas y listo. A mi donde halla unas buenas extensiones ARB que se quite el resto... :P Incluso se podría sacar una extensión ARB para proveer OO... pero claro, no queda tan "buen marketing" como decir... "el nuevo OpenGL 3". El marketing siempre ha estado detrás de que ahora se pueda decir eso de las cosas ya no duran lo que antes xDDDD.

* Por último lo del deprecated la han liado parda, pero vamos, que tampoco quita el sueño. A modo curiosidad todavía no me ha quedado claro si se cargan el clásico "glBegin();... glVertex();... glEnd();" de OpenGL... en la sección de deprecated dan a entender que sí, pero luego en la sección 2.6 hablan del tema como si fuera a quedarse. A mi personalmente me parecía un buen método para probar cosas, pero luego a la hora de la verdad siempre es buena cosa empacar los vértices.

A mi personalmente no me había creado ninguna espectativa el que surgiera OpenGL 3 o DirectX 11... para mi son medios para lograr fines, en unos casos con más dolor de cabeza y en otros con menos.

Sólo espero que cuando aparezcan las primeras implementaciones aparezca, cuanto más material, mejor :)

lunes, 4 de agosto de 2008

Windows 7 y Midori

Cuando por la mañana empiezas a leer apaciblemente las noticias, te topas con algo así y abres los ojos algo más de lo normal... y no es para menos: esta noticia no sale todos los días, y no en vano se ha extendido como la pólvora por toda la blogosfera.

Para empezar el nivel de "credibilidad" que yo personalmente le doy es -aún- bajo. Siguiendo un poco la noticia a sus origenes parece que o es una filtración por parte de Microsoft o es algo que una persona ajena a Microsoft ha inferido a partir de varios hechos.

Además, si nos paramos un momento más y recordamos, hace uno o dos meses apareció una de esas noticias, yo creo que un globo-sonda, que lanzó un ingeniero hablando del "nuevo" Windows 7, o mejor dicho, de miniwin (http://meneame.net/story/salen- ... -minwin) y diciendo, casi aproximadamente, lo mismo que se dice aquí, sólo que en lugar de hablar del sistema en general hablaba del Kernel y por tanto no matizaba tanto algunas cosas. Finalmente la propia Microsoft dijo que no (http://meneame.net/story/proximo- ... -kernel), que Windows 7 iba a ser el -ordinario- sucesor de Vista, basado en el Kernel WinNT.

Ahora aparece esta noticia, yo creo que tiene mucho que ver con aquella que se lanzó originalmente, más desarrollada, pero viene a decir lo mismo:
  • Por un lado, como es lógico, Microsoft está cansada del mastodóntico código que tiene el Kernel WinNT, por causa, sobre todo, de la retro-compatibilidad nativa que ofrece ¡¡hasta Windows 3.11 incluso!! y de manera nativa. Si alguno es programador sabrá a que me refiero. Se habla de usar un micro-núcleo, idea con sus añitos, pero que hasta la fecha apenas es implementada por un puñado de sistemas, debido a la complejidad que encierra (por ejemplo MINIX usa un micro-núcleo desde hace años y Hurd, el hermano pequeño de Linux, esperemos que pronto esté listo, WinNT estaba a medio camino siendo de tipo híbrido). Esta me parece una línea de actuación adecuada.
  • Por otro lado la idea es poder reducir los recursos que "devora" el sistema, haciéndolo mucho más ligero, aunque esto no hay que confundirlo con el hecho de que si activamos una interfaz similar a Aero si no tenemos recursos. Sin embargo el núcleo en si mismo es una pieza muy liviana: el mismo núcleo o kernel, por ejemplo Linux, se puede usar en dispositivos móviles o en super main-frames de peta-flops, siempre que se cumplan una serie de requisitos: es lo que se monta sobre el kernel lo que va orientado a uno u otro dispositivo. Sin comentarios: supongo que todo el mundo dirá que esto es genial.
  • Se habla del .NET como plataforma de desarrollo integrada en el sistema. Para aquellos que no lo conozcan: es un entorno de compilación dinámica (JIT), similar a Java en algunos aspectos. No voy a entrar en profundidad, tenéis un magnífico artículo en la Wikipedia sobre el JIT: http://es.wikipedia.org/wiki/Compilaci%C3%B3n_JIT ni que decir que lo del JIT tiene sus años, aunque no lo creáis. Desde mi punto de vista meter .NET me parece bien, pero no me parecería una decisión correcta desplazar a la interfaz de funciones stdcall de toda la vida por ello (ambos sistemas pueden y deben coexistir). Por otro lado programar en .NET elementos críticos en velocidad del sistema operativo también puede ser un gran error que provoque que se pierda el rendimiento ganado por la primera decisión.
  • Aunque no se comentaba en la primera noticia, ya se entreveía la virtualización como apuesta fuerte: con virtualización podemos ejecutar aplicaciones que a priori no son compatibles con el sistema en él. Esta idea no es, ni mucho menos nueva. El máximo exponente de esto, creo yo, es Rosetta de MacOSX, un elemento que casi ningún maquero (yo no lo soy, al menos no 100%) conoce y que permite ejecutar aplicaciones de PowerPC en Macs basados en Intel es muy similar, sino idéntica. Una idea muy acertada, creo yo, sobre todo porque al seguir funcionando el sistema sobre una plataforma x86 la eficiencia de ejecución es mucho mayor que en el caso de Rosetta. LO MÁS IMPORTANTE ES QUE EL USUARIO TENGA CONTROL sobre el virtualizador para que este no coma recursos a lo tonto.
  • Además, como efecto colateral de la virtualización, y esto se comenta ya sólo en la última noticia, el sistema funcionará con un sistema similar a la jaula chroot. No sé si tienen pensado llegar al extremo de chroot, pero si es así: cada aplicación estará completamente aislada de las otras, incluso a nivel de disco (cada aplicación no podría ver datos fuera de su zona de disco), salvo que específicamente se solicite al sistema que dicha aplicación tenga acceso a otra o usando IPCs. Hasta aquí la idea ya estaba implementada en WinNT, sólo que a la hora de la verdad WinNT permitía que hicieran de él un pandero puesto que las aplicaciones de un mismo usuario podían entrar en la memoria de las demás (ESTA ES LA CAUSA, JUNTO CON EL ACCESO AL DISCO, DE TANTO VIRUS DE WINDOWS). Con la jaula la idea es que cada aplicación va a pensar que tiene todo un ordenador sólo para ella. Para comunicarse con otras aplicaciones tendrá que usar sockets, memoria compartida y otros tipos de IPCs. En ocasiones se puede permitir que una aplicación tenga acceso a otra, pero sólo en casos contados. Mi opinión sobre este punto es que ¡¡¡ya era hora!!!
  • En la nueva noticia se habla de cloud-computing y de integración de la web y de internet con el sistema... mi opinión es que esto llega ya tarde, bastante tarde. Todo el tema este de sistema operativo y web es un problema de interfaces y usabilidad más que de infraestructuras: sobre esto mi opinión es que lo que más futuro tiene son los sistemas que carguen en menos de un segundo, en los que las páginas web se integren como un contenido más del sistema, una aplicación más, vamos y desde luego es algo que ya hace tiempo que debió hacer Microsoft. Sobre esto, a ver si publico un artículo que había escrito hace un tiempo sobre el futuro de los navegadores y que habla de la integración de sistema operativo y navegador y en el que defiendo que no C# o C, sino Javascript, sobre .NET o cualquier otro compilador JIT debería ser el lenguaje de peso del sistema, pero sin dejar de lado a C, como ya dije.
Por lo tanto, nada nuevo, aunque eso sí, todo interesante; ya cuando leí la noticia por primera vez me pareció una idea muy interesante.

Fuentes:
http://pixelame.net/story/se-acaba-windows-llega-midori
http://www.error500.net/articulo/midori-microsoft-sistema-operativo-cero
http://www.elpais.com/articulo/internet/Microsoft/prepara/sustituto/virtual/Windows/elpeputec/20080804elpepunet_4/Tes
http://meneame.net/story/microsoft-podria-estar-trabajando-futuro-sin-windows-proyecto-midori
http://www.sdtimes.com/MICROSOFT_S_PLANS_FOR_POST_WINDOWS_OS_REVEALED/About_CLOUDCOMPUTING_and_MOBILEDEVELOPMENT_and_NET_and_SOASAAS_and_SOFTWAREDEVELOPMENT_and_WINDOWS_and_MICROSOFT/32627
http://www.infoworld.com/article/08/07/29/Microsoft_prepares_for_end_of_Windows_with_Midori_1.html
http://research.microsoft.com/os/Singularity/