La nueva propaganda para la revista. Gracias a todos los clientes, los nuevos y los que a través de los años siguen confiando.
Buscador de Google
Microsoft cerrara Hotmail.com por Outlook.com
Microsoft anunció el mayor cambio a su sistema de correos en línea, que incluye no sólo nuevo diseño y funciones, sino cambio de nombre. Hotmail.com dará paso a una nueva etapa llamada Outlook.com, la que se puede probar desde ya.
La opción de Microsoft de cambiar de Hotmail a Outlook parece ser sencilla: Outlook sigue siendo el sistema de correos más utilizado en oficinas y trabajos, por lo que es una marca consolidada en el mercado, con la que esperan conquistar el sector más adulto.
Destaca primero su diseño, similar a la interfaz Metro, usada tanto en Windows Phone como en el futuro Windows 8, con un orden que permite ver en una misma ventana las etiquetas, la lista de correos, el contenido y la información del contacto.
La principal novedad de esta nueva casilla es su interconexión con redes sociales. El usuario podrá asignar sus cuentas de Facebook, Twitter y LinkedIn y enviar o recibir mensajes de cada servicio dentro de la misma página. Incluso ofrece la posibilidad de hablar por teleconferencia a través de Skype y sin necesidad de bajar el programa.
El nuevo Outlook también es un servicio más inteligente, ya que permite agrupar automáticamente los correos que son enviados por tus redes sociales, los newsletters o de trabajo, para llegar más rápido a los correos que uno de verdad quiere.
Otra de las ventajas que posee es el tratamiento de los archivos adjuntos: las fotos enviadas pueden verse en un modo de visualización como galería o diapositivas, y los documentos, a través de una versión online y gratuita de Office, similar a lo que ofrece Gmail.
Outlook.com también se integra con Skydrive, el disco duro virtual de Microsoft y que permite tener 25 GB de espacio en la nube gratis.
¿Qué pasará con Hotmail? Sus usuarios pueden estar tranquilos, ya que todos los cambios serán aplicados a los correos de Microsoft, como @live.com, conservando su dirección. Pero las cuentas nuevas deberán adoptar el nombre de la nueva etapa de Microsoft: outlook.com
Destaca primero su diseño, similar a la interfaz Metro, usada tanto en Windows Phone como en el futuro Windows 8, con un orden que permite ver en una misma ventana las etiquetas, la lista de correos, el contenido y la información del contacto.
La principal novedad de esta nueva casilla es su interconexión con redes sociales. El usuario podrá asignar sus cuentas de Facebook, Twitter y LinkedIn y enviar o recibir mensajes de cada servicio dentro de la misma página. Incluso ofrece la posibilidad de hablar por teleconferencia a través de Skype y sin necesidad de bajar el programa.
El nuevo Outlook también es un servicio más inteligente, ya que permite agrupar automáticamente los correos que son enviados por tus redes sociales, los newsletters o de trabajo, para llegar más rápido a los correos que uno de verdad quiere.
Otra de las ventajas que posee es el tratamiento de los archivos adjuntos: las fotos enviadas pueden verse en un modo de visualización como galería o diapositivas, y los documentos, a través de una versión online y gratuita de Office, similar a lo que ofrece Gmail.
Outlook.com también se integra con Skydrive, el disco duro virtual de Microsoft y que permite tener 25 GB de espacio en la nube gratis.
¿Qué pasará con Hotmail? Sus usuarios pueden estar tranquilos, ya que todos los cambios serán aplicados a los correos de Microsoft, como @live.com, conservando su dirección. Pero las cuentas nuevas deberán adoptar el nombre de la nueva etapa de Microsoft: outlook.com
Nuevo supervirus golpea Sudamérica
En principio, el nuevo virus informático, ACAD/Medre.A, procede de servidores chinos y ya ha afectado a computadoras en USA, Colombia y Perú. Inicialmente el virus, detectado por la compañía de ciberseguridad ESET, se camuflaba bajo plantillas delprograma de arquitectura Autocad y tiene la capacidad de robar planos incluso antes de ser terminados.
El mundo está en medio de una guerra cibernética sin precedentes que hace que peligrosas armas cibernéticas hayan sido liberadas por toda la red. A los recientes descubrientos en torno a Flame o Stuxnet (relacionados entre ellos) se suma la aparición de un nuevo virus, apodado ACAD/Medre.A.
El malware fue detectado por la compañía de ciberseguridad ESET. La mayoría de los ordenadores infectados se encontraban en Perú, pero también se han registrado víctimas en Ecuador, Colombia y USA. El nuevo gusano digital robaba los ficheros del popular programa de diseño e ingeniería industrial AutoCAD y los reenviaba a los correos electrónicos de las página de dos proveedores de internet en China (163.com y qq.com).
Todavía no está claro si los recipientes de los correos de verdad eran chinos o los 'hackers' sólo registraron una cuenta en China para despistar a las autoridades. El virus ha sido concebido para robar diseños y planos en una operación internacional de espionaje industrial.
Según los expertos de ESET, el virus se difundió a través de una plantilla de AutoCAD descargada por las compañías peruanas.
Otras compañías que colaboran con las peruanas se vieron obligadas a descargarla también, lo que extendió el contagio. “ACAD/Medre.A es un ejemplar peligroso de espionaje industrial”, dice Richard Zweinenberg, experto de ESET. “Cada nuevo diseño se envía automáticamente a los creadores del virus. Este robo puede causar gran daño material porque los 'hackers' tienen la posibilidad de usar el diseño antes que su autor”.
El expertó subraya que los hackers pueden ir más allá y obtener la patente del diseño antes de que lo haga sus legítimo poseedor. ESET ha trabajado con el ISP chino Tencent, con el Centro Nacional de Respuestas ante Emergencias de Virus Informáticos de China y con Autodesk, el fabricante de AutoCAD, para detener la transmisión de esos archivos. Como medida preventiva ESET ha puesto a disposición de los usuarios una herramienta gratuita de limpieza.
Stuxnet y Flame: Los antivirus no pueden hacer nada
La ciberguerra velada que se lleva a cabo en todo el mundo, con ataques chinos a USA, virus informáticos contra Irán y operaciones de inteligencia encubiertas en Internet (llamese Wikileaks), tiene como víctimas a toda la población, como suele ser en toda guerra. La reciente revelación de que Obama ordenó los ataques con Stuxnet contra Irán y la promesa de la prolongación de la guerra informática arrojan perspectivas desesperanzadoras que incluso los expertos en seguridad informatica no tardan en advertir.
Mikko Hypponen es jefe de investigaciones de F-Secure, una empresa de seguridad informática que cuenta con la experiencia de haber combatido ataques de virus como Loveletter, Blaster, Conficker y Stuxnet. Reflejando la postura de la industria de los antivirus sobre la ciberguerra que enfrenta a potencias de todo el mundo, escribe para Wired la nota titulada "Por qué compañías como la mía fallaron en atrapar a Flame y Stuxnet":
"Hace un par de días recibí un correo electrónico desde Irán. Era enviado por un analista del Equipo de Respuestas de Emergencia Informática de Irán y me informaba acerca de una pieza de malware que había sido encontrada infectando computadoras iraníes. Esto resultó ser Flame: el malware que hoy por hoy ocupa las portadas de los medios de todo el mundo.
A medida que escarbabamos en nuestros archivos para encontrar ejemplos similares a este malware, nos sorprendimos al encontrar que ya teníamos ejemplos del Flame, que databan de 2010 y 2011 y que sin saberlo manteníamos en nuestras PC's. Habían llegado a través de mecanismos automáticos de reporte, pero nunca habían sido marcados por el sistema como algo que debía examinarse de cerca. Investigadores de otras firmas de antivirus habían encontrado evidencia de que tenían muestras del malware incluso antes del 2010.
Lo que eso significa es que todos nosotros hemos fallado en detectar este malware desde hace dos años o mas. Ese es un fallo espectacular para nuestra compañía y para la industria de los antivirus en general.
Esta no es la primera vez que algo así sucede, de cualquier manera. Stuxnet no fue detectado por más de un año luego de haber sido liberado y no fue detectado hasta que una compañía de antivirus de Bielorusia fue llamada a irán para revisar unas computadoras que presentaban problemas. Cuando los investigadores buscaron entre los archivos algo similar al Stuxnet, encontraron que el mecanismo usado en Stuxnet había sido empleado con anterioridad en otros malware, pero nunca se notificó a tiempo el hallazgo. Un malware relacionado, llamado DuQu también fue indetectable para los antivirus por más de un año.
Stuxnet, Duqu y Flame no sn normales, por supuesto. Los tres parecen haber sido desarrollados por agencias de inteligencia occidentales como parte de operaciones encubiertas que no fueron hechas para ser descubiertas. El hecho de que el malware pueda evadir su detección prueba lo bien que los atacantes hicieron su trabajo. En el caso de Stuxnet y DuQu, usaron componentes digitales reconocidos para hacer que su malware apareciera como aplicaciones fiables. Y en vez de tratar de ocultarse con los métodos usuales, que habría puesto una sospecha sobre ellos, se "escondieron" a la vista de todos. En el caso de Flame, se usaron librerías LUA, SQLite, SSH y SSL para hacer pasar al código malware como una base de datos comercial
Algunos podrán argumentar que es bueno que hayamos fallado al buscar esas piezas de código. Lamayoría de las infecciones ocurren en lugares del mundo politicamente turbulentos, en países como Irán, Sudán o Siria. No se sabe con certeza para qué fue usado el Flame, pero es posible que si hubieramos detectado y bloqueado a tiempo el código, indirectamente hubieramos ayudado a regímenes opresivos en esos países en contra de los esfuerzos de las agencias de inteligencia extranjeras para monitorearlos.
Pero ese no es el punto. Nosotros queremos detectar malware, sin importar su fuente o propósito. La politica ni siquiera entra en la discusión ni debería hacerlo. Cualquier malware, incluso los detectados, puede inhabilitar y causar un "daño colateral" a máquinas que no son el objetivo del ataque. Stuxnet, por ejemplo, se esparció por el mundo a través ed su función de 2gusano" vía USB e infectó a más de 100 mil computadoras mientras buscaba su objetivo real, lascomputadoras que cntrolaban el enriquecimiento de uranio en Natanz, Irán. En resumen, es nuestro trabajo como industria proteger a las computadoras del malware. Eso es.
Y hemos fallado al hacer eso con el Stuxnet, DuQu y Flame. Y eso pone a nuestros clientes algo nerviosos.
Es altamente probable que haa otros ataques similares en camnino que no hemos detectado aún. Para ponerlo de manera sencilla, a los atacantes les gusta su trabajo. Lo cierto es que incluso los cnsumidores de antivirus de alta gama pueden protegerse de los ataques de malware creados por estados con recursos abultados. Los antivirus coomunes pueden protegerlo de malware común como los troyanos de cuentas bancarias, los capturadores de teclado o los gusanos de Correos electrónicos. Sin embargo, ataques dirigidos como estos hacen todo lo posible para evitar los antivirus a propósito. Y los recursos utilizados en estos ataques son desconocidos para las compañías antivirus, por definición. Hasta donde podemos decir, antes ed lanzar sus códigos maliciosos, los atacantes los testearon con todos los antivirus más conocidos en el mercado para asegurarse de que su malware no sería detectado. Tienen tiempo ilimitado para perfeccionar sus ataques. No es una guerra justa entre atacantes y defensores cuando los atacantes tienen acceso a nuestras armas.
Los sistemas antivirus tienen que acertar en el balance entre detectar todas las posibles amenazas sin generar falsas alarmas. Y mientras tratamos de mejorar esto todo el tiempo, nunca habrá una solución 100% efectiva. La mejor protección contra los ataques. La mejor protección posible requiere de una defensa por capas, con sistemas de detección de intrusos de red, listas blancas contra el malware conocido y la vigilancia activa del tráfico entrante y saliente de la red de una organización.
Flame fue una falla para la industria de los antivirus. Realmente deberíamos poder hacerlo mejor. Pero no podemos. Estamos fuera de la liga, en nuestro propio juego".
Flame=Angry Birds
Como si sostuviera las palabras de Hypponen, recientemente se descubrió que el virus Flame fue escrito con el mismo lenguaje de programación que el juego Angry Birds, según informó un canal de noticias estadounidense.
Aunque la complejidad y funcionalidad de Flame supera a otras amenazas cibernéticas conocidas hasta la fecha, fue construido utilizando el lenguaje de programación LUA, el mismo que el del popular juego interactivo, dijo el ex empleado del Grupo de Inteligencia Aérea, Cedric Leighton.
“Las personas que desarrollaron el software malicioso encontraron una ingeniosa manera de utilizar un código que no forma parte del arsenal habitual de un hacker y eso hizo que sea más difícil de detectarlo“, añadió Leighton.
El programa, capaz de capturar todo el tráfico de la red local, activar micrófonos, enviar registros de tráfico y redirigir mensajes instantáneos, permite al atacante acceder al sistema infectado sin que el usuario sea consciente de ello.
Tras estallar el escándalo acerca del peligroso virus de ciberespionaje, Irán anunció que ya dispone de una herramienta capaz de identificarlo y eliminarlo.
Por su parte, el proveedor de seguridad digital ruso Kapersky, quien dio a conocer la noticia de su existencia el pasado 29 de mayo, advirtió que el virus podría llevar años circulando de forma oculta y que algunas de sus capacidades permiten considerarlo como un arma destinada para la ciberguerra.
A las ordenes de Obama
El actual presidente de USA, Barak Obama, ordenó aumentar el volumen de ciberataques contra Irán. Obama decidió aumentar los esfuerzos de una iniciativa de George Bush y asediar los sistemas de Irán para intentar frenar su desarrollo nuclear. Entre las campañas de ciberarmas que Obama aprobó se encuentra Stuxnet, virus que se desarrolló con la colaboración de Israel.
En 2011 los sistemas informáticos de Irán, sobre algunos relacionados con su programa nuclear, sufrieron varios ataques informáticos importantes. Stuxnet fue el virus que protagonizó el ataque más significativo, que llegó a afectar a parte de las centrifugadoras del programa nuclear. La complejidad del virus hizo que los expertos buscasen su origen de forma masiva, pero nunca llegó a saberse su procedencia.
Tras la aparición de Stuxnet, se especuló con que podría ser fruto de un proyecto conjunto entre el ejército de USA y el de Israel, que buscarían inutilizar los sistemas iraníes para frenar su desarrollo nuclear y dificultar una posible acción de guerra contra Israel. Sin embargo, hasta ahora no había habido confirmación de que estos países estuviesen detrás de Stuxnet.
Un año después, el diario 'The New York Times' apunta directamente a Barak Obama como el responsable de autorizar el desarrollo y la utilización de Stuxnet y otras ciberarmas. El diario cita a personal del programa de desarrollo de estas iniciativas para confirmar que Estados Unidos e Israel fueron los responsables de los ataques contra Irán. Las fuentes no han sido identificadas por cuestiones de seguridad.
Según dichas fuentes, Barak Obama, después de suceder a George Bush, se encontró con un programa denominado 'Olympic Games', enfocado al desarrollo de ciberarmas. Obama decidió aumentar los recursos a este plan y autorizó de forma directa que se realizasen ataques contra los sistemas iraníes.
Entre Estados Unidos e Israel desarrollaron distintas ciberarmas, entre las que destacó Stuxnet. Este gusano consiguió causar daños en los sistemas nucleares de Irán, objetivo principal de la ofensiva. USA e Israel perseguían frenar lo máximo posible la campaña de desarrollo nuclear de Irán, al mismo tiempo que pensaban debilitar al país ante un posible ataque contra la propia Israel.
Tras realizar los ataques con Stuxnet, virus que se asegura que tiene un código 50 veces más complejo que un malware normal, los analistas aseguraron que se había conseguido retrasar en aproximadamente 18 meses el desarrollo nuclear de Irán. Por su parte, Irán aseguró que había conseguido controlar Stuxnet y que el virus no había afectado a sus sistemas.
Las fuentes de The New York Times confirman así que USA, que ya había anunciado el desarrollo de ciberarmas, habría realizado su primer ataque en la Red. Pese a que el proyecto lo inició George Bush, Obama sería el responsable de haber coordinado las acciones y haber dado las órdenes directas para su aplicación.
Mikko Hypponen es jefe de investigaciones de F-Secure, una empresa de seguridad informática que cuenta con la experiencia de haber combatido ataques de virus como Loveletter, Blaster, Conficker y Stuxnet. Reflejando la postura de la industria de los antivirus sobre la ciberguerra que enfrenta a potencias de todo el mundo, escribe para Wired la nota titulada "Por qué compañías como la mía fallaron en atrapar a Flame y Stuxnet":
"Hace un par de días recibí un correo electrónico desde Irán. Era enviado por un analista del Equipo de Respuestas de Emergencia Informática de Irán y me informaba acerca de una pieza de malware que había sido encontrada infectando computadoras iraníes. Esto resultó ser Flame: el malware que hoy por hoy ocupa las portadas de los medios de todo el mundo.
A medida que escarbabamos en nuestros archivos para encontrar ejemplos similares a este malware, nos sorprendimos al encontrar que ya teníamos ejemplos del Flame, que databan de 2010 y 2011 y que sin saberlo manteníamos en nuestras PC's. Habían llegado a través de mecanismos automáticos de reporte, pero nunca habían sido marcados por el sistema como algo que debía examinarse de cerca. Investigadores de otras firmas de antivirus habían encontrado evidencia de que tenían muestras del malware incluso antes del 2010.
Lo que eso significa es que todos nosotros hemos fallado en detectar este malware desde hace dos años o mas. Ese es un fallo espectacular para nuestra compañía y para la industria de los antivirus en general.
Esta no es la primera vez que algo así sucede, de cualquier manera. Stuxnet no fue detectado por más de un año luego de haber sido liberado y no fue detectado hasta que una compañía de antivirus de Bielorusia fue llamada a irán para revisar unas computadoras que presentaban problemas. Cuando los investigadores buscaron entre los archivos algo similar al Stuxnet, encontraron que el mecanismo usado en Stuxnet había sido empleado con anterioridad en otros malware, pero nunca se notificó a tiempo el hallazgo. Un malware relacionado, llamado DuQu también fue indetectable para los antivirus por más de un año.
Stuxnet, Duqu y Flame no sn normales, por supuesto. Los tres parecen haber sido desarrollados por agencias de inteligencia occidentales como parte de operaciones encubiertas que no fueron hechas para ser descubiertas. El hecho de que el malware pueda evadir su detección prueba lo bien que los atacantes hicieron su trabajo. En el caso de Stuxnet y DuQu, usaron componentes digitales reconocidos para hacer que su malware apareciera como aplicaciones fiables. Y en vez de tratar de ocultarse con los métodos usuales, que habría puesto una sospecha sobre ellos, se "escondieron" a la vista de todos. En el caso de Flame, se usaron librerías LUA, SQLite, SSH y SSL para hacer pasar al código malware como una base de datos comercial
Algunos podrán argumentar que es bueno que hayamos fallado al buscar esas piezas de código. Lamayoría de las infecciones ocurren en lugares del mundo politicamente turbulentos, en países como Irán, Sudán o Siria. No se sabe con certeza para qué fue usado el Flame, pero es posible que si hubieramos detectado y bloqueado a tiempo el código, indirectamente hubieramos ayudado a regímenes opresivos en esos países en contra de los esfuerzos de las agencias de inteligencia extranjeras para monitorearlos.
Pero ese no es el punto. Nosotros queremos detectar malware, sin importar su fuente o propósito. La politica ni siquiera entra en la discusión ni debería hacerlo. Cualquier malware, incluso los detectados, puede inhabilitar y causar un "daño colateral" a máquinas que no son el objetivo del ataque. Stuxnet, por ejemplo, se esparció por el mundo a través ed su función de 2gusano" vía USB e infectó a más de 100 mil computadoras mientras buscaba su objetivo real, lascomputadoras que cntrolaban el enriquecimiento de uranio en Natanz, Irán. En resumen, es nuestro trabajo como industria proteger a las computadoras del malware. Eso es.
Y hemos fallado al hacer eso con el Stuxnet, DuQu y Flame. Y eso pone a nuestros clientes algo nerviosos.
Es altamente probable que haa otros ataques similares en camnino que no hemos detectado aún. Para ponerlo de manera sencilla, a los atacantes les gusta su trabajo. Lo cierto es que incluso los cnsumidores de antivirus de alta gama pueden protegerse de los ataques de malware creados por estados con recursos abultados. Los antivirus coomunes pueden protegerlo de malware común como los troyanos de cuentas bancarias, los capturadores de teclado o los gusanos de Correos electrónicos. Sin embargo, ataques dirigidos como estos hacen todo lo posible para evitar los antivirus a propósito. Y los recursos utilizados en estos ataques son desconocidos para las compañías antivirus, por definición. Hasta donde podemos decir, antes ed lanzar sus códigos maliciosos, los atacantes los testearon con todos los antivirus más conocidos en el mercado para asegurarse de que su malware no sería detectado. Tienen tiempo ilimitado para perfeccionar sus ataques. No es una guerra justa entre atacantes y defensores cuando los atacantes tienen acceso a nuestras armas.
Los sistemas antivirus tienen que acertar en el balance entre detectar todas las posibles amenazas sin generar falsas alarmas. Y mientras tratamos de mejorar esto todo el tiempo, nunca habrá una solución 100% efectiva. La mejor protección contra los ataques. La mejor protección posible requiere de una defensa por capas, con sistemas de detección de intrusos de red, listas blancas contra el malware conocido y la vigilancia activa del tráfico entrante y saliente de la red de una organización.
Flame fue una falla para la industria de los antivirus. Realmente deberíamos poder hacerlo mejor. Pero no podemos. Estamos fuera de la liga, en nuestro propio juego".
Flame=Angry Birds
Como si sostuviera las palabras de Hypponen, recientemente se descubrió que el virus Flame fue escrito con el mismo lenguaje de programación que el juego Angry Birds, según informó un canal de noticias estadounidense.
Aunque la complejidad y funcionalidad de Flame supera a otras amenazas cibernéticas conocidas hasta la fecha, fue construido utilizando el lenguaje de programación LUA, el mismo que el del popular juego interactivo, dijo el ex empleado del Grupo de Inteligencia Aérea, Cedric Leighton.
“Las personas que desarrollaron el software malicioso encontraron una ingeniosa manera de utilizar un código que no forma parte del arsenal habitual de un hacker y eso hizo que sea más difícil de detectarlo“, añadió Leighton.
El programa, capaz de capturar todo el tráfico de la red local, activar micrófonos, enviar registros de tráfico y redirigir mensajes instantáneos, permite al atacante acceder al sistema infectado sin que el usuario sea consciente de ello.
Tras estallar el escándalo acerca del peligroso virus de ciberespionaje, Irán anunció que ya dispone de una herramienta capaz de identificarlo y eliminarlo.
Por su parte, el proveedor de seguridad digital ruso Kapersky, quien dio a conocer la noticia de su existencia el pasado 29 de mayo, advirtió que el virus podría llevar años circulando de forma oculta y que algunas de sus capacidades permiten considerarlo como un arma destinada para la ciberguerra.
A las ordenes de Obama
El actual presidente de USA, Barak Obama, ordenó aumentar el volumen de ciberataques contra Irán. Obama decidió aumentar los esfuerzos de una iniciativa de George Bush y asediar los sistemas de Irán para intentar frenar su desarrollo nuclear. Entre las campañas de ciberarmas que Obama aprobó se encuentra Stuxnet, virus que se desarrolló con la colaboración de Israel.
En 2011 los sistemas informáticos de Irán, sobre algunos relacionados con su programa nuclear, sufrieron varios ataques informáticos importantes. Stuxnet fue el virus que protagonizó el ataque más significativo, que llegó a afectar a parte de las centrifugadoras del programa nuclear. La complejidad del virus hizo que los expertos buscasen su origen de forma masiva, pero nunca llegó a saberse su procedencia.
Tras la aparición de Stuxnet, se especuló con que podría ser fruto de un proyecto conjunto entre el ejército de USA y el de Israel, que buscarían inutilizar los sistemas iraníes para frenar su desarrollo nuclear y dificultar una posible acción de guerra contra Israel. Sin embargo, hasta ahora no había habido confirmación de que estos países estuviesen detrás de Stuxnet.
Un año después, el diario 'The New York Times' apunta directamente a Barak Obama como el responsable de autorizar el desarrollo y la utilización de Stuxnet y otras ciberarmas. El diario cita a personal del programa de desarrollo de estas iniciativas para confirmar que Estados Unidos e Israel fueron los responsables de los ataques contra Irán. Las fuentes no han sido identificadas por cuestiones de seguridad.
Según dichas fuentes, Barak Obama, después de suceder a George Bush, se encontró con un programa denominado 'Olympic Games', enfocado al desarrollo de ciberarmas. Obama decidió aumentar los recursos a este plan y autorizó de forma directa que se realizasen ataques contra los sistemas iraníes.
Entre Estados Unidos e Israel desarrollaron distintas ciberarmas, entre las que destacó Stuxnet. Este gusano consiguió causar daños en los sistemas nucleares de Irán, objetivo principal de la ofensiva. USA e Israel perseguían frenar lo máximo posible la campaña de desarrollo nuclear de Irán, al mismo tiempo que pensaban debilitar al país ante un posible ataque contra la propia Israel.
Tras realizar los ataques con Stuxnet, virus que se asegura que tiene un código 50 veces más complejo que un malware normal, los analistas aseguraron que se había conseguido retrasar en aproximadamente 18 meses el desarrollo nuclear de Irán. Por su parte, Irán aseguró que había conseguido controlar Stuxnet y que el virus no había afectado a sus sistemas.
Las fuentes de The New York Times confirman así que USA, que ya había anunciado el desarrollo de ciberarmas, habría realizado su primer ataque en la Red. Pese a que el proyecto lo inició George Bush, Obama sería el responsable de haber coordinado las acciones y haber dado las órdenes directas para su aplicación.
Utilizando un Kernel RT (de baja latencia)
Los kernels RT permiten un óptimo rendimiento en algunas situaciones partículares, por ejemplo, la edición de audio o la utilización de instrumentos musicales virtuales.
Kernel multitarea
El kernel de Linux, como el de la mayoría de los sistemas operativos modernos, es multitarea. Eso quiere decir que se están ejecutando varios programas al mismo tiempo.
En realidad esto no ocurre exactamente así. Lo que se hace es poner los programas en una cola y, uno por uno, el microprocesador los ejecuta durante una cierta cantidad de tiempo. Una vez agotado éste el microprocesador interrumpe la tarea dejándola a medias y da paso a la siguiente. A esta cantidad de tiempo se le denomina quantum o time slice, y no tiene por qué ser constante.
Una buena analogía podría ser el cocinero de un bar preparando varios platos a la vez: un bocata de lomo, una de callos, una ensalada mixta... Ahora parto el pan, enciendo la sartén, mientras se calienta lavo la lechuga, etc.
Si el quantum es suficientemente pequeño la impresión subjetiva para un observador lento, como el ser humano, es de que en vez de un procesador rápido ejecutando tareas alternativamente tenemos un procesador lento para cada una ellas (varios cocineros en la misma cocina haciendo lentamente cada uno un solo plato).
La conmutación de tareas tiene un costo
La multitarea no es gratis: implica una sobrecarga del procesador. En efecto, desalojar una tarea y cargar la siguiente es un trabajo extra. Esta operación se denomina 'cambio de contexto' o 'conmutación de tareas'. Sería más rentable en términos de CPU ejecutar los programas por completo, uno por uno, que partirlos en 'rodajas' e ir saltando de uno a otro. Sin embargo, el sistema perdería en interactividad, no podríamos tener varias ventanas abiertas o, en el caso de un servidor, atender a varias peticiones simultáneamente.
Latencia y rendimiento
Supongamos que nuestro cocinero tiene que pelar 20 kilos de gambas y deshuesar 20 kilos de aceitunas. ¿Cómo se planifica el trabajo?
En un caso extremo primero pelaría todas las gambas, se lavaría las manos para no mezclar sabores y después deshuesaría todas las aceitunas. Lo representaremos así:
GGGGGGGGGGGGGGGGGGGGGG... C AAAAAAAAAAAAAAAAAAAAAA...
En el extremo opuesto, pelaría una gamba, se lavaría las manos, deshuesaría una aceituna, se lavaría las manos... gamba, aceituna, gamba, aceituna... Lo representaremos así:
GCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCAC...
La 'C' representa el cambio de contexto: lavarse las manos, cambiar de utensilio...
Al mismo tiempo, un camarero recoge las peticiones de los clientes: "¡una de gambas!"... "¡una de aceitunas!"... y las translada a la cocina.
En el primer caso, supongamos que entra un cliente y pide una ración de gambas. No hay problema, enseguida se le sirve. Pero, ¿y si pide aceitunas? El camarero no podría servirla hasta que todas las gambas estuvieran peladas. En este caso la latencia, que es el tiempo que pasa desde que se hace una petición hasta que ésta es atendida, sería muy alta.
En el segundo caso, pida lo que pida el cliente, estará disponible en poco tiempo, además prácticamente igual en ambos casos. La latencia será baja, pero a un coste: debido a los cambios de contexto se producirá una disminución del rendimiento, entendido como la parte del tiempo durante el cuál la CPU está haciendo tareas directamente productivas, en lugar de labores de soporte.
Evidentemente en este caso la solución ideal sería un término medio, que dependería del tamaño de las raciones y de la distribución estadística de las peticiones. La teoría de colas es la rama de la matemática que se encarga de estudiar estas situaciones y de darles soluciones óptimas.
Como se puede ver, latencia y rendimiento son opuestos. Por esta razón no es correcto afirmar que los kernels rt dan más rendimiento. Todo lo contrario, al bajar la latencia empeoran el rendimiento de la máquina y, por lo tanto, son una elección pésima para sistemas que no necesiten respuestas superrápidas como, por ejemplo, servidores web o de bases de datos.
Por el contrario, los kernels de baja latencia son ideales en situaciones donde se necesite la máxima velocidad de respuesta a los estímulos externos, como sistemas de control industrial o aplicaciones multimedia interactivas, sabiendo que estamos sacrificando parte de la potencia de la máquina en garantizar esa rápida reacción.
Prioridades
Una opción interesante en sistemas multitarea es dar distintas prioridades a las tareas, de tal forma que las más importantes reciban más tiempo del procesador y las menos importantes menos. En un kernel normal esto se hace con el comando 'nice'. Si nuestro cocinero espera servir más raciones de gambas que de aceitunas haría bien en dedicarle más tiempo a las primeras, lógicamente.
Kernel RT (o de baja latencia)
El problema de los kernel normales es que las tareas no se pueden interrumpir en cualquier sitio, hay que esperar a que lleguen a ciertos puntos de ejecución donde ya se pueden detener para conmutar a otra. Esto introduce lo que llamamos latencia.
Por ponerlo de una forma simplificada, los kernels RT permiten interrumpir las tareas en más cantidad de sitios que los kernel normales. Pueden hacer, por así decirlo, rodajas más finas de tiempo, así que la tarea actual será desalojada más rápidamente y nuestra tarea prioritaria podrá acceder antes a la CPU. Por lo tanto la latencia será más baja.
Digamos que un kernel RT nos permite dejar una gamba a medio pelar si lo que se necesita en ese momento, urgentemente, es ponerse a deshuesar una aceituna lo antes posible, mientras que en un kernel normal habría que terminar de pelar la gamba.
Además de hacer rodajas más finas, los kernels RT tienen un sistema de prioridades mucho más estricto, donde las tareas prioritarias pegan hachazos inmisericordes a las demás (preempting) para hacerse con el control de la CPU, ralentizando los demás programas lo que sea necesario para cumplir con sus requisitos.
¿Cuándo es importante usar un Kernel RT?
En dos casos:
1) Cuando necesitamos latencias muy bajas, es decir, reacciones muy rápidas de la máquina. El ejemplo más claro es la ejecución de instrumentos virtuales, donde necesitas que al pulsar una tecla de un teclado MIDI el instrumento suene inmediatamente.
2) Cuando necesitamos prioridades muy estrictas, es decir, que nuestra tarea de alta prioridad no se interrumpa por nada del mundo (a no ser en el caso catastrófico de que la CPU esté tan sobrecargada que se supere el 100% de utilización). Por ejemplo, estamos grabando una sesión de audio con Ardour y observando cómo suben y bajan los indicadores de los faders. No importa si perdemos algún cuadro de refresco de los faders con tal de que el transporte de sonido del micrófono al disco duro no se vea interrumpido. Un kernel RT ralentizará el refresco de los faders todo lo que sea necesario con tal de que no se pierda ni una muestra de audio.
Dicho esto, en general los kernels no RT más recientes han mejorado mucho su sistema de planificación de tareas y su gestión de prioridades. Si no tienes la CPU al límite de sus posibilidades (digamos por debajo del 50% de utilización) o si no te importa que de vez en cuando se produzca un pequeño microcorte (clic) en el sonido (los tan temidos xruns), un kernel normal da unas prestaciones perfectamente aceptables.
¿Qué latencia es aconsejable?
A mí personalmente cualquier cosa por debajo de 10 ms ya me va bien y a partir de 20 ms ya empiezo a notar el retardo claramente. Hay gente más exigente.
Instalación
En Ubuntu y derivados:
sudo apt-get install linux-headers-lowlatency
sudo apt-get install linux-lowlatency
sudo update-grub
Al arrancar se podrá disponer de las dos opciones (el kernel normal y el de baja latencia).
En Arch y derivados:
yaourt -S linux-rt
sudo update-grub
Fuente: http://www.taringa.net/posts/linux/14764674/Utilizando-un-kernel-RT-_de-baja-latencia_.html
Kernel multitarea
El kernel de Linux, como el de la mayoría de los sistemas operativos modernos, es multitarea. Eso quiere decir que se están ejecutando varios programas al mismo tiempo.
En realidad esto no ocurre exactamente así. Lo que se hace es poner los programas en una cola y, uno por uno, el microprocesador los ejecuta durante una cierta cantidad de tiempo. Una vez agotado éste el microprocesador interrumpe la tarea dejándola a medias y da paso a la siguiente. A esta cantidad de tiempo se le denomina quantum o time slice, y no tiene por qué ser constante.
Una buena analogía podría ser el cocinero de un bar preparando varios platos a la vez: un bocata de lomo, una de callos, una ensalada mixta... Ahora parto el pan, enciendo la sartén, mientras se calienta lavo la lechuga, etc.
Si el quantum es suficientemente pequeño la impresión subjetiva para un observador lento, como el ser humano, es de que en vez de un procesador rápido ejecutando tareas alternativamente tenemos un procesador lento para cada una ellas (varios cocineros en la misma cocina haciendo lentamente cada uno un solo plato).
La conmutación de tareas tiene un costo
La multitarea no es gratis: implica una sobrecarga del procesador. En efecto, desalojar una tarea y cargar la siguiente es un trabajo extra. Esta operación se denomina 'cambio de contexto' o 'conmutación de tareas'. Sería más rentable en términos de CPU ejecutar los programas por completo, uno por uno, que partirlos en 'rodajas' e ir saltando de uno a otro. Sin embargo, el sistema perdería en interactividad, no podríamos tener varias ventanas abiertas o, en el caso de un servidor, atender a varias peticiones simultáneamente.
Latencia y rendimiento
Supongamos que nuestro cocinero tiene que pelar 20 kilos de gambas y deshuesar 20 kilos de aceitunas. ¿Cómo se planifica el trabajo?
En un caso extremo primero pelaría todas las gambas, se lavaría las manos para no mezclar sabores y después deshuesaría todas las aceitunas. Lo representaremos así:
GGGGGGGGGGGGGGGGGGGGGG... C AAAAAAAAAAAAAAAAAAAAAA...
En el extremo opuesto, pelaría una gamba, se lavaría las manos, deshuesaría una aceituna, se lavaría las manos... gamba, aceituna, gamba, aceituna... Lo representaremos así:
GCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCACGCAC...
La 'C' representa el cambio de contexto: lavarse las manos, cambiar de utensilio...
Al mismo tiempo, un camarero recoge las peticiones de los clientes: "¡una de gambas!"... "¡una de aceitunas!"... y las translada a la cocina.
En el primer caso, supongamos que entra un cliente y pide una ración de gambas. No hay problema, enseguida se le sirve. Pero, ¿y si pide aceitunas? El camarero no podría servirla hasta que todas las gambas estuvieran peladas. En este caso la latencia, que es el tiempo que pasa desde que se hace una petición hasta que ésta es atendida, sería muy alta.
En el segundo caso, pida lo que pida el cliente, estará disponible en poco tiempo, además prácticamente igual en ambos casos. La latencia será baja, pero a un coste: debido a los cambios de contexto se producirá una disminución del rendimiento, entendido como la parte del tiempo durante el cuál la CPU está haciendo tareas directamente productivas, en lugar de labores de soporte.
Evidentemente en este caso la solución ideal sería un término medio, que dependería del tamaño de las raciones y de la distribución estadística de las peticiones. La teoría de colas es la rama de la matemática que se encarga de estudiar estas situaciones y de darles soluciones óptimas.
Como se puede ver, latencia y rendimiento son opuestos. Por esta razón no es correcto afirmar que los kernels rt dan más rendimiento. Todo lo contrario, al bajar la latencia empeoran el rendimiento de la máquina y, por lo tanto, son una elección pésima para sistemas que no necesiten respuestas superrápidas como, por ejemplo, servidores web o de bases de datos.
Por el contrario, los kernels de baja latencia son ideales en situaciones donde se necesite la máxima velocidad de respuesta a los estímulos externos, como sistemas de control industrial o aplicaciones multimedia interactivas, sabiendo que estamos sacrificando parte de la potencia de la máquina en garantizar esa rápida reacción.
Prioridades
Una opción interesante en sistemas multitarea es dar distintas prioridades a las tareas, de tal forma que las más importantes reciban más tiempo del procesador y las menos importantes menos. En un kernel normal esto se hace con el comando 'nice'. Si nuestro cocinero espera servir más raciones de gambas que de aceitunas haría bien en dedicarle más tiempo a las primeras, lógicamente.
Kernel RT (o de baja latencia)
El problema de los kernel normales es que las tareas no se pueden interrumpir en cualquier sitio, hay que esperar a que lleguen a ciertos puntos de ejecución donde ya se pueden detener para conmutar a otra. Esto introduce lo que llamamos latencia.
Por ponerlo de una forma simplificada, los kernels RT permiten interrumpir las tareas en más cantidad de sitios que los kernel normales. Pueden hacer, por así decirlo, rodajas más finas de tiempo, así que la tarea actual será desalojada más rápidamente y nuestra tarea prioritaria podrá acceder antes a la CPU. Por lo tanto la latencia será más baja.
Digamos que un kernel RT nos permite dejar una gamba a medio pelar si lo que se necesita en ese momento, urgentemente, es ponerse a deshuesar una aceituna lo antes posible, mientras que en un kernel normal habría que terminar de pelar la gamba.
Además de hacer rodajas más finas, los kernels RT tienen un sistema de prioridades mucho más estricto, donde las tareas prioritarias pegan hachazos inmisericordes a las demás (preempting) para hacerse con el control de la CPU, ralentizando los demás programas lo que sea necesario para cumplir con sus requisitos.
¿Cuándo es importante usar un Kernel RT?
En dos casos:
1) Cuando necesitamos latencias muy bajas, es decir, reacciones muy rápidas de la máquina. El ejemplo más claro es la ejecución de instrumentos virtuales, donde necesitas que al pulsar una tecla de un teclado MIDI el instrumento suene inmediatamente.
2) Cuando necesitamos prioridades muy estrictas, es decir, que nuestra tarea de alta prioridad no se interrumpa por nada del mundo (a no ser en el caso catastrófico de que la CPU esté tan sobrecargada que se supere el 100% de utilización). Por ejemplo, estamos grabando una sesión de audio con Ardour y observando cómo suben y bajan los indicadores de los faders. No importa si perdemos algún cuadro de refresco de los faders con tal de que el transporte de sonido del micrófono al disco duro no se vea interrumpido. Un kernel RT ralentizará el refresco de los faders todo lo que sea necesario con tal de que no se pierda ni una muestra de audio.
Dicho esto, en general los kernels no RT más recientes han mejorado mucho su sistema de planificación de tareas y su gestión de prioridades. Si no tienes la CPU al límite de sus posibilidades (digamos por debajo del 50% de utilización) o si no te importa que de vez en cuando se produzca un pequeño microcorte (clic) en el sonido (los tan temidos xruns), un kernel normal da unas prestaciones perfectamente aceptables.
¿Qué latencia es aconsejable?
A mí personalmente cualquier cosa por debajo de 10 ms ya me va bien y a partir de 20 ms ya empiezo a notar el retardo claramente. Hay gente más exigente.
Instalación
En Ubuntu y derivados:
sudo apt-get install linux-headers-lowlatency
sudo apt-get install linux-lowlatency
sudo update-grub
Al arrancar se podrá disponer de las dos opciones (el kernel normal y el de baja latencia).
En Arch y derivados:
yaourt -S linux-rt
sudo update-grub
Fuente: http://www.taringa.net/posts/linux/14764674/Utilizando-un-kernel-RT-_de-baja-latencia_.html
Suite Libre Office 3.5.3 final en Español
El equipo de trabajo de The Document Foundation acaba de liberar la úlltima actualización de este conjunto de herramientas de productividad alternativa a Office y LibreOffice.
Esta versión además de contener las oportunas correciones de bugs de la versión anterior aporta pequeñas mejoras en rendimiento sin que se incluyan cambios importantes en su funcionalidad (ver notas de lanzamiento de esta última versión).

