lunes, 31 de marzo de 2014

El software libre permitió que el internet sea gratuito

La idea original de internet se describió hace 25 años, cuando el WWW se gestaba en el CERN en Europa. Sin embargo, el origen de la red tiene muchos más antecedentes como aquel que permitió su gratuidad, producto del concepto de software libre.


De acuerdo con Gloria Koenigsberger, investigadora del Instituto de Astronomía de la UNAM y pionera de la implementación de internet en México, este hecho se basó en el proyecto que desarrollaba EU a través de su National Science Foundation (NSF) y la Advanced Research Projects Agency NETwork (Arpanet) mediante el desarrollo de un solo protocolo para la red.

“Entre 1980 y 1985 Stephen Wolff —directivo de la NSF— dijo que utilizarían un protocolo TCP/IP, el cual sería gratuito”, refirió la astrónoma durante su participación en el simposio “Importancia de la computación para el desarrollo de la ciencia”, realizado ayer en El Colegio Nacional.

Los protocolos en la red permiten la trasmisión de datos entre computadoras, y el Protocolo de Control de Transmisión (TCP) y el Protocolo de Internet fueron los primeros en definirse, en gran parte por la medida de la NSF. Ambos fueron desarrollados por Arpanet a principios de los años setentas y ésta migró a los protocolos en su totalidad en 1983.

La NSF entonces comisionó la distribución en todos los sistemas y obligó a empresas a que instalarán estos protocolos para que se hicieran compatibles sus computadoras con la red, refirió la astrónoma. “Cada marca tenían diferentes sistemas operativos y no se podían comunicar unas computadoras con otras. Por ello, el TCP/IP fue clave de lo que hoy es internet, un software libre”.

No obstante, para entonces no se sabía el impacto que esto tendría, relató, un ejemplo de ello es que la NSF contactó a AT&T para que operara la red pero ésta no veía mucha utilidad en el proyecto. “En la mentalidad de aquella época no se predecía (en ninguna parte del mundo) lo que realmente sucedió: que hoy pueda revisar mi correo desde mi teléfono”.

CIENCIAS DEL CÓMPUTO.


A lo largo del simposio, presentado por los miembros de El Colegio Nacional Samuel Gitler (Cinvestav), Luis Felipe Rodríguez (UNAM) y Eusebio Juaristi (Cinvestav), académicos de estas instituciones, así como del IPN e instituciones de EU y España, se bosquejó desde la historia de la computación hasta las aplicaciones más novedosas a las que ha llegado esta ciencia menor de 70 años.

Carlos Coello, investigador del Cinvestav y Premio Nacional de Ciencias y Artes expuso una breve historia de la computación, hasta dar un panorama sobre el estado actual y llegar a lo que podríamos esperar en el futuro.

“Hoy tenemos software y hardware más poderosos, en una laptop o computadora de escritorio tenemos más poder que las estaciones de trabajo de hace 10 o 15 años; tenemos mejores unidades de procesamiento de video y los clusters de computadoras son más accesibles. Ha habido un gran crecimiento que nos ha llevado a una nueva era”.

Hacia dónde vamos en el futuro, se preguntó el investigador del Departamento de Computación del Cinvestav. “No soy muy bueno prediciendo el futuro pero analistas señalan que dispositivos como las computadoras corporales serán más comunes, las cuales podrán detectar problemas de salud y dar aviso a los hospitales”.

También se prevé la convergencia hacia un dispositivo único, añadió, que reunirán las características y aplicaciones de las computadoras en sistemas que estarán entre el celular y la tablet, dijo.

Por otra parte, puntualizó que en el tema del cómputo cuántico él tiene sus reservas: lo que promete es mucho, pero tecnológicamente aún estamos lejos de desarrollarlo, principalmente por la capacidad de procesamiento. “Algunos ven que hacia allá van las tendencias de la computación, pero yo no estoy convencido y soy más bien un escéptico, aunque tampoco soy experto en el tema”.

Otro de los participantes fue Adolfo Guzmán Arenas, investigador del Centro de Investigación en Computación del IPN, artífice de la computación en el país, quien refirió cómo casi todas las áreas del conocimiento y de la vida común están asociadas con sistemas computacionales y sin los cuales no sería posible hacer astronomía moderna o detectar bosones de Higgs.

Acotó que la ingeniería en computación es la más popular entre las ingenierías entre los jóvenes mexicanos, puesto que egresa 25 mil al año, en tanto que EU hace lo propio con 50 mil e india 100 mil. “Esta no es una ciencia difícil, como todo tiene su chiste y no es nada fuera de este mundo. Eso sí, hay que estar afilando el machete de ese conocimiento continuamente”, cada lustro, aproximadamente, agregó. Las aplicaciones van y vienen, “lo de hoy son las que se necesitan para los celulares”, ejemplificó.

viernes, 28 de marzo de 2014

¿Qué es lo que un usuario de Windows debería saber de GNU/Linux?

Muchos de los que usamos GNU/Linux andamos por ahí evangelizando nuestro Sistema Operativo y por lo general siempre hablamos de lo mismo: Que si los virus, que si es gratis, que si es abierto… etc


¿Esto es solamente lo que realmente debería conocer un usuario de Windows o de cualquier otro SO? En parte si, pero no lo es todo. Veamos algunas cosas que considero, deberían aprender todo el usuario que llegan nuevo a GNU/Linux.

¿Qué es GNU/Linux?

Pero ojo, muchas veces decimos: “Yo uso Linux”, cuando en realidad debería ser:“Yo uso GNU/Linux”. Cuando usamos cualquier distribución, estamos usando el Kernel (Linux)y muchas otras aplicaciones del proyecto GNU. Nadie usa solamente Linux (el Kernel).
Hay para todos los gustos

Distribuciones de GNU/Linux hay para todos los gustos y de todos los sabores. Podemos encontrar desde las más fáciles en cuanto a instalación y configuración (Ubuntu, LinuxMint, openSUSE, Debian) algunas más complejas (Archlinux, Chakra, Slitaz) hasta las más complicadas(Gentoo, Slackware).

También tenemos muchísimas opciones en dependencia del Hardware con el que contamos. Existen distribuciones muy ligeras que pueden variar según el Entorno de Escritorio que usemos.
Sistema de Ficheros y Particiones

Creo que el punto más crítico a la hora de usar GNU/Linux es a la hora de instalar y particionar los discos, y conocer como está estructurado el Sistema de ficheros. Pero podríamos resumir que un usuario de Windows debe conocer que “por lo general” en GNU/Linux se usan 3 particiones:

- La primera partición para la raíz ( / ) que equivale al disco C:
- La segunda partición para el home ( /home ) que equivale al disco D:
- La tercera partición para la Swap que equivale a la memoria virtual.

También debe conocer que para estas particiones no se usa NTFS o Fat32 (aunque se puede acceder a particiones de este tipo). Nosotros usamos “generalmente”: Ext2, Ext3 y Ext4, y es válido aclarar que no son las únicas opciones que tenemos.
¿Terminal? Que horror!!!

A pesar de que muchos usuarios le temen al terminal, todos sabemos que no muerde, al contrario, muchas veces nos facilita la vida. No se concibe una distribución de GNU/Linux sin un Emulador del Terminal. Una vez que se aprende a usarla, no podemos estar sin ella.

Todo lo que podemos hacer en el terminal “generalmente” se puede hacer con aplicaciones gráficas o viceversa y es de vital importancia hacer uso de ella para depurar errores u obtener información del Sistema. Cuando un programa no quiere iniciar, una buena práctica es ejecutarlo o llamarlo desde un terminal para ver el error que nos devuelve.
Logs ¿Qué son? ¿Para que me sirven?

