lunes, 17 de noviembre de 2008

¿Muerte al mercado de segunda mano? Habla un programador del Spore.

La novedad (que por cierto no me sorprende) es que alguien del circulo interno ha hablado. Cito de la fuente original:


Soren Johnson comenta que «la reventa de juegos incrementa la percepción de su valor monetario, y es un poderoso concepto que conecta a jugadores con los juegos». También tiene palabras de benevolencia hacia GameStop (que suele ser la franquicia que se lleva la mayoría de palos cuando un distribuidor despotrica contra la segunda mano), a la que califica «más como una pieza clave en la venta de juegos nuevos, que como un perjuicio por la venta de juegos usados». Además, Johnson dice que «el mercado secundario representa una segmentación beneficiosa del mercado, debido al hecho de que un mismo producto puede tener distinto coste de cara al cliente, que se sentirá más cómodo pagando más por un juego nuevo si sabe que luego podrá revenderlo a un precio razonable y recuperar parte de su valor».


Y es que últimamente empezamos a ver por la esfera de las grandes compañías de vídeo-juegos, supongo que las distribuidoras, que, no contentas con ser la industria más rentable del sector entretenimiento quiere más y más dinero... y es que a los precios un tanto desorbitados a los que nos van acostumbrando se une ahora una manía por eliminar el mercado de préstamo y reventa (venta de segunda mano) de juegos... bajo la justificación de que no cobran, ahora todo hijo de vecino se verá obligado a comprar de primera mano.

Para aquellos que no sepan de que va todo este ajo, tenemos varios platos en la degustación: en primer lugar, en Bélgica, gracias a un poderoso esfuerzo por parte de alguien, se ha prohibido el alquiler (y un aguilucho negro aletea sobre la venta de segunda mano).

Por otro lado tenemos juegos como el ya archi-famoso (y archi-criticado por ello) Spore, cuyos distribuidores, no contentos con cobrar la salvajada que vale... han limitado la cantidad de instalaciones que se pueden realizar a 3, y no es el único. Por suerte EA ha reculado un poco y al parecer ahora resulta que la instalación se limita a 3 simultáneos... pero ya veremos, porque me da que el poder que les da sobre el titular del juego no va a caer en saco roto... o sea, que supongo que impedirán por todos los medios que se revenda el juego.

Las discográficas con grandes éxitos que ya han salido 5 veces y los vídeo-juegos decisexagesimas partes más repetidas que un yo-yo y protecciones para evitar usos indeseados... por si se nos ocurre... las diferencias, si alguna vez existieron, empiezan a diluirse.

Y es que está claro que la realidad es que lo que importa es el dinero y da igual si el cliente está contento o no, si la calidad baja o si los profesionales que viven de ello se van a freír puñetas... siempre, que fluya el dinero hacia los distribuidores. Yo lo que me pregunto es que ocurrirá cuando bajen las ventas de juegos... ¿¿¿harán como las discográficas y pedirán un canon??? (pensad en que los vídeo-juegos se empiezan a declarar cultura en Alemania y otros lares...).

Donde quedará aquello de la edad dorada...


Fuente: http://www.anaitgames.com/el-programador-de-spore-defiende-el-mercado-de-segunda-mano/

viernes, 17 de octubre de 2008

R telecomunicaciones caída toda una tarde

"R" lleva con su salida a internet __PARA TODOS O CASI TODOS SUS CLIENTES__ caída desde las 4 y media (aproximadamente) y hasta hace escasos momentos (son más o menos las once menos cuarto). Por supuesto el número de asistencia colapsado... normal... pusieron un mensaje automático... sí te entraba línea.

La noticia salió en las noticias de la televisión autonómica -TVG- que comentaba que el fallo masivo fue -al parecer- causado por el proveedor "internacional" (todo sea echar pelotas fuera). Esto denota que hasta las operadoras e ISP que se venden como "serio/as" y "fardan" de "clientes contentos" no cuentan con una política realmente seria y robusta, jugando en la cuerda floja de tener una única salida (y no varias e independientes) al exterior (fallos como el de hoy denotan que si no es así, como si lo fuera) seguramente para ahorrar costes.