LibreOffice 3.5.3 Final es una versión recomendada para usuarios finales y empresas que busquen un software de productividad de software libre y con la necesaria estabilidad.
Con soporte para usuarios Windows, Mac y Linux, LibreOffice incluye hasta seis herramientas como Writer, Calc, Impress, Draw, Math y Base con las que cubrir nuestras necesidades a la hora de producir documentos y procesar datos.
Se recomienda a todos aquellos usuarios OpenOffice que quieran dar el salto al nuevo LibreOffice 3.5.3 Final, lo desinstalen primero para evitar posibles conflictos y fallos del programa.
Interesados en acceder a la descarga del nuevo LibreOffice 3.5.3 Final en español pueden acceder a
http://es.libreoffice.org/descarga/
¿Que es Libre Office?
LibreOffice es una suite ofimática libre y gratuita, compatible con Microsoft Windows, Mac y GNU/Linux. Cuenta con un procesador de texto (Writer), un editor de hojas de cálculo (Calc), un creador de presentaciones (Impress), un gestor de bases de datos (Base), un editor de gráficos vectoriales (Draw), y un editor de fórmulas matemáticas (Math).
Mas Info en WikiPedia: http://es.wikipedia.org/wiki/LibreOffice
Creador de Linux gana el llamado "Nobel" de tecnología
Linus Torvalds es el creador del sistema operativo de código abierto, que utilizan unos 30 millones de dispositivos.
El creador del sistema operativo Linux, Linus Torvalds, recibió hoy el Premio Millennium de Tecnología 2012, que la Academia de Tecnología de Finlandia entrega cada dos años y que es considerado como el "Nobel" de esta área.
Torvalds es el creador del sistema operativo de código abierto Linux, que utilizan actualmente unos 30 millones de personas en computadores, teléfonos móviles o cámaras de video.
"Linus Torvalds encarna el espíritu de innovación y de colaboración que este premio representa, y lo felicitamos por este gran honor", dijo Jim Zemlin, director ejecutivo de la Fundación Linux.
Torvalds, informático de 42 años, creó Linux en 1991 cuando era estudiante de la Universidad de Helsinki y lo desarrolló con los aportes de miles de internautas voluntarios, hasta convertirse en el exponente más conocido de software libre.
"El software es demasiado importante en el mundo moderno como para que no sea desarrollado a través de fuentes abiertas", declaró Torvalds cuando conoció su nominación al Millennium.
El premio se concede para destacar las innovaciones para mejorar la calidad de la vida humana y fomentar el desarrollo sostenible. La entrega del galardón se realizará el próximo 13 de junio.
El creador del sistema operativo Linux, Linus Torvalds, recibió hoy el Premio Millennium de Tecnología 2012, que la Academia de Tecnología de Finlandia entrega cada dos años y que es considerado como el "Nobel" de esta área.
Torvalds es el creador del sistema operativo de código abierto Linux, que utilizan actualmente unos 30 millones de personas en computadores, teléfonos móviles o cámaras de video.
"Linus Torvalds encarna el espíritu de innovación y de colaboración que este premio representa, y lo felicitamos por este gran honor", dijo Jim Zemlin, director ejecutivo de la Fundación Linux.
Torvalds, informático de 42 años, creó Linux en 1991 cuando era estudiante de la Universidad de Helsinki y lo desarrolló con los aportes de miles de internautas voluntarios, hasta convertirse en el exponente más conocido de software libre.
"El software es demasiado importante en el mundo moderno como para que no sea desarrollado a través de fuentes abiertas", declaró Torvalds cuando conoció su nominación al Millennium.
El premio se concede para destacar las innovaciones para mejorar la calidad de la vida humana y fomentar el desarrollo sostenible. La entrega del galardón se realizará el próximo 13 de junio.
Suscribirse a:
Entradas (Atom)