Una de las diferencias entre GNU/Linux y Windows, que siempre nosotros enumeramos, es que tenemos control sobre nuestro Sistema Operativo. ¿A qué yo le llamo control? Pues simplemente que podemos saber que está haciendo nuestro sistema en diferentes ocasiones, o mejor, que en caso de algún error podemos ver cual es la causa. ¿Cómo? Pues con los Logs del Sistema.

Créanme, cuando aprendí que eran los logs, se resolvieron un 90% de mis problemas. Los logs son, digamos, una especie de registro o historial que nos muestra que está sucediendo con determinadas aplicaciones o el sistema en si.

El simple hecho de conectar un cable de red o desconectarlo por ejemplo, se registra en un log. El arranque de nuestro Sistema Operativo se registra en un log, y muchísimas aplicaciones registran sus acciones en logs. Estos ficheros “generalmente” se almacenan en el directorio /var/log y ahí podemos consultarlos si tenemos algún problema.
Más de un Entorno de Escritorio

A diferencia de Windows, en GNU/Linux podemos usar más de un Entorno de Escritorio, incluso, tenerlos instalado sin que uno afecte al otro. Pero es bueno aclarar que no necesitamos un Escritorio para poder trabajar con GNU/Linux.

El Entorno de Escritorio nada tiene que ver con el correcto funcionamiento del Sistema Operativo. Simplemente es una forma “gráfica” de gestionarlo, por decirlo de alguna forma. Ahora, para tener un Entorno de Escritorio es necesario tener instalado un Servidor Gráfico, el cual generalmente es Xorg.

Para que los nuevos usuarios entiendan un poco esto veamos el siguiente gráfico:



Siguiendo el orden mostrado en el gráfico:
Arranca el Kernel, el cual es el encargado de gestionar entre otras cosas, el Hardware disponible y los periféricos (Mouse, Teclado…etc). Esto conlleva librerías y demás.
Luego arrancan los Servicios (Ej: Servidor de base de datos, demonios de aplicaciones y demás).
Posteriormente arranca el Servidor Gráfico. Sin este servidor no podremos ver en el monitor ni ventanas, ni menús.. etc.
Por último arranca el Gestor de Sesión (opcional si usamos startx) que nos llevará al Entorno Gráfico que tengamos instalado cuando pongamos usuario y contraseña.

El Sistema Operativo y el Entorno de Escritorio, aunque se relacionan, son cosas apartes. Es por eso que si ocurre un error con el Entorno de Escritorio, normalmente este no afecta alKernel y con solo reiniciar el Servidor Gráfico (en algunos casos) podemos solucionarlo.
Repositorios y dependencias: Mira mamá no tengo .EXE

En GNU/Linux es muy común hacer uso de repositorios de paquetes -que no es más que gigas de software organizados, estructurados y reunidos en un servidor- para instalar nuestras aplicaciones ¿Qué es lo chocante de este método para los nuevos usuarios? Que los usuarios de Windows están adaptados a instalar de binarios (.exe) y este tiene “generalmente”, todo lo necesario para que software funcione.

En el caso de GNU/Linux hay paquetes que si, se pueden instalar solitos y no pasa nada, pero por lo general, la mayoría necesita de otros paquetes (librerías y cosas así) que pasan a ser sus dependencias. Es por ello que si alguien quiere por ejemplo, LibreOffice para Windows, solo tiene que bajar un .exe y listo, pero si lo quiere para Debian, tendría que bajar un tarballcargado de .deb, o bajar cada paquete del repositorio con sus dependencias. No es que esto sea complicado ni mucho menos, pero digamos que es un poco más engorroso.

En GNU/Linux tenemos binarios similares al .exe, incluso, aplicaciones que permiten instalar dichos binarios con un simple doble clic. Acá les muestro varios ejemplos de como podríamos encontrar estos binarios:
bluefish.deb – Para distribuciones basadas en Debian (Ubuntu, LinuxMint, Dreamlinux…etc)
bluefish.rpm – Para distribuciones basada en RedHat o en su sistema de paquetes (Fedora, openSUSE…etc)
bluefish.pkg.tar.xz – Para distribuciones basadas en Archlinux (Chakra, ArchBang… etc)
bluefish.tar.gz o bluefish.tar.bz2 – Por lo general sirve en cualquier distribución ya que debemos compilarlo.

¿Donde están mis configuraciones?

Cuando configuramos el cliente de correo o el navegador, todas esas configuraciones del usuario se guardan en nuestro /home (equivalente al disco D:) o como lo llamamos algunos, nuestra Carpeta Personal. Al contrario de lo que sucede en Windows que este tipo de cosas se guardan en el Disco C: (Documents and Settings..).

Las configuraciones se guardan en carpetas ocultas dentro de nuestro /home que por lo general llevan el nombre de la aplicación. Por ejemplo, las configuraciones de Thunderbird, los correos recibidos, listas de contactos y demás, se guardan en /home/usuario/.thunderbird.

Esto trae muchísimas ventajas, ya que si necesitamos reinstalar nuestro SO, solo tenemos que formatear la partición de la raíz, dejando el /home intacto, y cuando terminemos tendremos nuestras preferencias, intactas. Esto lo explico con más detalles en este artículo.
¿Puedo hacer lo mismo que en Windows?

La respuesta es SI e incluso, mucho más. Podemos realizar las mismas tareas que estamos acostumbrados a hacer normalmente: Navegar, Chatear, Redactar un documento, Jugar, Escuchar música, Ver un video, Editar imágenes, Trabajar con nuestro ordenador.

Son los mismos atajos de teclado para la mayoría de las cosas: [Ctrl] + [C] para copiar, [Ctrl] + [V] para pegar…etc. Todo en GNU/Linux es muy personalizable, desde los atajos de teclado hasta la apariencia del escritorio.

Tú no eres el Administrador (Si no quieres.)

Eso de trabajar con la cuenta de Administrador a lo Windows XP: olvídalo!!! No es que no se pueda, sino que por defecto no es así. Los usuarios tienen sus cuentas con limitaciones para tareas de Administración (según la distro porque Ubuntu…. bueno..) y por lo general, para afectar algo del sistema necesitas credenciales con permisos administrativos.
Compártelo, regálalo.

Olviden los malvados EULAs. Puedes coger tu iso de Ubuntu o cualquier otra distro y prestarla, regalarla, o instalar en todas las máquinas que quieras la misma copia. O si quieres no instales, solo tienes que cargar con un LiveCD o una Memoria Flash.
Instala y verás que todo funciona.

Por lo general, puedes olvidarte del disco de drivers para tu motherboard o cualquier otro hardware. Es instalar y empezar a usar. GNU/Linux gestiona de forma asombrosa el hardware de tu PC (a no ser que suceda lo que viene en el siguiente punto).
Pero No todo lo que brilla es oro.

A pesar de que GNU/Linux tiene muchísimas cosas buenas, también tiene otras muy malas. No es culpa del Sistema como tal, en este aspecto entran a jugar muchos factores que podríamos resumir en los intereses marcados de algunas Compañías: Dinero, Monopolio y sus amiguitos. Es por ello que podremos encontrar en algunos casos, problemas con determinado Hardware o que no existan algunas aplicaciones muy usadas en el ámbito profesional o empresarial. Pero fuera de esto, siempre podremos encontrar alguna alternativa o solución a nuestros problemas.

La curva de aprendizaje tampoco es muy baja, pero sin duda no es para nada alta. Existe muchísima documentación, foros de ayuda, canales IRC, blogs, sitios y demás, repletos de usuarios dispuestos a ayudar.

Conclusiones.

Pienso que la mejor manera de conocer GNU/Linux es entrando en su mundo. Todas estas cosas que acabo decir, se aprenden con el paso del tiempo. Yo llevo más de 5 años usándolo y no me he muerto, al contrario, he aprendido y he crecido como informático. La clave está en no resistirse al cambio, a probar nuevas cosas y aprender de ellas.