Actualización: El fallo al parecer se ha producido por un incendio en las vías del tren, por donde va la fibra óptica.

A mi personalmente me tocó un poco las narices, cambio de tareas y listo, pero seguro que más de uno se vio mucho más perjudicado por el corte.

Por suerte, la avería se arregló en un plazo relativamente razonable, dado el impacto del mismo, ya que podría haber significado varios días con el culo al aire... Con otras operadoras -dicen- suele pasar y en plan un cliente por acá y otro por allá, pero "R" no es precisamente de las baratas, y por suerte no permite que clientes puntuales queden sin servicio mucho tiempo. Y es precisamente esto lo que hace que sea tan curioso que esto halla ocurrido.

El otro día (no se si el lunes o el martes) hubo un corte menos drástico: con páginas en USA, algo menos de una hora, creo, lo que ya no sé es si fue sólo para "R", si fue el mismo proveedor o que narices ocurrió. Eso sí, casi no se notó porque Google y otras muchas páginas habituales disponen de servidores en Europa.

¿Será la crisis?

Fuentes:

miércoles, 10 de septiembre de 2008

PHP 6 o como liarla parda!

Para aquellos que programáis en PHP, cada día se acerca más PHP 6, y con esta versión su característica estrella: todo el interior ha sido adaptado para trabajar en UNICODE (UTF-8, UTF-16 ó UTF-32) y con esta maravillosa característica empieza la riada de problemas:
  • Por supuesto miles de scripts que hay ahí fuera dejarán de funcionar -ya lo tienen hecho antes por chorradas menos importantes-.
  • Por ejemplo, todo aquel script que partía del hecho de que muchas de las rutinas de gestión de cadenas eran binary-safe, lo cual nos brindaba la posibilidad de usarlas sobre datos binarios... a la porra... ahora todas esas rutinas son o serán compatibles con UNICODE, por lo que a nada que nos despistemos tendremos una rutina haciendo de las suyas.
  • Luego hay incoherencias -era inevitable-. Un ejemplo: urlencode y urldecode ya se niegan a funcionar sobre cadenas UNICODE, pese a estar, aparentemente homologadas en la lista de funciones UNICODE.
  • En general auguro un pesado y doloroso devenir de PHP 6... se va a tener que programar con pies de plomo muchas de las rutinas, con especial cuidado de controlar en cada momento que estamos haciendo: la mayoría del software para versiones anteriores dejará de funcionar por esta misma razón (varios paquetes actuales que he probado hacen aguas por todos los lados).
Pese a todo lo dicho, estoy totalmente a favor de adoptar UNICODE como nuevo juego de caracteres, ya que es más universal y flexible.

Sin embargo -desde mi punto de vista- la manera en que PHP 6 ha implantado este en su núcleo es más bien una especie de dictadura que de seguro hará rechinar los dientes a más de uno.

Lo más normal en estos casos en crear funciones "paralelas" de manera que quien guste puede ir adoptando el nuevo sistema, poco a poco, sin sobresaltos y además sabiendo que tiene entre manos en cada momento.

El problema empieza cuando PHP decide que en lugar de hacerlo así, todas las cadenas y ficheros de código fuente se pasan a UNICODE, de manera, por decirlo de alguna manera unilateral. Además, y por si fuera poco lo hace de forma transparente, de manera que ahora ya no sabemos si tratamos con datos ASCII ó UNICODE (por lo menos provee nuevas rutinas is_unicode y is_buffer) pero lo curioso es que probándolo en seguida vemos que el core tiene una inherente manía de pasar todo a UNICODE, claro, a nada que adjuntemos alguna cadena definida en el código, esta será UNICODE y convertirá todo a UNICODE.

Por suerte tenemos la posibilidad de hacer casts hacia lo que queramos $variable2=(unicode)$variable1; convierte el contenido de la variable 1 a UNICODE, mientras que $variable2=(binary)$variable1; convierte el contenido a ISO-8859-1 binario. Con esto podemos deshacer algo el entuerto.

Los ficheros se leen en UNICODE siempre que espeficiquemos que es un fichero de texto (con la opción "t" en fopen, si leemos binario con la opción "b" se tratará como binario/ISO-8859-1 lo que leamos).

