Nueva restricción por parte de Google en Gmail. Desde al menos el mes pasado (septiembre 2014) se ha restringido la opción de usar los servidores de correo salientes de Google para dar de alta nuevos alias en las cuentas de Gmail.
Puede parecer una tontería, pero a partir de ahora ya no es posible usar Gmail como cliente de cuentas alias o redireccionadas.
Google va redirigiendo cada vez más su mercado de trabajo hacia el sector empresarial y de dispositivos y da un paso más en el continuo cierre de servicios y funcionalidades que viene realizando de manera más agresiva en los últimos dos años.
martes, 21 de octubre de 2014
viernes, 12 de septiembre de 2014
Comparando TinyCC vs Visual C++ 2012 Express vs PicoC vs Otras Máquinas Virtuales
He realizado una prueba de velocidad entre estos diferentes compiladores de C y varias máquinas virtuales con idea de ver en que orden de magnitud se mueve cada uno de los lenguages y plataformas.
El código de prueba son dos for anidados con varias operaciones matemáticas para generar interdependencia en su interior. Es un tanto arbitrario, pero creo que suficiente para comparar la ejecución de código interdependiente.
Respecto a los compiladores (o interpretes) de C, todos ejecutando el mismo código:
Ahora pasamos a plataformas de máquina virtual, respetando el código al máximo (apenas hizo falta reemplazar las declaraciones de las variables según el lenguaje y los printf por la instrucción adecuada). El resultado:
Sorprende en positivo el rendimiento de Java SE y muy en negativo el rendimiento de PicoC.
El código de prueba son dos for anidados con varias operaciones matemáticas para generar interdependencia en su interior. Es un tanto arbitrario, pero creo que suficiente para comparar la ejecución de código interdependiente.
Respecto a los compiladores (o interpretes) de C, todos ejecutando el mismo código:
- 1 segundo aproximadamente en promedio TinyCC (tardó 1 segundo en ejecutar la prueba).
- 1 segundo aprox. Visual C++ (con las opciones por defecto).
- 0.15 segundos aprox. 6 veces más rápido, Visual C++ con /O2 (optimizar velocidad)
- 600 segundos aprox. PicoC.
Ahora pasamos a plataformas de máquina virtual, respetando el código al máximo (apenas hizo falta reemplazar las declaraciones de las variables según el lenguaje y los printf por la instrucción adecuada). El resultado:
- 4 segundos aproximadamente Chrome 35 ejecutando en Javascript estándar.
- 1.5 segundos aproximadamente Firefox 31.
- 0.15 segundos aproximadamente Java 1.8 SE 64bits.
- 1 segundo aproximadamente en C#, Mono 2.0, ejecutandose en Unity 3D.
- 60 segundos aproximadamente PHP 5.
Sorprende en positivo el rendimiento de Java SE y muy en negativo el rendimiento de PicoC.
sábado, 31 de mayo de 2014
Inestabilidad de Flash en Google Chrome y otros golpes bajos a Java y otros plugins
De un tiempo ha esta parte me ha sorprendido un hecho sorprendente: en el Google Chrome el Flash Player no deja de colgarse.
Por un momento pensé que sería cosa de Adobe, por un pobre mantenimiento del plugin pero cual ha sido mi sorpresa cuando en Firefox, con la misma versión y todo igual estos problemas no se producen. Es un problema reproducible y que ocurre el 100% de las veces al cargarse los reproductores y que deja colgada la pestaña impidiendo navegar y dando una imagen penosa del Flash (más penoso si cabe cuando Chrome supuestamente se encargar de mantener Flash al día).
Y esto se suma a los tumbos que viene dando Oracle respecto a los applets de Java, obligando a todos los desarrolladores a dar explicaciones a clientes descontentos. Todos sabíamos que la obligación de firmar los applets no iba a llevar a ningún lugar.
No es que esté a favor de los plugins de Java o de Flash, de hecho no me gustan, pero no dejo de sentir que todos estos movimientos son chapuzas. Son movimientos necesarios para garantizar la seguridad de los usuarios pero otra solución más eficiente hubiera sido mucho más útil.
En lugar de esto se sucedió una cadena de absurdos: primero fue la obligación de firmar applets incluso sin acceso privilegiado si no querías ver un aviso, luego obligaron a que fuera firmado con certificado. Luego como ya estaba cantado, esa chapuza no llegó y tuvieron que pedir confirmación para todo: los hackers pueden comprar certificados también, es más, seguramente no tengan que convencer a ningún cliente para ello (la medida perjudica más a los desarrolladores honrados que a cualquier otro sector). Luego para ejecutar un applet no firmado había que hacer un cambio en la configuración de windows y ahora finalmente ante la avalancha de quejas directamente prohibieron los applets no firmados. ¿Es que creen que la firma con certificado de entidad autorizada supone alguna diferencia? Como si ahora los usuarios diferenciaran entre los mensajes de un applet que está fabricado por alguien que ha demostrado su identidad. El problema es que los usuarios no leen: quitadles los cuadros modales y que tengan que hacer clic en un checkbox y un enlace dentro del applet para cargarlo y ya veréis como bajan las quejas. Pero no, en lugar de eso PROHIBICIÓN TOTAL de applets no firmados.
Es cierto que son productos privados, y pueden hacer lo que quieran, y no se puede hacer nada, pero eso no quita que que queje en un blog con verborrea a gusto sobre su actitud dictatorial encubierta ;)
¿Qué hacer frente a esto? ¿Hay alguna alternativa?
Pues no sé, yo por ahora ajo y agua.
Si un cliente necesita ejecutar un applet a narices se le pasa el presupuesto de certificado y presupuesto de adaptar el applet como aplicación.
Se le da la alternativa totalmente desaconsejada y chapucera de instalar una versión antigua de Java (y eso cuando no la piden ellos directamente, que tontos tampoco son; al menos se les fuerza a desactivar java para internet en general).
MORALEJA: ¿las medidas de estos señores han conseguido algo? por mi parte me da la sensación de que son medidas que dan una falsa sensación de seguridad, escurren el bulto de la culpa, impiden el correcto funcionamiento y en muchos casos logran el efecto contrario que supuestamente buscan, por lo que tiendo a pensar que lo que quieren es sacarse el soporte a estos productos de encima como puedan... aunque incluso eso lo podrían hacer más elegantemente.
Gracias por nada Oracle, Adobe y Google!
Por un momento pensé que sería cosa de Adobe, por un pobre mantenimiento del plugin pero cual ha sido mi sorpresa cuando en Firefox, con la misma versión y todo igual estos problemas no se producen. Es un problema reproducible y que ocurre el 100% de las veces al cargarse los reproductores y que deja colgada la pestaña impidiendo navegar y dando una imagen penosa del Flash (más penoso si cabe cuando Chrome supuestamente se encargar de mantener Flash al día).
Y esto se suma a los tumbos que viene dando Oracle respecto a los applets de Java, obligando a todos los desarrolladores a dar explicaciones a clientes descontentos. Todos sabíamos que la obligación de firmar los applets no iba a llevar a ningún lugar.
No es que esté a favor de los plugins de Java o de Flash, de hecho no me gustan, pero no dejo de sentir que todos estos movimientos son chapuzas. Son movimientos necesarios para garantizar la seguridad de los usuarios pero otra solución más eficiente hubiera sido mucho más útil.
En lugar de esto se sucedió una cadena de absurdos: primero fue la obligación de firmar applets incluso sin acceso privilegiado si no querías ver un aviso, luego obligaron a que fuera firmado con certificado. Luego como ya estaba cantado, esa chapuza no llegó y tuvieron que pedir confirmación para todo: los hackers pueden comprar certificados también, es más, seguramente no tengan que convencer a ningún cliente para ello (la medida perjudica más a los desarrolladores honrados que a cualquier otro sector). Luego para ejecutar un applet no firmado había que hacer un cambio en la configuración de windows y ahora finalmente ante la avalancha de quejas directamente prohibieron los applets no firmados. ¿Es que creen que la firma con certificado de entidad autorizada supone alguna diferencia? Como si ahora los usuarios diferenciaran entre los mensajes de un applet que está fabricado por alguien que ha demostrado su identidad. El problema es que los usuarios no leen: quitadles los cuadros modales y que tengan que hacer clic en un checkbox y un enlace dentro del applet para cargarlo y ya veréis como bajan las quejas. Pero no, en lugar de eso PROHIBICIÓN TOTAL de applets no firmados.
Es cierto que son productos privados, y pueden hacer lo que quieran, y no se puede hacer nada, pero eso no quita que que queje en un blog con verborrea a gusto sobre su actitud dictatorial encubierta ;)
¿Qué hacer frente a esto? ¿Hay alguna alternativa?
Pues no sé, yo por ahora ajo y agua.
Si un cliente necesita ejecutar un applet a narices se le pasa el presupuesto de certificado y presupuesto de adaptar el applet como aplicación.
Se le da la alternativa totalmente desaconsejada y chapucera de instalar una versión antigua de Java (y eso cuando no la piden ellos directamente, que tontos tampoco son; al menos se les fuerza a desactivar java para internet en general).
MORALEJA: ¿las medidas de estos señores han conseguido algo? por mi parte me da la sensación de que son medidas que dan una falsa sensación de seguridad, escurren el bulto de la culpa, impiden el correcto funcionamiento y en muchos casos logran el efecto contrario que supuestamente buscan, por lo que tiendo a pensar que lo que quieren es sacarse el soporte a estos productos de encima como puedan... aunque incluso eso lo podrían hacer más elegantemente.
Gracias por nada Oracle, Adobe y Google!
Suscribirse a:
Entradas (Atom)