miércoles, 26 de marzo de 2014

¿Por qué una página web no puede valer 500 €?

¿Tu página web fue diseñada y programada por un primo tuyo de Cuenca que es muy mañoso? ¿Tienes una página web porque todas las empresas tienen una? ¿La ejecutaste sin formular objetivos? ¿Sabes cuántas visitas recibes en tu sitio web y de dónde proceden? ¿Quieres abrir un perfil en Facebook o Twitter pero no has revisado tu página web en los últimos 5 años?


Si has respondido “Sí” a casi todas estas preguntas puede que tu página web no esté contribuyendo a la buena marcha de tu negocio.

Mantén la calma, no está todo perdido…. Infinidad de empresas que realizan competitive bidding para la ejecución de su página web escogen a su proveedor en función del precio. Vamos a ser valientes y vamos a gritarlo fuerte y alto: ¡el precio SÍ está ligado firmemente a la calidad y resultados de un sitio web!

Es nuestra intención mostraros las razones por las que una web de calidad no puede costar €500, a menos que tú mismo realices una serie de trabajos previos antes de que tu agencia comience con las tareas de diseño y programación. Para ello podemos destacar algunas pautas y recomendaciones.

Investiga las webs de la competencia

¡Es asombroso descubrir cuántas cosas puedes aprender navegando por las páginas de tus rivales!
En ellas encontrarás ideas brillantes, y otras muchas que te harán aliviar ese sentido de culpabilidad por tener tu web desactualizada, por su escasa usabilidad o calidad: noticias desactualizadas, programaciones en flash, diseños obsoletos…y otros muchos factores que te harán abrir bien los ojos para no repetir esos errores en tu propia site.

Estudia tu posicionamiento SEO

Existen numerosas fórmulas para saber si tu web está bien posicionada frente a la competencia, como el estudio de palabras clave en Google Adwords, o páginas de auditoría SEO, entre otras.

Fija objetivos

Coge papel y lápiz y piensa qué motivos te llevan a tener una página web: ¿quieres conseguir clientes? ¿Quieres conseguir notoriedad? ¿Quieres crear una comunidad? ¿Quieres vender?... Infinidad de objetivos distintos dan lugar al siguiente paso:

¿Cómo vas a conseguir cumplir tu objetivo? Traza estrategias

Una vez que tus objetivos han sido definidos, escribe paso por paso las medidas a tomar: contenidos a destacar, estructura web, cómo vas a dirigir al visitante a las secciones con más interés estratégico, etc.

Planteamiento de estructura y contenidos

Ya sabes qué quieres hacer y cómo lo vas a hacer, así que es hora de ponerse manos a la obra y definir la estructura más apropiada y alineada con tus objetivos.

Si tu presupuesto es ajustado no podrás contratar a un asesor lingüístico, así que dedica un tiempo generoso a escribir los textos, utiliza un buen lenguaje y revisa faltas de ortografía.

Por último recuerda que el diseño tiene que ir acorde con tu imagen de marca. ¡No inventes nuevos colores corporativos o logotipos, a no ser que quieras hacer un restyling!

Briefing a la agencia

Para que todo salga perfecto, debes dedicar un tiempo a escribir un resumen claro de todo lo anterior: análisis de la competencia, objetivos, estrategias, estructura planteada y contenidos e imágenes a incluir para posteriormente, ponerlas en común con diseñador y programador.

Cantidad, calidad y orden de la información del trabajo serán claves para que el proyecto sea ejecutado en condiciones óptimas de tiempo y siguiendo firmemente tus pautas marcadas.

Lanzamiento y control

Semanas de trabajo y esfuerzo no pueden tirarse por la borda. Por eso, una vez tu web sea colgada en el servidor debes llevar un control periódico de los resultados obtenidos.

¿Cuántas personas visitan tu web? ¿Proceden de buscadores o tráfico directo? ¿Cuál ha sido el recorrido que han realizado por el site? ¿Cuánto tiempo han permanecido? Debes manejar e interpretar estos datos para realizar acciones correctoras si fuera necesario.

Cuantifiquemos…

Ya sabemos qué debemos hacer para que nuestra página web sea efectiva y cumpla objetivos.
Por lo que nos vemos obligados a volver a la pregunta inicial…

¿Cuánto tiempo puede llevarte hacer las 7 tareas que hemos planteado, dos, tres, cuatro semanas? ¿Tienes conocimientos y experiencia en análisis, trazado de objetivos y estrategias?¿Cuánto vale tu tiempo? ¿Puedes desocuparte de tus obligaciones laborales para dedicar este tiempo de calidad a tu página web?

Si la respuesta es no, y has leído este artículo hasta el final, comprenderás que las agencias especializadas no pueden permitirse cobrar €500 por realizar una página web de calidad.

martes, 25 de marzo de 2014

Las Islas Canarias se cambian al software libre en sus bases de datos y adoptarán Open Office.

A través del Observatorio del Open Source de la Unión Europea nos enteramos que en las Islas Canarias siguen dando pequeños pasos en favor del Open Source: el cambio a PostgreSQL está decidido, mientras que lapropuesta de adoptar OpenOffice como suite ofimática está sobre la mesa.


El grupo de trabajo técnico de la Comisión Superior de Tecnología de la Información del Gobierno Canarias “ha decidido establecer herramientas de software libre (PostgreSQL) como gestores de las grandes bases de datos relacionales corporativas de la Administración y su utilización en las aplicaciones informáticas de la Comunidad Autónoma”.

Según informan en la página web del Gobierno Canarias, “el interés de las administraciones públicas por soluciones informáticas de Open Source, es una apuesta a medio plazo, que ya iniciamos en 2011 y que comienza a dar sus frutos tanto en la gestión presupuestaria como en la independencia tecnológica respecto de grandes fabricantes propietarios de licencias”.

Roberto Moreno, director general de Telecomunicaciones y Nuevas Tecnologías del Gobierno de Canarias, explica que “la política de uso y migración a software libre seguida por el Gobierno de Canarias ha estado en el punto de mira del Observatorio de Código Abierto y Reutilización Tecnológica de la UE en los últimos meses”. Asimismo, ha propuesto reemplazar las soluciones ofimáticas propietarias por OpenOffice 4.0.

martes, 18 de marzo de 2014

¿Qué hacer para que tu web salga en Google News?

En Internet siempre estamos deseando conseguir posicionar bien nuestras webs y nuestros contenidos, por ser este un aspecto fundamental para lograr un tráfico relevante y de importancia, que nos aporte un buen número de visitas de calidad.

Como cada vez es más importante posicionar nuestra web en Internet, hay una herramienta que nos puede ayudar y que muchos desconocen, aunque no todo el mundo puede aparecer en ella, como es Google News.


Para intentar aparecer en Google News, hay que seguir una serie de sencillos pasos y tras hacerlos y si cumplimos con los requisitos que nos pide el potente buscador, podemos hacer más accesible las informaciones de nuestras webs o blogs a los usuarios, gracias a aparecer nuestro contenido en las noticias de Google.

Para lograrlo, es un requisito fundamental que la web que queremos dar de alta en este servicio sea un sitio web de noticias con información relevante, es decir, que no sea una web solo de promoción o meramente publicitaria.

También es primordial que se actualice prácticamente a diario y que cumpla con unos mínimos requisitos de calidad.

"Los sitios incluidos en Google Noticias deben ofrecer puntualmente informes de noticias importantes o interesantes para nuestra audiencia. Por lo general no se incluyen artículos sobre cómo hacer cosas, columnas con consejos, ofertas de empleo o contenido estrictamente informativo como previsiones meteorológicas o datos de cotizaciones en bolsa."