Por último el código debe estar codificado en UTF-8 también, de lo contrario a la primera "á" tilde o similar que haya (salvo en comentarios) la compilación se detendrá y habrá error. Para usar código ISO-8859-1 debemos declarar en la primera orden que el fichero es de este tipo con:

declare(encoding='iso-8859-1');

Al principio de todos nuestros ficheros de código con tildes y en ISO-8859-1, y pese a ello se convertirá dinámicamente todo a UNICODE. Un show vamos, yo ya estoy adaptando el código que tengo hecho en PHP a este nuevo sistema... no se cuanto tardará en publicarse la versión 6, pero dudo que tarde mucho.

Enlaces:
Lista de compatibilidad de funciones con UNICODE: http://www.php.net/~scoates/unicode/render_func_data.php

miércoles, 3 de septiembre de 2008

Google Chrome... me pone los pelos de punta

Supongo que ya sabéis que Google ha sacado su navegador, creo que hace menos de una hora, puede que algo más...

Se puede descargar en http://www.google.com/chrome (yo lo he visto en la página principal de Google, aunque ya había leído antes sobre el detalle).

Lo que más sorprende es que dispone de gestión de memoria, recursos y CPU por cada pestaña y permite matar pestañas, vamos, que más que navegador es un sistema operativo dentro del sistema operativo.

Más allá de que integre un 90% de elementos de otros navegadores y plug-ins de navegadores... tiene muchas novedades. Es sin duda un pequeño paso para Google, pero un gran paso para los navegadores (LEER ACTUALIZACIÓN 1).

También tenemos este vídeo que creo que os resultará muy interesante: las razones para desarrollar el "artilugio" de la mano de sus creadores, o de sus portavoces, vamos, de parte de Google:



Es curioso cómo se ha llevado todo lo referente a Chrome, el secretismo y todo eso frente a los autobombos, noticias hinchadas, globos sonda y demás que se suelen ver por la red últimamente.

Y sobre eso, la chorrada del día: la anécdota de los pelos de punta... leed esto:

http://barrapunto.com/~iagofg/journal/30155

¿No le encontráis un leve parecido?

Voy a ponerme a leer posos del café un día de estos y espero no ver nada acerca del LHC xDDDD

ACTUALIZACIÓN (1): desde mi punto de vista, una vez probado, y aunque todavía no lo he usado mucho, ya he probado lo de "vista de aplicación separada", sin el navegador y todo eso... es una pena que no se hallan puesto a integrar más el tinglado en el sistema operativo, escritorio o que lo hallan hecho más al estilo de los applets de Opera... me recuerda mucho al Prism. Realmente lo único bueno y novedoso que introduce este navegador es el tema del Administrador de Tareas. ¿Conocéis algún otro navegador con algo similar?

ACTUALIZACIÓN (2): respecto al rendimiento y avidez de recursos, al parecer es más liviano que el Firefox. Sin embargo en lo referente al rendimiento me confunde: parece que también va más ligerillo, pero sin embargo parece que echa el freno para determinadas tareas... debe ser control de prioridad de ráfaga. Si realmente implementa control de ráfagas... es la caña (para aquellos que les suene a chino, con esto me refiero a que si un Javascript de una página se vuelve muy ávido momentáneamente, el navegador lo controla de cerca regulando su %CPU asignado).

ACTUALIZACIÓN (3): Sinceramente el Chrome se va a volver un experimento de como una empresa poderosa puede introducir un producto... está puesto en la página principal de Google... me pregunto hasta que % de penetración llegará... dudo que supere a Firefox pero sí será interesante ver hasta que tasa llega.

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/

jueves, 31 de julio de 2008

pBits

Un Blog especializado en tecnologías, fundamentalmente de la información.

Buscaré más la calidad que la cantidad de posts. Espero que a lo largo de este tiempo que sigue os resulte interesante e inspirador lo que aquí voy a publicar.

Ya digo de antemano que, lógicamente, no me hago responsable de los comentarios que escribáis ni de que os aburráis como ostras leyéndome, pero admito sugerencias y/o críticas sobre lo escrito o la forma de contarlo.

¡¡Un saludo y espero que en breve nos veamos!!