La importancia del contenido original aquí tiene especial valor, ya que desde Google News se van a fijar principalmente en este aspecto de originalidad, aspecto que cada día se está valorando más por parte de los buscadores y de Google en particular.

Y es que se buscan contenidos en los que se acredite la originalidad de los artículos o noticias, que se refleje el autor original y se especifique a ser posible la información de los autores y sus datos de contacto (Twitter, Facebook, Linkedin, etc ) y otro factor muy importante para Google es el de la velocidad de carga de la página.

Este último punto es además de gran importancia para el posicionamiento en buscadores (SEO) de tu sitio web.

Aparte de estos requisitos en cuánto a contenido, también existen unos requisitos técnicos que pueden consultarse en la página de soporte de Google y entre los que se incluyen unos sitemaps específicos que deberemos generar.

Por último y si cumplimos con todos estos requisitos, nos quedaría tan sólo mandar nuestra petición a: enviar a Google la solicitud de inclusión de nuestro sitio en Google News.

El tiempo que suele tardar Google no es exacto, pero está generalmente entre una y dos semanas para sabar si podemos estar ya dentro de Google News.

Mozilla detiene el desarrollo de Firefox Metro para Windows

A través del blog oficial, la gente de Mozilla ha anunciado que han decidido detener el desarrollo de Firefox Metro para Windows 8 debido principalmente, a la baja adopción de dicha interfaz.

Según indica Johnathan Nightingale, vice-presidente de Mozilla Firefox, la adopción de la interfaz Metro es baja entre los mismos usuarios de Windows 8, este sería uno de los motivos por el cuál se decidió parar el desarrollo de Firefox para dicha interfaz.


Al respecto indicó:

“Desde hace meses, el equipo viene desarrollando, probando y refinando el producto, a su vez hemos estado viendo la adopción de la interfaz Metro. Desde donde pudimos observar, que es demasiado plano. En cualquier día que tenemos, por ejemplo, millones de personas prueban versiones de pre-lanzamiento de Firefox en el escritorio, pero nunca observamos que hallan más de 1000 usuarios usando el entorno gráfico Metro.”

“Esto nos deja con una decisión difícil, podemos continuar ofreciéndolo, pero eso también significa que no tendremos muchas pruebas reales a nivel mundial. Eso va a significar que habrán un montón de errores por descubrir, requerirá a varios de nuestros equipos de ingenieros, de diseñadores y de nuestro equipo de aseguramiento de calidad. Hacer un lanzamiento sin antes realizarle un seguimiento de trabajo no es una opción para nosotros. Si lanzamos un producto, lo mantenemos a través de todo su ciclo de vida, cuando hablo de la necesidad de escoger nuestras batallas, se trata de elegir la que requerirá una de alta investigación con bajo impacto.” agregó.


Finalmente también Nightingale ha indicado que el costo real en cuanto a impacto e investigación es demasiado grande para los pocos usuarios reales que usan la interfaz Metro de Windows 8, por lo que resaltó de que ellos prefieren centrarse en proyectos y productos que tienen un gran impacto o un gran número de usuarios como lo es por ejemplo, FirefoxOS.

miércoles, 12 de marzo de 2014

Valve libera su librería de conversión de DirectX a OpenGL y Crytek porta su CryEngine a GNU/Linux.

Parece que lo de que Linux se convierta en plataforma de juegos va muy en serio. Por un lado Valve publica su librería de conversión de DirectX a OpenGL hoy en GitHub bajo una licencia libre:

https://github.com/ValveSoftware/ToGL

Y, por otro, Crytek, los creadores de juegos como Crysis, Far Cry (I) y Warface, y reconocido por sus excelentes gráficos, ha portado su CryEngine a Linux:

http://www.crytek.com/news/conference-attendees-can-also-see-a-brand-new-mobile-game-extra-engine-updates-and-much-more-at-crytek-s-booth


Lo primero permitirá mejor portar juegos basados en DirectX a Linux, incluso mejorando el rendimiento del original (ya en su día Valve hizo pruebas y comprobó que podía ejecutar sus juegos a más fotogramas por segundo en Linux que en Windows). El código en sí se considera sólo apto para expertos y no es algo que se pueda compilar y utilizar independientemente. De hecho está extraído de un trabajo mayor (concretamente del código fuente del juego Dota2) y tendrá que ser adaptado e integrado según cada necesidad.

Lo segundo significa que Crytek ya tiene las miradas puesta en GNU/Linux como plataforma de sus juegos, posiblemente mirando de reojo las posibilidades que ofrecerá el SteamMachine de Valve. Que su CryEngine ya funcione en Linux implica que (a) Crytek ya está portando sus juegos para que se ejecuten nativamente y (b) que terceras empresas que utilicen el motor podrán desarrollar para más plataformas, incluyendo Linux, con mínimas dificultades.

lunes, 10 de marzo de 2014

Adiós privacidad: Fotos de Whatsapp aparecerán en Facebook

A pesar que el propio Mark Zuckerbergaseguró que no haría ningún cambio, los usuarios de Whatsapp tendrán que soportar que las fotos que compartan con sus contactos aparezcan publicadas también en sus perfiles de Facebook.


Recientemente Zuckerberg, dueño de Facebook, compraraWhatsapp, hizo el anuncio a través de la prestigiosa revista Time que todas las fotos que hayan subidas a través de esta aplicación tendrán como destino un álbum en su popular red social.

Dicha función correrá desde el próximo 1ro de abril, donde todas las fotos que los usuarios deWhatsappsuban irán a para inmediatamente a un álbum que no tendrá carácter de privado, lamentablemente.

Como era de esperarse, esta nueva disposición ha levantado mucha controversia porque todas las fotos y videos que sean enviadas durante las conversaciones irán directo a dicho álbum, con lo que todos los contactos (en Whatsapp y Facebook) podrán visualizarlo.

Es preciso destacar que muchos de los usuarios de Whatsapp compartían material visual a través de esta aplicación debido a la privacidad que permitía hacerlo solo con los destinatarios determinados, algo que no ocurrirá jamás.

martes, 4 de marzo de 2014

Virus en GNU/Linux: ¿Realidad o Mito?

El debate sobre Linux y los virus no es algo nuevo. Cada cierto tiempo vemos un correo en alguna lista preguntando si existen virus para Linux; y automáticamente alguien responde afirmativamente y alega que si no son más populares es porque Linux no está tan extendido como Windows. También son frecuentes las notas de prensa de desarrolladores de antivirus diciendo que sacan versiones contra los virus de Linux.

Personalmente he tenido alguna que otra discusión con distintas personas por correo, o por lista de distribución, respecto al tema de si existen o no los virus en Linux. se trata de un mito, pero es complejo derribar un mito o, mejor dicho, un bulo, especialmente si está causado por interés económico. A alguien le interesa transmitir la idea de que si Linux no tiene este tipo de problemas, es porque muy poca gente lo utiliza.

A la hora de publicar este reportaje me hubiese gustado elaborar un texto definitivo sobre la existencia de virus en Linux. Desgraciadamente, cuando la superstición y el interés económico campan a sus anchas, es difícil construir algo definitivo.
No obstante, intentaremos hacer aquí un argumentario razonablemente completo para desarmar los ataques de cualquiera que quiera discutirlo.

¿Qué es un Virus?

Lo primero, vamos a comenzar definiendo qué es un virus. se trata de un programa que se copia y se ejecuta automáticamente, y que tiene por objeto alterar el normal funcionamiento de un ordenador, sin el permiso o el conocimiento del usuario. Para ello, los virus reemplazan archivos ejecutables por otros infectados con su código. La definición es estándar, y es un resumen de una línea de la entrada sobre virus que aparece en la Wikipedia.
La parte más importante de esta definición, y la que diferencia el virus del resto del malware, es que un virus se instala solo, sin el permiso o conocimiento del usuario. si no se instala solo, no es un virus: podría ser un ser un rootkit, o un troyano.

Un rootkit es un parche al kernel que permite ocultar determinados procesos a las utilidades de área de usuario. Dicho de otra forma, es una modificación del código fuente del kernel que tiene como objeto que las utilidades que permiten ver qué se está ejecutando en cada momento no visualicen un determinado proceso, o un determinado usuario.

Un troyano es análogo: es una modificación al código fuente de un servicio concreto para ocultar determinada ac tividad fraudulenta. En ambos casos es necesario obtener el código fuente de la versión exacta instalada en la máquina Linux, parchear el código, recompilarlo, obtener privilegios de administrador, instalar el ejecutable parcheado, e inicializar el servicio –en el caso del troyano– o el sistema operativo completo –en el caso del
rootkit–. El proceso, como vemos, no es trivial, y nadie puede hacer todo esto “por error”. Tanto unos como otros exigen en su instalación que alguien con privilegios de administrador, de forma consciente, ejecute una serie de pasos tomando decisiones de índole técnica.

Lo cual no es un matiz semántico sin importancia: para que un virus se instale, basta con que ejecutemos un programa infectado como usuario común. Por otro lado, para la instalación de un rootkit o de un troyano es imprescindible que un humano malicioso entre personalmente en la cuenta de root de una máquina, y de forma no automatizada realice una serie de pasos que son potencialmente detectables. un virus se propaga con rapidez y eficiencia; un rootkit o un troyano necesitan que vayan específicamente a por nosotros.
La transmición de virus en Linux:

El mecanismo de transmisión de un virus, por lo tanto, es lo que realmente lo define como tal, y es la base de la existencia de los mismos. un sistema operativo es más sensible a los virus cuanto más fácil sea desarrollar un mecanismo eficiente y automatizado de transmisión de estos.

Supongamos que tenemos un virus que quiere transmitirse solo. Supongamosque ha sido lanzado por un usuario normal, de forma inocente, al lanzar un programa. Dicho virus tiene exclusivamente dos mecanismos de transmisión:

Replicarse tocando la memoria de otros procesos, anclándose a ellos en tiempo de ejecución.
Abriendo los ejecutables del sistema de ficheros, y añadiendo su código –payload– al ejecutable.

Todos los virus que podemos considerar como tales tienen al menos uno de estos dos mecanismos de transmisión. O los dos. No hay más mecanismos.
Respecto al primer mecanismo, recordemos la arquitectura de memoria virtual de Linux y cómo funcionan los procesadores intel. Estos poseen cuatro anillos, numerados de 0 a 3; a menor número, mayores los privilegios que tiene el código que se ejecute en dicho anillo. Estos anillos corresponden con estados del procesador, y, por lo tanto, con lo que se puede hacer con un sistema estando en un anillo concreto. Linux hace uso del anillo 0 para el kernel, y del anillo 3 para los procesos. no hay código de proceso que se ejecute en anillo 0, y no hay código de kernel que se ejecute en anillo 3. Solo hay un único punto de entrada al kernel desde el anillo 3: la interrupción 80h, que permite saltar del área donde está el código de usuario al área donde está el código de kernel.
La arquitectura de Unix en general y de Linux en particular no hace factible la dispersión de virus.

El kernel mediante el uso de la memoria virtual hace creer a cada proceso que tiene toda la memoria para él solo. Un proceso –que trabaja en anillo 3– solo puede ver la memoria virtual que le han configurado, por el anillo en el que opera. No es que la memoria de los otros procesos esté protegida; es que para un proceso la memoria de los otros está fuera del espacio de direcciones. Si un proceso diese una batida a todas las direcciones de memoria, no sería capaz ni de referenciar una dirección de memoria de otro proceso.

¿Por qué esto no se puede trampear?

Para modificar lo comentado –por ejemplo, generar puntos de entrada en anillo 0, modificar los vectores de interrupciones, modificar la memoria virtual, modificar la LGDT…– solo es posible desde el anillo 0.
Es decir, para que un proceso pudiese tocar la memoria de otros procesos o del kernel, debería ser el propio kernel. Y el hecho de que haya un único punto de entrada y que los parámetros se pasen por registros complica la trampa –de hecho, se pasa por registro hasta lo que se debe hacer, que se implementa luego como un case en la rutina de atención a la interrupción 80h–.
Otro escenario es el caso de sistemas operativos con cientos de llamadas no documentadas al anillo 0, donde esto sí es posible –siempre puede quedar una llamada olvidada mal implementada sobre la que se pueda desarrollar una trampa–, pero en caso de un sistema operativo con un mecanismo de paso tan simple, no lo es.

Por ello, la arquitectura de memoria virtual impide este mecanismo de transmisión; ningún proceso –ni siquiera los que tienen privilegios de root– tienen forma de acceder a la memoria de otros. Podríamos argumentar que un proceso puede ver el kernel; lo tiene mapeado a partir de su dirección de memoria lógica 0xC0000000. Pero, por el anillo del procesador en el que se ejecuta, no puede modificarlo; generaría un trap, ya que son zonas de memoria que pertenecen a otro anillo.

La “solución” sería un programa que modificara el código del kernel cuando es un fichero. Pero el hecho de que estos se recompilen, lo hace imposible. No se puede parchear el binario, ya que hay millones de kernels binarios distintos en el mundo. Simplemente con que al recompilarlo le hubiesen puesto o quitado algo al ejecutable del kernel, o le hubiesen cambiado el tamaño de alguna de las etiquetas que identifican la versión de compilación –algo que se hace incluso involuntariamente– el parche binario no se podría aplicar. La alternativa sería descargar el código fuente de Internet, parchearlo, configurarlo para el hardware apropiado, compilarlo, instalarlo y reiniciar la máquina. Todo esto lo debería hacer un programa, de forma automática. Todo un reto para el campo de la Inteligencia Artificial.
Como vemos, ni siquiera un virus como root puede saltar esta barrera. La única solución que queda es la transmisión entre ficheros ejecutables. Lo que tampoco funciona como veremos a continuación.

Mi experiencia como administrador:

En más de diez años que llevo administrando Linux, con instalaciones en cientos de máquinas de centros de cálculo, laboratorios de alumnos, empresas, etc.

Nunca me ha “entrado” un virus
Nunca he conocido a alguien que le haya ocurrido
Nunca he conocido a alguien que haya conocido a alguien que le haya ocurrido

Conozco a más gente que ha visto al monstruo del Lago Ness a que haya visto virus para Linux.
Personalmente, reconozco que he sido un temerario, y he lanzado varios programas que los autoprocramados “especialistas” denominan “virus para Linux” -en adelante, los denominaré virus, para no hacer pedante el texto-, desde mi cuenta habitual contra mi máquina, para ver si es posible un virus: tanto el virus bash que circula por ahí -y que, por cierto, no me infectó ningún fichero-, como un virus que se hizo muy famoso, y salió en la prensa. Intenté instalarmelo; y después de veinte minutos de trabajo, me rendí cuando vi que entre sus exigencias estaba tener el directorio tmp en una partición del tipo MSDOS. Personalmente, no conozco a nadie que cree una partición específica para tmp y la formatee en FAT.
De hecho, algunos supuestos virus que he probado para Linux necesitan un nivel de conocimientos altos y la clave de root para ser instalados. Podríamos calificar, cuanto menos, de “cutre” un virus si necesita nuestra intervención activa para que nos infecte la máquina. Además, en algún caso requieren amplios conocimientos de UNIX y la clave de root; lo que está bastante lejos de la instalación automática que se le supone.
Infectando ejecutables en Linux:

En Linux, un proceso puede hacer simplemente lo que le permita su usuario efectivo y su grupo efectivo. Es cierto que existen mecanismos para intercambiar el usuario real con el efectivo, pero poco más. Si nos fijamos donde están los ejecutables, veremos que solamente root tiene privilegios de escritura tanto en dichos directorios, como en los ficheros contenidos. Dicho de otro modo, solamente root puede modificar dichos archivos. Esto es así en Unix desde los 70, en Linux desde sus orígenes, y en un sistema de ficheros que soporte privilegios, aún no ha aparecido ningún error que permita otro comportamiento. La estructura de los ficheros ejecutables ELF es conocida y está bien documentada, por lo que es técnicamente posible que un fichero de este tipo cargue el payload en otro fichero ELF… siempre que el usuario efectivo del primero o el grupo efectivo del primero tengan privilegios de lectura, escritura y ejecución sobre el segundo fichero. ¿Cuántos ejecutables del sistema de ficheros podría infectar como usuario común?
Esta pregunta tiene una respuesta simple, si queremos saber a cuántos ficheros podríamos “infectar”, lanzamos el comando:

$ find / -type f -perm -o=rwx -o ( -perm -g=rwx -group `id -g` ) -o ( -perm -u=rwx -user `id -u` ) -print 2> /dev/null | grep -v /proc

Excluimos el directorio /proc porque es un sistema de ficheros virtual que muestra información sobre cómo funciona el sistema operativo. Los archivos de tipo fichero y con privilegios de ejecución que encontraremos no suponen un problema, ya que con frecuencia son enlaces virtuales que constan como que pueden leerse, escribirse y ejecutarse, y si un usuario lo intenta, nunca funciona. También descartamos los errores, abundantes –ya que, especialmente en /proc y en /home, hay muchos directorios donde un usuario común no puede entrar–.Este script tarda bastante. En nuestro caso particular, en una máquina donde trabajamos cuatro personas, la respuesta fue:

/tmp/.ICE-unix/dcop52651205225188
/tmp/.ICE-unix/5279
/home/irbis/kradview-1.2/src
/kradview


La salida muestra tres ficheros que podrían infectarse si se ejecutase un hipotético virus. Los dos primeros son ficheros de tipo Unix socket que se borran en arranque –y que no pueden verse afectados por un virus–, y el tercero es un fichero de un programa en desarrollo, que cada vez que se recompila se borra. El virus, desde el punto de vista práctico, no se propagaría.
Por lo que vemos, la única forma de propagar el payload es siendo root. En ese caso para que un virus funcione es necesario que los usuarios tengan siempre privilegios de administrador. En ese caso sí puede infectar archivos. Pero aquí viene la trampa: para transmitir la infección, necesita tomar otro ejecutable, mandarlo por correo a otro usuario que solamente emplee la máquina como root, y que repita el proceso.
En sistemas operativos donde es necesario ser administrador para tareas comunes o para ejecutar muchas aplicaciones diarias, esto sí se puede dar. Pero en Unix es necesario ser administrador para configurar la máquina y modificar los archivos de configuración, así que es escaso el número de usuarios que emplea como cuenta diaria la de root. Es más; algunas distribuciones de Linux ni siquiera tienen habilitada la cuenta de root. En casi todas, si accedes como tal al entorno gráfico, el fondo se cambia a rojo intenso, y se repiten mensajes constantes que recuerdan que no se debe emplear esta cuenta.
Finalmente, todo lo que se debe hacer como root es posible hacerlo mediante un comando sudo sin riesgo.
Por ello, en Linux un ejecutable no puede infectar a otros siempre que no estemos usando la cuenta de root como cuenta de uso común; y aunque las compañías antivirus se empeñan en decir que hay virus para Linux, realmente lo más parecido que se puede crear en Linux es un troyano en área de usuario. La única forma de que estos troyanos puedan afectar algo del sistema es ejecutándolo como root y con lo privilegios necesarios. Si solemos emplear la máquina como usuarios de a pie, no es posible que un proceso lanzado por un usuario común infecte al sistema.

Mitos y mentiras:

Encontramos una gran cantidad de mitos, bulos y simplemente mentiras sobre los virus en Linux. Hagamos una relación de los mismos basándonos en una discusión acontecida hace ya tiempo con un representante de un fabricante de antivirus para Linux que se ofendió mucho por un artículo publicado en esta misma revista.
Aquella discusión es un buen ejemplo de referencia, ya que toca todos los aspectos sobre los virus en Linux. Vamos a repasar todos estos mitos uno a uno según se comentaron en aquella discusión concreta, pero que tantas veces se ha repetido en otros foros.

Mito 1:

“No todos los programas malignos, particularmente los virus, necesitan privilegios de root para infectar, sobre todo en el caso particular de los virus ejecutables (formato ELF) que infectan otros ejecutables”.

Respuesta:

Quien realice semejante afirmación desconoce cómo funciona el sistema de privilegios de Unix. Para poder afectar a un fichero, un virus necesita el privilegio de lectura –hay que leerlo para modificarlo–, y de escritura –hay que escribirlo para que la modificación sea válida– sobre el fichero del ejecutable que quiere ejecutar.
Esto es así siempre, sin excepciones. Y en todas y cada una de las distribuciones, los usuarios que no son root no disponen de estos privilegios. Luego simplemente con no ser root, la infección no es posible. Prueba empírica: En la sección anterior vimos un simple script para comprobar el rango de ficheros que pueden ser afectados por una infección. Si lo lanzamos en nuestra máquina, veremos como es ínfimo, y respecto a ficheros de sistema, nulo. Además, a diferencia de operativos como Windows, no es necesario tener privilegios de administrador para realizar tareas comunes con programas que emplean comúnmente usuarios normales.

Mito 2:

“Tampoco necesitan ser root para entrar en el sistema por vía remota, es el caso de Slapper un gusano que explotando una vulnerabilidad en el SSL de Apache (los certificados que permiten comunicación segura), creó su propia red de máquinas zombie en septiembre de 2002”.

Respuesta:

Ese ejemplo no alude a un virus, sino un gusano. La diferencia es muy importante: un gusano es un programa que explota un servicio de cara a Internet para transmitirse. No afecta a programas locales. Por ello, solamente afecta a los servidores; no a máquinas particulares.
Los gusanos han sido siempre muy pocos y de incidencia ínfima. Los tres realmente importantes nacieron en los 80, una época en la que Internet era inocente, y todo el mundo se fiaba de todo el mundo. Recordemos que eran los que afectaban a sendmail, fingerd y rexec. Hoy en día la cosa es más complicada. Aunque no podemos negar que sigue habiéndolos y que, si no se controlan, son extremadamente peligrosos. Pero ahora, los tiempos de reacción ante los gusanos son muy cortos. Es el caso del Slapper: un gusano creado sobre una vulnerabilidad descubierta –y parcheada– dos meses antes de la aparición del propio gusano.
Aún suponiendo que todo el mundo que usara Linux tuviese Apache instalado y funcionando siempre, simplemente con actualizar mensualmente los paquetes hubiese sido más que suficiente para que nunca se corriera ningún riesgo.
Es cierto que el fallo de SSL que originó Slapper era crítico –de hecho, el mayor fallo encontrado en toda la historia de SSL2 y SSL3–, y como tal fue solucionado en pocas horas. Que dos meses más tarde de que se encontrara y se solucionara dicho problema, alguien hiciera un gusano sobre un error ya corregido, y que ese sea el ejemplo más potente que se puede dar como vulnerabilidad, cuando menos tranquiliza.
Como regla general, la solución a los gusanos no es comprar un antivirus, instalarlo y desperdiciar tiempo de cómputo manteniéndolo residente. La solución es hacer uso del sistema de actualizaciones de seguridad de nuestra distribución: teniendo la distribución actualizada, no habrá problemas. Ejecutar solamente los servicios que necesitamos es también una buena idea por dos razones: mejoramos el aprovechamiento de recursos, y evitamos problemas de seguridad.

Mito 3:

“No creo que el núcleo sea invulnerable. De hecho existe un grupo de programas malignos denominados con las siglas LRK (Linux Rootkits Kernel), que se basan precisamente en que explotan vulnerabilidades de módulos del kernel y sustituyen los binarios del sistema”.

Respuesta:

Un rootkit es básicamente un parche al kernel que permite ocultar la existencia de determinados usuarios y procesos ante las herramientas habituales, gracias a que no aparecerán en el directorio /proc. Lo normal es que lo utilicen al final de un ataque, en primer lugar, van a explotar una vulnerabilidad remota para tener acceso a nuestra máquina. Después emprenderán una secuencia de ataques, para hacer escalado de privilegios hasta llegar a tener la cuenta de root. El problema cuando lo consiguen es cómo instalar un servicio en nuestra máquina sin ser detectados: ahí entra el rootkit. Se crea un usuario que será el usuario efectivo del servicio que queremos que se oculte, instalan el rootkit, y ocultan tanto dicho usuario como todos los procesos pertenecientes a dicho usuario.
De cómo ocultar la existencia de un usuario es útil a un virus es algo que podríamos discutir largamente, pero un virus que emplee un rootkit para instalarse parece divertido. Imaginemos la mecánica del virus (en pseudocódigo):


1) El virus entra en el sistema.
2) Localiza el código fuente del kernel. Si no está lo instala él mismo.
3) Configura el kernel para las opciones de hardware que procedan para la máquina en cuestión.
4) Compila el kernel.
5) Instala el nuevo kernel; modificando LILO o GRUB si es preciso.
6) Reinicia la máquina.

Los pasos (5) y (6) necesitan privilegios de root. Es algo complicado que los pasos (4) y (6) no sean detectados por el infectado. Pero lo divertido es que haya alguien que crea que existe un programa que puede hacer el paso (2) y (3) automáticamente.
Como colofón, si nos encontramos con alguien que nos dice “cuando haya más máquinas con Linux habrá más virus”, y nos recomienda “disponer de un antivirus instalado y actualizarlo constantemente”, posiblemente esté relacionado con la empresa que comercializa el antivirus y las actualizaciones. Desconfía, posiblemente sea el mismo dueño.

Antivirus para Linux:

Es cierto que existen antivirus para Linux buenos. El problema es que no hacen lo que los defensores de los antivirus argumentan. Su función es filtrar el correo que pasa de malware y virus para Windows, así como verificar la existencia de virus de Windows en carpetas exportadas vía SAMBA; con lo que si empleamos nuestra máquina como gateway de correo o como NAS para máquinas Windows, podemos protegerlas.
Clam-AV:

No terminaremos nuestro reportaje sin hablar del principal antivirus existente para GNU/Linux: ClamAV.
ClamAV es un potentísimo antivirus bajo GPL que compila para la mayor parte de los Unix disponibles del mercado. Está diseñado para analizar los adjuntos a los mensajes de correo que pasen por la estación y filtrarlos de virus.
Esta aplicación se integra perfectamente con sendmail para permitir el filtrado de los virus que puedan almacenarse en los servidores Linux que proveen de correo a las empresas; disponiendo de una base de datos de virus que se actualiza diariamente, con soporte a forma digital. La base de datos se actualiza varias veces al día, y es un proyecto vivo y muy interesante.
Este potente programa es capaz de analizar virus incluso en adjuntos en formatos más complejos de abrir, como pueda ser RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, MS Cabinet files, MS CHM (HTML COmprimido), y MS SZDD.
ClamAV soporta también mbox, Maildir, y archivos de correo en formato RAW, y ficheros Portable Executable comprimidos con UPX, FSG, y Petite. La pareja Clam AV y spamassassin son la pareja perfecta para proteger a nuestros clientes Windows desde los servidores de correo Unix.

CONCLUSIÓN

A la pregunta ¿Existen vulnerabilidades en sistemas Linux? la respuesta es ciertamente sí.
Nadie en su sano juicio lo duda; Linux no es OpenBSD. Otra cosa es la ventana de vulnerabilidad que tiene un sistema Linux que sea actualizado adecuadamente. Si nos preguntamos ¿existen herramientas para aprovechar estos agujeros de seguridad, y explotarlos? Pues también sí, pero eso no son virus, son exploits.

El virus debe saltar varias dificultades más que siempre se han puesto como un defecto/problema de Linux por los defensores de Windows, y que complican la existencia de virus reales –kernels que se recompilan, muchas versiones de muchas aplicaciones, muchas distribuciones, cosas que no pasan automáticamente de forma transparente al usuario, etc.–. Los teóricos “virus” actuales hay que instalarlos a mano desde la cuenta de root. Pero eso no puede ser considerado un virus.
Como siempre digo a mis alumnos: no me creáis, por favor. Descargad e instalaros un rootkit en la máquina. Y si queréis más, leed el código fuente de los “virus” que hay en el mercado. La verdad está en el código fuente. Es difícil a un “autoproclamado” virus seguir nombrándolo de esa forma después de leer su código. Y si no sabéis leer código, una única medida de seguridad sencilla que os recomiendo: usad la cuenta de root solo para administrar la máquina, y mantener al día las actualizaciones de seguridad.
Solamente con eso es imposible que os entren virus y muy poco probable que lo hagan gusanos o que alguien ataque vuestra máquina con éxito.

sábado, 1 de marzo de 2014

Dennis Ritchie, el gran programador que el mundo olvidó.


Dennis Ritchie

Fue un científico computacional estadounidense. Colaboró en el diseño y desarrollo de los sistemas operativos Multics y Unix, así como el desarrollo de varios lenguajes de programación como el C, tema sobre el cual escribió un célebre clásico de las ciencias de la computación junto a Brian Wilson Kernighan: El lenguaje de programación C.
Recibió el Premio Turing de 1983 por su desarrollo de la teoría de sistemas operativos genéricos y su implementación en la forma del sistema Unix. En 1998 le fue concedida la Medalla Nacional de Tecnología de los Estados Unidos de América. El año 2007 se jubiló, siendo el jefe del departamento de Investigación en software de sistemas de Alcatel-Lucent.
Nació en Bronxville (Nueva York) el 9 de septiembre de 1941. Obtuvo dos grados en Harvard, en física y matemática aplicada.
En 1967 entró a trabajar en los Laboratorios Bell, donde participó en los equipos que desarrollaron Multics, BCPL, ALTRAN y el lenguaje de programación B. En Lucent encabezó los esfuerzos para la creación de Plan 9 e Inferno, así como del lenguaje de programación Limbo.

C y Unix


Ritchie es conocido sobre todo por ser el creador del lenguaje de programación C y cocreador, junto con Ken Thompson, del sistema operativo Unix. También fue coautor junto con Brian Kernighan del manual El lenguaje de programación C, que durante años fue el estándar de facto del lenguaje (conocido como K&R C), hasta la aparición del ANSI C.
Estos aportes convirtieron a Ritchie en un importante pionero de la informática moderna. El lenguaje C aún se usa ampliamente hoy día en el desarrollo de aplicaciones y sistemas operativos, y ha sido una gran influencia en otros lenguajes más modernos como el lenguaje de programación Java. Unix también ha sentado las bases de los sistemas operativos modernos, estableciendo conceptos y principios que hoy son ampliamente adoptados.


Dennis Ritchie es con frecuencia conocido como “dmr” (su dirección de email en Bell Labs) en varios grupos de noticias de Usenet (como comp.lang.c). Ritchie es la “R” de K&R o K/R, como se conoce popularmente al famoso libro sobre C.

En 1968 ingresó en el equipo de desarrollo del sistema operativo Multics (Multiplexed Information and Computing Service) donde trabajó junto a multitud de leyendas de la programación y la arquitectura de sistemas como Fernando J.Corbató o Peter James Denning. Aunque si Dennis Ritchie es famoso por algo es por ser el creador del lenguaje de programación C.

El desarrollo de UNIX y la necesidad de C



No existe duda alguna de que C es el lenguaje de programación más popular y famoso de todos los tiempos. C es un lenguaje de programación imperativa para implementación de sistemas. Aunque al ser tan popular también se ha desarrollado infinidad de aplicaciones con él. C presenta facilidades para la programación estructurada, permite ámbito léxico variable y recursión, además esta fuertemente orientado a tipos con un sistema estático que impide operaciones no deseadas.

Como ya he apuntado anteriormente, Ritchie entró en el grupo de desarrollo de Multics en 1968, para entonces, los Bell Labs ya estaban bastante frustrados por los serios problemas que presentaba Multics y poco a poco fueron desplazando el proyecto. Los últimos investigadores en abandonar el proyecto, decidieron reescribir todo el trabajo desde cero y a menor escala. Entre esos investigadores se encontraban Dennis Ritchie y Ken Thompson —al que dedicaremos unas líneas en el futuro—.

Ritchie estaba convencido en crear un sistema operativo sobre el cual pudiera desarrollarse una comunidad ya que creía fervientemente en la computación comunal en la que era necesaria la comunicación estrecha entre personas a través de accesos remotos.

Como Ken Thompson aún tenía acceso al entorno de Multics, escribió un simulador para el nuevo sistema de ficheros y de paginación en él. También programó el famoso juego Space Travel, pero el juego requería de una máquina más eficiente y barata sobre la que ejecutarse, así primero fue portado a FORTRAN en un sistema GECOS y finalmente fue portado por Dennis Ritchie y Ken Thompson al lenguaje ensamblador de una máquina PDP-7.

Fue en ese proceso de portar el código de FORTRAN a lenguaje ensamblador del PDP-7 cuando Thompson y Ritchie escribieron el código subyacente que finalmente se convirtió en el sistema operativo originario de UNIX. Junto a Rudd Canaday desarrollaron un sistema de ficheros jerárquico, los conceptos de proceso de ejecución y de archivos de dispositivo, un intérprete de línea de comandos y algunas aplicaciones y utilerías. Muchos consideran a Space Travel como la primera aplicación del sistema UNIX.

En 1970 el equipo de desarrollo liderado por Dennis Ritchie y Ken Thompson necesitaban migrar el sistema a una plataforma más potente y pusieron su vista en la PDP-11/20. Y el manual del programador de UNIX salió a la luz el 3 de Noviembre de 1971. En 1972 y contra toda razón, UNIX fue portado al lenguaje de programación C de forma contraria a la idea general de la época de que “algo tan complejo como un sistema operativo, que debía tratar con eventos en tiempos críticos, debía estar escrito completamente en lenguaje ensamblador”.



Sin embargo el portar el código fuente de UNIX a un lenguaje de más alto nivel como C, derivó en un código mucho más portable que requería de cambios mínimos en su código cuando se portaba UNIX a otra plataforma cosa que parecía que iba a ser cada vez más común. La incapacidad del lenguaje de programación B para usar las ventajas de la máquina PDP-11, especialmente del direccionamiento de byte llevó a Ritchie a desarrollar la primera versión de C.

La primera versión del UNIX para PDP-11 fue completamente escrito en lenguaje ensamblador, pero cuando las primigenias versiones de C ya soportaban los tipos de estructura, la mayor parte del núcleo de UNIX fue portada a C. El núcleo de UNIX se convirtió así en uno de los primeros núcleo de sistemas operativos escrito en algo diferente a lenguaje ensamblador junto a Multics y MPC.
K&R C

En 1978, Brian Kernighan —al que también dedicaremos algunas líneas más adelante— y Dennis Ritchie publicaron la primera edición de El lenguaje de programación C. El libro pronto se empezó a conocer en la comunidad como K&R C o C de Kernighan y Ritchie y fue usado durante muchos años como una especificación informal del lenguaje antes de la aparición del ANSI C.

El C de Kernighan y Ritchie tenía algunas peculiaridades , como la de que las funciones que no devolvían un tipo de valor diferente a un entero, no tenían por qué ser definidos previamente con un prototipo. Así por ejemplo esta sintaxis era válida en K&R C pero no en ANSI C:

main() {

}

En 1983, Ritchie y Ken Thompson recibieron conjuntamente el Premio Turing por el desarrollo de la teoría genérica de sistemas operativos y específicamente por la implementación del sistema operativo UNIX. Ritchie nombró a su conferencia en la entrega del Premio Turing como “Reflexiones sobre la Investigación del Software”.


Ritchie fue elegido miembro de la Academia Nacional de Ingeniería en 1988 por el desarrollo del lenguaje de programación C y por el desarrollo conjunto del sistema operativo UNIX. En 1990, tanto Ritchie como Thompson recibieron la medalla IEEE Richard W.Hamming del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) por “originar el sistema operativo UNIX y el lenguaje de programación C”

El 21 de Abril de 1999 Ritchie y Thompson recibieron conjuntamente la Medalla Nacional de Tecnología de 1998 de manos del presidente Bill Clinton por la invención conjunta del sistema operativo UNIX y el lenguaje de programación C que en conjunto han dado lugar a enormes avances en el hardware, el software, redes de sistemas y ha estimulado el crecimiento de una industria por completo, mejorando así el liderazgo estadounidense en la era de la información. Estos yankees es que son muy suyos.

Este mismo año, Ritchie y Thompson han sido galardonados con el Premio Japón de Información y Comunicación por el trabajo pionero en el desarrollo del sistema operativo Unix.

Vida después de UNIX y C



En 1990 Ritchie fue nombrado jefe del Departamento de investigación de Software en el Centro de Investigación de los Laboratorios Bell en Murray Hill, New Jersey. En 1996 fue nombrado director de desarrollo para la creación del sistema operativo Plan 9 sucesor de Unix en Bell —del que también hablaremos algún día —. En 1996 comienza a dirigir los esfuerzos para la creación del sistema operativo Inferno, sistema operativo distribuido que corre encima de otro sistema operativo a través de una máquina virtual.

El sistema operativo Plan 9 se basa en un Kernel híbrido y no en uno Monolítico como el de Unix.

Sobre Dennis Ritchie


Si no fuera por Dennis Ritchie y por Ken Thompson, UNIX jamás hubiera existido, tampoco hubiera existido por tanto BSD, o Solaris o Minix y mucho menos Linux, tampoco existiría Mac OS X. Y si no fuera especialmente por Dennis Ritchie, no existiría C, no existirían muchos conceptos que en su día rompieron esquemas a través de su innovadora visión y se convirtieron en al ABC de la teoría de los sistemas operativos por lo que sería complicado que hubieran existido hoy sistemas como Windows, PlayStation, o PCs. Sin C otros muchos lenguajes que se basaron o inspiraron en C tampoco existirían hoy y por nombrar solo unos pocos:

C++
C#
Objective-C
D
Java
JavaScript
Limbo
Perl
PHP

Y por supuesto, tampoco existiría ninguno de los lenguajes basados en los pocos de la lista anterior. Si existe alguien a quien haya que agradecerle especialmente su trabajo y dedicación, no cabe duda de que ese es Dennis Ritchie.


Murió la noche del miércoles 12 de octubre de 2011 en compañía de su familia. Su amigo Robert Pike, fue el primero en dar la noticia a través de la red social Google+.