Videos de Geeko animado! Have a lot of fun!!

Te apetece ver una pequeña muestra de vídeos de animación de SUSE y openSUSE con Geeko como protagonista.

opensuse_logo

Geeko es el nombre que del camaleón que tiene como logotipo openSUSE y SUSE. Un simpático camaleón de color verde, que a los usuarios de esta distro nos gusta tener visible. Ya sea en el fondo de pantalla o en la pantalla de inicio, etc… El nombre proviene de una mezcla entre geek (friki de la tecnología) y geko (lagarto,o reptil parecido)

Pero Geeko tiene vida, no es sólo un camaleón sonriente que vemos de perfil! Geeko salta, surfea, y mucho más! Y como buen camaleón también se mimetiza con el entorno y a veces no le ves!

Hoy a raíz de un vídeo que he visto de una animación de SUSE, quería traer por el blog una recopilación de videos que tienen como protagonista a Geeko, donde le podreis ver en diversas facetas. Espero que os resulte interesante y paseis un buen rato, ya sabes lo que dice Geeko al arrancar el sistema: Have a lot of fun!! ;)

 

E incluso yo me atreví a hacer unos vídeos en Blender con animaciones, no con Geeko, pero sí basadas en openSUSE!

 

Y si queréis jugar con Geeko y crearos uno a medida de vuestros gustos, aqui os dejo este enlace: GeekoBuilder donde le podréis disfrazar, customizar, y ponerle en los entornos más raros!! Crearos un fondo de pantalla, un avatar o una imagen customizada de Geeko, que incluso puedes imprimir en una camiseta o en una taza!!

 

———————————————————————————————————————–

Entrevista a Vincent Untz. Nuevo “jefe” de openSUSE

Hace unos días se publicaba una entrevista con el nuevo presidente del consejo de openSUSE, Vincent Untz. Te la traigo traducida al español para que sepas que piensa sobre nuestra ditro el nuevo “jefe”

Hace un tiempo ya publiqué por el blog que el proyecto openSUSE tenía nuevo jefe (puedes ver el artículo aqui). Vincent Untz un desarrollador implicado en Gnome era elegido por SUSE para presidir el consejo de openSUSE. Este consejo (board en inglés) está formado por 6 miembros. 5 son elegidos por la comunidad y el presidente es elegido por SUSE. por cierto dentro de poco serán las elecciones para ocupar uno de los 5 puestos elegibles, si crees y quieres optar a un sitio estate atento…

¿Quieres saber quien ocupa actualmente estos puestos en el consejo de openSUSE? Mira este enlace: http://en.opensuse.org/Board son un grupo abierto a escuchar a la comunidad por tanto no dudes en ponert en contacto con ellos en cuestiones relacionadas con consultas sobre el proyecto, etc… eso sí, no les preguntes sobre drivers, u otras cuestiones técnicas, para eso hay otros cauces…

En la web http://www.muktware.com/ han publicado una entrevista a Vincent Untz, donde este ha hablado sobre openSUSE, y que tiene previsto para el proyecto y como conseguirlo. Una entrevista interesante para todos aquellos que somos usuarios de esta distro. Me pareció interesante, así que despues de dedicarle unas cuantas horas te la he traducido del inglés al español, para facilitarte la tarea ;) y la publico en mi blog.

El enlace de la página original es este: www.muktware.com/4484/interview-new-opensuse-chairman-vincent-untz y los créditos pertenecen a Swapnil Bhartiya, gracias a él y a la página por permitir la traducción. Tanto el original como la traducción que he hecho estan licenciados bajo licencia CC-by-sa puedes utilizarlas pero enlazando tanto el original como este blog, gracias.

Me pareció interesante, espero que también lo sea para vosotros, lo hice de la mejor manera que sé, estoy abierto a comentarios y sugerencias constructivas de mejoras que tengáis o correcciones, no dudeis en comentar. Empezamos…

Vincent Untz fue nombrado recientemente presidente del consejo de openSUSE. Fue una gran oportunidad para hablar con Vincent y entender un poco más que papel desempeña el presidente. Desde que Untz se dedicaba a gestionar los lanzamientos de Gnome hemos hablado mucho sobre el desarrollo de Gnome. Sigue leyendo…

Felicidades por tu nombramiento de presidente. ¿Qué papel desempeñas y que responsabilidades conlleva esta nueva posición? ¿En otras palabras que hace un presidente de openSUSE?
Gracias la verdad es que estoy muy ilusionado con este nuevo cargo como presidente.

Supongo que lo primero es explicar el papel del consejo de openSUSE. Es un grupo formado por seis personas (cinco miembros elegidos por la comunidad y un presidente elegido por SUSE). El consejo se encarga de servir y guiar a la comunidad y el proyecto, en todos los aspectos no extrictamente técnicos. Esto incluye cosas como: la organización del proyecto y la comunidad, los aspectos legales y financieros, y también la relación con nuestros patrocinadores.

Se podría decir que es un especie de “liderazgo suave”

Ahora, el presidente es un miembro del consejo que además preside el consejo. Lo que de verdad significa esto es que el presidente está para asegurarse de que el consejo se mantiene activo y útil. También está para ayudar a asegurar la continuidad del consejo.

Por lo menos esta es la manera en que yo lo veo. No creo que el presidente sea mucho más diferente que otro miembro del consejo. La posición lógicamente significa algo de cara al exterior, así que algo de expectación conlleva. Lo que supongo que es por eso por lo que estoy aquí respondiendo a tus preguntas.

Permiteme que aproveche la oportunidad para mencionar que tendremos las elecciones anuales para el consejo de openSUSE dentro de pocos meses, y todos aquellos que estén interesados en ocupar un asiento en el consejo de openSUSE deberían empezar a pensárselo ya mismo!

La conferencia de openSUSE está ya más cerca. ¿Cual será la agenda de la conferencia?
Así es, la conferencia de openSUSE se llevará a cabo del 20 al 23 de Octubre en Praga. Todo el mundo que este cerca no debería perdérselo, especialmente porque se celebrarán otros tres interesantes eventos: SUSE Labs, Gentoo Miniconf y LinuxDays. ¡Seguro que será fantastico!

La programación de la conferencia de openSUSE lo puedes ver aquí: http://bootstrapping-awesome.org/schedule/

Hay sesiones para estar al tanto de las últimas novedades de proyectos específicos (Wayland, LibreOffice, ownCloud, etc.) para aprender a utilizar algunas tecnologías (empaquetado de software, AppArmor, y más) para saber más sobre la comunidad (nuestro programa de embajadores, gestión de lanzamientos, nuestro programa de ayuda a los viajes,…) Habrá incluso una sesión sobre Watson, el super ordenador de IBM qye ganó al campeón de Jeopardy!

Y hemos hecho una llamada para las sesiones BoFs, así que habrá más novedades que las publicadas en el programa de la conferencia.

Personalmente, me gustaría enfocar mi tiempo en las sesiones enfocadas con nuestra comunidad, y los cambios a los que nos enfrentamos. También me gustaría pasar un tiempo charlando con todos sobre nuestro proyecto: sería una buena manera de conocer opiniones y recopilarlas para en Consejo. Encontrarse con todos los usuarios de la comunidad es lo mejor de la conferencia!

Has sido el gestor del lanzamiento de Gnome, el lanzamiento 3.x está pasando por una transición y teniendo algunas críticas como las tuvo KDE cuando pasó a la versión 4.x o como cuando Ubuntu se decantó por Unity. Es normal, a la gente le gusta el statu quo (N.T:“estado del momento actual”) He sido usuario durante mucho tiempo de GNOME y me gustan los cambios (esto es una opinión personal) Hay algunas criticas válidas y prácticas como que las extensiones han dejado de funcionar con los últimos lanzamientos y dejan una mala experiencia… (por ejemplo la 3.6 está lanzada y la mayoría de extensiones ya no funcionan) así que, ¿Qué está haciendo el equipo de Gnome ante hechos como estos?
Primero no estoy de acuerdo en que está recibiendo las mismas críticas que cuando KDE cambió a su versión 4.x. Con KDE 4.0 la mayoría de la gente se quejaba de su estabilidad, y no es sorprendente, ya que la versión 4.0 estaba más orientada hacia los desarrolladores que para ser usada por los usuarios. Hubo una falta de comunicación.

Con GNOME 3, las quejas recibidas son por lo general sobre cambios en la experiencia del usuario. La gente estaba muy agusto con GNOME 2 y muchos no querían un cambio real. Sin embargo como comunidad hemos querido llevar a Gnome por una nueva dirección, hacia una nueva visión. Creemos que esta nueva visión es mejor que la de GNOME 2, y estamos trabajando duro para satisfacer a nuestros usuarios. Estamos escuchando y trabajando en resolver los problemas que la gente está viendo en GNOME 3, mientras nos mantenemos fieles a nuestra visión.

Nuestro proceso iterativo de lanzamientos de GNOME 3 nos permite ofrecer un flujo constante de mejoras en cuanto a la experiencia con GNOME 3 desde Abril del 2011. Es por ello que hemos visto en los últimos meses cada vez más gente empezando a hablar sobre lo que de verdad les gusta de GNOME 3. Es cierto que lo que hacemos no es todo lo todos esperan de nosotros (no podemos complacer a todos…), pero creo que estamos haciendo las cosas bien, y muchos usuarios nos lo dicen.

Sobre el error en concreto que mencionas en cuanto a las extensiones: estamos trabajando para mejorar la gestión de las extensiones. Habrá actualizaciones automáticas de las extensiones en la versión 3.8 por ejemplo (echa un vistazo a esto: https://live.gnome.org/ThreePointSeven/Features/ExtensionUpdates) El hecho de que las extensiones dejarande funcionar despues de una actualización a una nueva versión de GNOME (de la 3.4 a la 3.6, no de la 3.6.0 a la 3.6.1) es debido a la falta de garantías API dentro de GNOME Shell. Llevará un tiempo solucionar esto, de la misma manera que lleva un tiempo a Firefox mantener funcionando las extensiones por defecto despues de una actualización.

Iniciaste el proyecto AppStream. ¿Cual es el estado actual del proyecto?
Se está desarrollando más despacio de lo que deseamos, pero más que nada por que todos los que estan interesados en el proyecto se encuentran muy ocupados con otros proyectos.

Las buenas noticias es que tenemos un gan proyecto dentro del programa Google Summer of Code realizado por Mathias Klumpp, que ha traído muy buenos resultados.

  • Mejora sustancial de PackageKit, gracias a muchas optimizaciones y soporte a transacciones paralelas.
  • Muchas mejoras de velocidad y soluciones a la rama del software-center (como recordatorio, decidimos realizar una nueva rama porque Canonical no quiso proporcionar el CLA necesario para contribuir)
  • AppStream core: Un juego de accesorios para acceder a información de la base de datos de AppStream.

Y lo mejor de todo, openSUSE ya tiene disponible los metadatos de AppStream en sus repositorios. Esto significa que una vez que tengamos una herramienta para gestionar aplicaciones, lo tendremos inmediatamente disponible para funcionar.

Y relacionado con este tema, el equipo de diseño de GNOME ha creado un diseño para una aplicación software que encaja perfectamente con nuestras metas. Estoy seguro de que será lo mejor que se ha creado para AppStream.

De forma contraria a estos esfuerzos estamos viendo cada vez más trabajos duplicados. ¿Cual es tu opinión sobre Unity de Ubuntu que está basado en GNOME o Cinnamon?
Me preocupo por nuestra libertad, así que no me opongo a que la gente desarrolle sus propios proyectos! Pero obviamente estoy un poco triste debido a esta duplicación, especialmente porque esto implica que nos moveremos un poco más lento ya que no trababjamos todos en el mismo proyecto. Afortunadamente tanto Unity como Cinnamon están usando mucha tecnologías de GNOME con lo que podemos compartir y colaborar, y esto limita también la duplicación de esfuerzos. Realmente espero que no habrá divergencias en las necesidades de estas tecnologías, así que podemos seguir por este camino.

Ahora si me preguntas ¿Qué escritorio es mejor? Obviamente, mi respuesta será: GNOME. Pero para ser honestos no he utilizado Unity ni Cinnamon recientemente, y por eso no puedo comentar sobre las cosas nuevas que ofrecen a los usuarios. Estoy más interesado en la historia de fondo.

En el caso de Unity, creo que el camino actual que está siguiendo claramente indica que Canonical quiere controlar el desarrollo de su experinecia como escritorio, y Cononical no sería capaz de tener el control de GNOME. Era inevitable que Canonical tubviera su propio proyecto!

Y respecto a Cinnamon: Actualmente no tengo claro porque no permaneció como un juego de extensiones de GNOME, y porque decidió separarse de gnome-shell y de mutter. Especialmente mutter: no creo que fuera un problema el seguir usándolo, y mirando a la escisión (llamada muffin) no veo muchos cambios. De nuevo, está bien dividirse, pero no sé exactamente porque era necesario en vez de hacer de gnome-shell más extensible para las necesidades de Cinnamon.

¿Por que no existe en openSUSE un cliente para Ubuntu One? ¿Teniendo en cuenta que es un cliente de ownCloud?
Creo que el cliente de Ubuntu one es software libre, no? Así que la respuesta es simple porque nadie se ha preocupado lo suficiente para empaquetarlo. Actualmente no he oído a nadie pidiéndolo.

¿Cual es el perfil de usuarios que busca openSUSE ya que todavía hay algunas rarezas para un usuario doméstico medio? Añadir una impresora puede convertirse en un pequeño reto, donde un usuario debe añadirse dentro de los grupos. Lo que quiero entender es cuando miramos hacia Ubuntu o Linux Mint vemos una ventaja ya que un usuario doméstico no necesita ser un experto en ordenadores, donde te gustaría situar a openSUSE?
[Humm, no creo que un usuario deba añadirse dentro de los grupos para instalar una impresora. Al menos nunca he tenido que hacerlo. Así que este ejemplo en especial suena más como si se tratase de un error]

Hace unos pocos años, tuvimos una larga discusión sobre nuestra estrategia y nuestra misión. El resultado se publicó aquí (http://en.opensuse.org/openSUSE:Strategy) y ahí se menciona específicamente a l tipo de usuarios que queremos: buscamos usuarios “que esten interesados en los ordenadores y quieran el trabajo hecho, experimentar o aprender”. Diría que esto está un poco más orientado a usuarios avanzados que los usuarios domésticos normales, pero, obviamente, no queremos excluir a los usuarios domésticos medios.

En términos de características, este tipo de usuarios nos lleva a preocuparnos mucho en lo referente a la estabilidad (lo que significa, que a veces no adoptamos las últimas tecnologías punteras) y libertad de elección (tenemos un gran soporte para GNOME, KDE, XFCE y más), pero también nos piden opciones potentes como nuestro rolling release (Tumbleweed) para tener el software más reciente con un núcleo estable.

Si echas un vistazo a nuestro proyecto, estamos desarrollando un gran número de herramientas que permitan a los usuarios contribuir. Simplemente echa un vistazo a Open Build Service  por ejemplo, esto permite a los usuarios empaquetar software de una manera muy simple y así mismo hace muy fácil contribuir con openSUSE, son sólo unos pocos comandos. (Por cierto, esto es lo que hace Tumbleweed tás fácil de mantener) Con este tipo de herramientas obviamente queremos atraer usuarios que se impliquen en la mecánica propia de la distribución y contribuyan.

En definitiva, creo que estamos dirigidas a un público un poco diferente a Ubuntu y Linux Mint, aunque creo que estamos trabajando duro para no alienar a ese público, ni siquiera en openSUSE.

Las tabletas son la nueva “plataforma”, ¿Qué planes tiene openSUSE para las tabletas?
No hay un plan específico para las tabletas en openSUSE ahora mismo, pero esto es debido principalmente a que trabajamos como una distribución: openSUSE es actualmente bastante fiel a la experiencia de nuestros desarrolladores, y por ello confiamos en ellos para que nos provean una buena experiencia con las tablets. Lo que importa obviamente en este caso es la interface del usuario. Así que actualmente es más una pregunta dirigida a los desarrolladores.

(N. del T: en esta respuesta he traducido el término “upstream” que utiliza Vincent como desarrolladores, entiendo que se refiere a aquellos que desarrollan el kernel o los entornos de escritorio, ya que openSUSE sólo los disribuye junto con alguna herramienta propia)

Sé que GNOME está haciendo progresos sólidos para dar un buen soporte a dispositivos táctiles (el primer paso son las tablets). En KDE, se está trabajando en el proyecto Plasma Active para las tablets, y por supuesto está disponible en los paquetes de software de openSUSE.

Otra pregunta curiosa, ¿Por que openSUSE se está alejando de Raspberry Pi?
Es simple, hasta hace poco no teníamos un soporte oficial para arquitecturas ARM. Pero tenemos un equipo muy activo que está trabajando en ello, y hace poco hemos lanzado la primera versión candidata con soporte ARM de openSUSE

Este esfuerzo implicó un trabajo en habilitar infraestructuras que permitiesen ARM, y también solucionar algunos paquetes de software que tenían problemas de compilación para ARM. Mientras que todavía no existe una imagen para Raspberry Pi, Bernhard M. Wiedemann ha publicado hace pocas semanas una imagen no oficial.

Después de todo esto es algo imparable, y hay un gran interés en la comunidad en dar soporte a ARM. En la próxima openSUSE conference en Praga el equipo de ARM dará varias sesiones sobre el soporte a esta tecnología.

—————————————————————————–

openSUSE en Praga #oSC12

Asiste del 20 al 23 de Octubre de 2012 en Praga a la openSUSE Conference. Comparte, aprende y diviértete con otros usuarios de GNU/Linux!

Empieza el mes de Octubre, y quizás tengas unos días libres para disfrutar. Si es así y si eres un entusiasta de openSUSE o de GNU/Linux puedes escoger Praga como destino y disfrutar de una bonita ciudad y una vacaciones geeks!

Si el pasado mes de Septiembre Florida fue el epicentro de la comunidad de openSUSE, ahora el punto de encuentro será en Europa y en la República Checa, ya que del 20 al 23 de Octubre en Praga tendrá lugar lo que se ha denominado openSUSE Conference 2012. Un encuentro de usuarios, simpatizantes y desarrolladores en torno a esta distribución de GNU/Linux.

Pero no sólo quiere ser una reunión de amigos de Geeko! Tambien quiere compartir y unirse a otros simpatizantes de GNU/Linux, por lo que se celebrarán 4 encuentros en un sólo lugar. Sí, en el mismo sitio coincidirán otros tres eventos aparte del de openSUSE. En el mismo lugar se llevará a cabo el evento Checo LinuxDays (os dejo el enlace por si sabéis Checo), Gentoo minisummit un encuentro de los usuarios de esta distro, y Suse labs.

Las conferencias se darán en inglés, pero gente habrá de todo el mundo, yo ya he hablado con un Hondureño que se va a acercar, y también irá el webmaster de la página KDE Blog Baltasar Ortega. Pero no sólo como oyente! este último dará una conferencia, que lleva ya tiempo ensayando, por eso del acento inglés. Una conferencia que según él mismo dice en su blog se titula: “Teaching Free Software for everybody” y comenta:

[...]en ella pretendo demostrar que todo el mundo puede enseñar, aprender y aportar cosas al mundo del Software Libre.

Un buen ejemplo es su blog didáctico, y a la última de las novedades en cuanto a KDE y otros proyectos de software libre se refiere. Le deseo éxito y que todo vaya bien.

Si quieres ir pero el tema del dinero es un problema ya sabes que openSUSE pone remedio a esto financiando en parte los costos del viaje, con el programa de ayuda de viajes y alojamiento. Regístrate y si asistes no olvide la cámara de fotos para compartir con los que no podemos asistir, lo que allí ocurra. Todavía tienes tiempo para pensártelo y apuntarte, pero date prisa!!

Aprende, comparte y sobre todo… Have a lot of fun!! ;)

Enlaces de interés:

Página oficial del evento | conference.opensuse.org/
Últimas noticias | news.opensuse.org/2012/09/12/time-to-start-planning-your-sessions-conference-program-available/
Programa de ayuda al viaje | en.opensuse.org/openSUSE:Travel_Support_Program
Anuncio de KDEBlog | www.kdeblog.com/kde-blog-estara-presente-en-opensuse-conference-2012-de-praga.html
LinuxDays | http://www.linuxdays.cz/cs/
Gentoo miniconf | http://www.gentoo.org/proj/en/miniconf/

————————————————

SUSE y el Arranque Seguro: Los detalles

En este artículo podrás encontrar la traducción del artículo escrito en inglés por Vojtěch Pavlík: “SUSE and Secure Boot: The Details” una visión interesante de SUSE ante UEFI.

Desde los blogs de SUSE Olaf Kirch y Vojtěch Pavlík nos han dado una visión de los planes de esta empresa de GNU/Linux ante la nueva medida UEFI y Arranque Seguro. Estos son los planteamientos propuestos por SUSE.

openSUSE es una comunidad aparte que puede tomar sus propias decisiones, pero siempre está bien saber qué es lo que dicen los desarrolladores de SUSE y cuales son sus medidas ante esta nueva característica de seguridad.

GRACIAS a Vojtěch Pavlík por permitirme la traducción y la publicación de su artículo. Puedes ver el original en este enlace: www.suse.com/blogs/uefi-secure-boot-details/

GRACIAS también a Javier Llorente, miembro destacado de la comunidad de openSUSE por sacar tiempo de sus múltiples proyectos y su tiempo libre y ayudarme a corregir la traducción, bueno, y por todo!! ;)

Espero que aclare un poco la forma en la que SUSE tratará de mantener la libertad en tu PC y al mismo tiempo no renunciar a la seguridad del mismo. Vamos con la traducción:

En artículos anteriores Olaf Kirch nos ha hecho una introducción sobre el arranque seguro UEFI y el enfoque de SUSE sobre cómo abordar este tema. En este artículo os daré los detalles técnicos de nuestro plan sobre el arranque seguro. Así que prepararos para un artículo un tanto minucioso y técnico.

El objetivo del arranque seguro es prevenir que el malware se esconda de forma embebida durante el proceso de arranque realizando una comprobación de todos los componentes y tareas que se ejecuten durante un arranque en frío de todo el sistema.

Para lograr su objetivo, el arranque seguro debe impedir cualquier modificación del proceso de verificación, de las llaves, o de cualquier otra variable como código no confiable o entidades que no sean de confianza. Un ejemplo de una entidad en la que no se confía podría ser un pirata informático que ha penetrado en el sistema a través de un agujero de seguridad sin parchear en el sistema operativo.

Hay dos tipos de usuarios en los que se puede confiar:

  1. Primero, aquellos que tienen las llaves. La llave de la plataforma (Platform Key ó PK) permite casi todo. La llave de intercambio de llaves (Key Exchange Key ó KEK) permite todo, excepto que una PK pueda cambiar la PK.
  2. Segundo, cualquiera con acceso físico a la máquina. Un usuario con acceso físico puede reiniciar la máquina, y configurar el UEFI.

El arranque seguro UEFI ofrece dos tipos de variables para satisfacer las necesidades de los usuarios:

  1. La primera son las denominadas “variables autenticadas” – “Authenticated Variables” en inglés. Que se pueden actualizar tanto durante el proceso de arranque (denominado Entorno de Servicios de Arranque – Boot Services Environment) o desde el sistema operativo, pero sólo cuando el nuevo valor de la variable este firmada con la misma llave que el valor antiguo con el que la variable se firmó . Y sólo se puede añadir o cambiar a un valor con un número de serie mayor.
  2. La segunda es la denominada “variables exclusivas para Servicios de Arranque” – “Boot Services Only Variables”. Estas variables son accesibles para cualquier código que se ejecuta durante el proceso de arranque. Después de que el proceso de arranque termine y antes de que se inicie el sistema operativo, el gestor de arranque debe llamar a ExitBootServices(). Después de eso, estas variables ya no son accesibles, el sistema operativo no las puede tocar.

Las diferentes listas de llaves UEFI son del primer tipo, ya que esto permite la actualización on-line, añadir y poner en una lista negra de llaves, huellas digitales de controladores y firmware. El segundo tipo de variables, “variables exclusivas para servicios de arranque” son las que nos ayudarán en nuestra búsqueda de una implementación de arranque seguro que sea a la vez segura y compatible con la filosofía de código abierto. Y compatible con la GPLv3.

Como Olaf explicó en el anterior artículo, en SUSE hemos empezado desarrollando una “aplicación cuña” basada en la de Fedora, firmada con un certificado firmado por el KEK de SUSE o con un certificado emitido por Microsoft, basado en las KEK’s que están disponibles en la base de datos de llaves de UEFI del sistema

Esto permite a esta aplicación cuña cargarse y ejecutarse.

Esta aplicación cuña arranca para verificar que el gestor de arranque GRUB2 que quiere arrancar es de confianza. Para ésto no usará ni la KEK de SUSE ni el certificado emitido por Microsoft. En una situación por defecto, la aplicación cuña usará un certificado de SUSE independiente embebido en su código. Además, la aplicación cuña permitirá “grabar” nuevas llaves, reemplazando la llave de SUSE por defecto. A estas las llamaremos “llaves propietarias de la máquina – Machine Owner Keys” lo que para abreviar llamaremos MOKs

El proceso de grabado empieza reiniciando la máquina e interrumpiendo el proceso de arranque (por ejemplo, pulsando una tecla) mientras la aplicación cuña arranca. La aplicación cuña entrará entonces en un modo de grabado, permitiendo al usuario reemplazar la llave por defecto de SUSE con llaves que están en un fichero en la partición de arranque.

Si el usuario elige hacer ésto, la aplicación cuña entonces calculará un nuevo hash de ese archivo y pondrá el resultado en una variable “exclusivas para servicios de arranque”. Ésto permite a la aplicación cuña detectar cualquier cambio del fichero hecho fuera de los servicios de arranque y evitar así la manipulación usando la lista de usuarios autorizados de MOKs.

Un aspecto importante a tener en cuenta es que todo ésto pasa durante el tiempo de arranque, en el cual sólo se ejecuta código verificado. Por lo tanto, sólo un usuario presente delante de la consola puede decir “quiero usar mi propio juego de llaves”. Cosa que no podrían hacer ni un pirata informático ni malware con acceso remoto a nuestro PC, ya que los piratas o el malware sólo pueden cambiar el archivo pero no el hash almacenado en las variables exclusivas para los servicios de arranque.

Una vez cargado y verificado GRUB2 por la aplicación cuña, volverá a llamar a esta aplicación cuña cuando quiera verificar el kernel, para evitar la duplicación de verificación de código. La cuña utilizará la misma lista que MOKs para esto y dirá a GRUB2 si se puede cargar el kernel o no.

¡Y ésto es todo!

Ésto es todo lo que necesitas para ser capaz de trabajar mejorando el kernel o el gestor de arranque. Instalar un nuevo juego de llaves y autorizarlas in situ durante el primer reinicio.

También gracias a que los MOKs son una lista y no una sola MOK, puedes hacer que el proceso intermedio o cuña valide llaves de varios fabricantes diferentes, permitiendo un arranque no sólo dual, sino múltiple desde el GRUB2 del gestor de arranque.

Al final la implementación real de este sistema puede ser algo más complicada, por ejemplo, proteger con contraseña la autorización de MOK para permitir una actualización autentificada y segura de la lista de MOKs desde el propio sistema operativo, pero este es el quid de la cuestión, y como puedes modificar libremente el GRUB2 y el kernel de una máquina, puedes estar tranquilo ya que tu máquina seguirá cumpliendo la licencia GPLv3 y no será tivoizada (saltarse a la torera la licencia)

Quizás te preguntes si ésto va en contra de lo que permiten las especificaciones UEFI o de los requisitos del logo de Win8 de Microsoft o de cualquier otro contrato relacionado.

Yo no creo eso – incluso las especificaciones de la UEFI permiten, pero no obligan, que la implementación UEFI permita a un usuario autorizar código EFI con una firma no válida añadiendo un hash a una variable especial.

Y la Linux Foundation ha preguntado a los fabricantes para asegurarse de que incluyan una manera de limpiar los PK para permitir a el usuario grabar su propio juego de llaves.

Nuestro enfoque es simplemente asegurarse que una característica como ésta está disponible en todas partes. Y mantener libre la plataforma “PC”.

—————————————————-

Si quieres, puedes descargarte el documento traducido en PDF pinchando en este botón:   

NOTA:

SUSE y openSUSE propuestas de enfoque ante UEFI y el Arranque Seguro

Por este blog ya he hablado de UEFI y el Arranque Seguro, una medida que pretende hacer más seguros nuestros Pc’s, pero que esconde una cara poco amable y que atenta directamente contra la libertad del usuario de utilizar e instalar el software que le venga en gana. La comunidad de Software Libre y los usuarios de GNU/Linux somos la parte más afectada, debido a cómo crece y se desarrolla esta comunidad esta medida constituye un atraso considerable.

Las distintas comunidades de GNU/Linux se han propuesto adoptar fórmulas que sean beneficiosas para todos. En este caso la comunidad de SUSE ha escrito una serie de notas en las que detallan sus planes. Olaf Kirch ha escrito unas primeras notas contando los planes de SUSE,  la comunidad de openSUSE se rige de manera independiente a esta, pero siempre está bien conocer estas propuestas y tomarlas en consideración.

Así que para ello he traducido del inglés los dos primeros artículos de Olaf, que me ha permitido que los publique.

Puedes ver el original del primer artículo en este enlace: uefi-secure-boot-overview/ y en este la traducción que he hecho: victorhckinthefreeworld.wordpress.com/suse-opensuse-ante-uefi-y-el-arranque-seguro

Ahora te traigo traducido el segundo de los artículos escrito por Olaf, gracias de nuevo por permitir la difusión de su trabajo, puedes ver el original en este enlace: uefi-secure-boot-plan/ y si quieres ver la traducción sigue leyendo!

Ahora más que nunca debe ser “open”SUSE

Este nuevo artículo es una continuación de este primer artículo.  Describiré nuestros planes frente a UEFI y el Arranque Seguro (Secure Boot). Ten en cuenta que cuando digo “SUSE” en realidad me estoy refiriendo a dos distribuciones de GNU/Linux muy distintas: SUSE Linux Enterprise por un lado, y openSUSE por otro. Esta última al ser un proyecto comunitario es bastante independiente a la hora de abordar esta situación. Así que la descripción que sigue debe ser considerada como el actual Plan de Registro para SUSE Linux Enterprise, pero en lo referido a openSUSE, puede considerarse sólo una propuesta más para tener en cuenta por la comunidad.

Tal como se explicó en el anterior artículo, UEFI y el Arranque Seguro es una tecnología útil, Que hace que sea más difícil para los atacantes el esconder malware en la cadena de arranque.

Y al mismo tiempo, por la manera en que está basada esta operación – estableciendo una sólo raíz de confianza – entra de lleno en conflicto con el desarrollo del Código Abierto, que debe ser independiente y distribuido para que funcione.

Además de todo lo anterior, hay algunas lagunas en lo referente a licencias y cuestiones legales, para quien quiera utilizar este Arranque Seguro en forma por defecto. La clausula GPL v3 es una de esas, otra es la redacción del contrato SysDev de Microsoft que se opone a la firma de la GPLv3 binarios con un certificado proporcionado por Microsoft.

En la actualidad, los primeros sistemas de escritorio se están lanzando con soporte de arranque seguro, y esperamos que se vaya introduciendo en todos los PC nuevos vendidos hacia el final de este año. Y por supuesto, esperamos que todos los que se envía con llave de Microsoft Exchange ( Microsoft’s Key Exchange Key - KEK) instalado por defecto.

Algunas de estas nuevas máquinas, lo más probable es que tengan una manera de deshabilitar de una manera fácil el arranque seguro; en otras esto puede que también sea posible pero de una manera un poco más complicada; y en otras será totalmente imposible sin perder otras funcionalidades.

El soporte a UEFI y el Arranque Seguro esencialmente se reduce a tener un gestor de arranque con una firma digital que el firmware reconoce como una llave de confianza, y con el fin de ser útil a los clientes empresariales, esa llave será de confianza a priori por el firmware, sin necesidad de ninguna intervención o manipulación manual.

Hay 2 maneras de conseguir esto. Una es tabajar junto con los vendedores de hardware, para que avalen una llave SUSE con la que podremos firmar el cargador de arranque. Y la otra forma sería a través del programa de certificación del logo de Windows, para tener una certificación en el proceso de arranque y que Microsoft reconozca nuestra llave (por ejemplo tendría que estar firmada con su KEK). Actualmente estamos evaluando las dos propuestas, y puede que se realicen las 2 en paralelo.

En la capa de implementación, tenemos la intención de utilizar un primer cargador (N.del T: se podría traducir como “cargador cuña”) desarrollado originalmente por Fedora – es una solución inteligente que evita varios problemas legales desagradables, y simplifica considerablemente el paso de certificación / firma. El trabajo de este primer cargador es cargar grub2 y verificarlo, esta versión de grub2 a su vez, cargaría núcleos únicamente firmados por una llave de SUSE. Estamos estudiando la posibilidad de ofrecer esta funcionalidad con SLE11 SP3 para nuevas instalaciones con la presencia de UEFI Arranque Seguro.

Ahora quizás este claro porque esta primera medida ofrece el nivel de seguridad que promete UEFI Arranque Seguro, hay una cadena irrompible de verificación, asegurándose de que sólo código confiable y firmado será ejecutado antes de dar el control al kernel del sistema operativo.

Lo que no está tan claro es cómo los desarrolladores de Código libre y abierto van a hacer funcionar sus propios kernels, o cargadores de arranque para este caso, o cómo se va a cumplir la licencia GPL v3. En próximas series de estos blogs, explicaremos cómo pretendemos proporcionar esto con nuestra propia versión de un primer cargador de arranque o “cargador cuña”.

Espero que te sea útil. Si tienes sugerencias de una mejor traducción o alguna errata no dudes en comentarlo para corregirlo. openSUSE es una comunidad abierta, sientete libre de expresar tu punto de vista a la comunidad y dar tu opinión.

NOTA:

———————————————

SUSE – openSUSE ante UEFI y el Arranque Seguro

Quizás hayas oído hablar de UEFI y Secure Boot (Arranque seguro), una nueva medida de seguridad que puede hacer que los fabricantes de PC’s decidan qué puedes y qué no puedes instalar en tu PC.

La comunidad GNU/Linux sale al quite para que los usuarios no pirdan la libertad de elección.

Como seguro ya has leído, Windows 8 (siguiendo con sus políticas de monopolio encubierto) quiere imponer a los fabricantes de PC’s que si estos quieren incluir el logo de compatibilidad con este sistema operativo, deben incluir una medida de seguridad llamada Secure Boot, lo que podríamos traducir por: Arranque Seguro. Aunque existen muchas sospechas que lo que quieren hacer es un “Arranque restringido”. Las medidas de seguridad siempre son buenas, pero en este caso, en nombre de la seguridad quieren que los usuarios perdamos parte de nuestra libertad.

Y uno de los colectivos afectados somos los usuarios de GNU/Linux. De plantearse la medida como quieren no podrás instalar nada en tu PC, que los fabricantes de PC’s no hayan aceptado antes! Es decir que puedes desarrollar un nuevo sistema operativo, pero como este no está “firmado” por los fabricantes, entonces no es reconocido, y basándose en ese arranque seguro, no te dejarían instalarlo en PC’s que tengan implementado esta medida.

La Fundación de Software Libre, ya empezó una campaña (pincha aqui para verla) para que los usuarios firmáramos, y pidiéramos que ese arranque seguro no merme las libertades de los usuarios, independientemente del sistema operativo que utilizásemos.

Las diversas comunidades de GNU/Linux han dado su opinión para que ésta medida sea implementada de la mejor manera, no de forma unilateral por parte de Windows, y con el consenso de todos los usuarios. No estamos en contra de la medida de seguridad, estamos en contra de los modos y maneras en las que se quiere implementar.

La comunidad de SUSE y openSUSE, tambien ha dado su opinión, por medio de artículos. En estos artículos se expone qué es esta medidad y que piensa la comunidad de SUSE al respecto. La comunidad de openSUSE es independiente de aquella, pero quizás sus puntos de vista son interesantes y merecen tenerse en cuenta.

Olaf Kirch ha escrito un primer artículo en el que se detalla, y se hace un primer acercamiento a UEFI y el Secure Boot o Arranque Seguro. Puedes ver el original en inglés en el siguiente enlace: www.suse.com/blogs/uefi-secure-boot-overview/ o puedes leer a continuación la traducción que he hecho. Gracias a Olaf por permitirme publicar la traducción, a él pertenece el mérito del trabajo.

En el caso en que todavía no sepas a que se refieren estos dos términos: UEFI es “Unified Extensible Firmware Interface” y “Secure Boot” es uno de las más recientes características que está causando un gran revuelo dentro del mundo del código libre y abierto.

En SUSE hemos estado observando UEFI y Secure boot durante mucho tiempo y de forma minuciosa.

Por un lado, estamos de acuerdo en que el cierre de algunas de las lagunas en el proceso de arranque es una meta que vale la pena. Durante décadas, hemos aceptado que este proceso ha sido una de los puntos débiles que no pueden ser solucionados fácilmente sin un cambio profundo en la BIOS. Ahora que este cambio está llegando, estamos dispuestos a aceptarlo. Y también estamos contentos de ver que un cambio mucho mayor está sucediendo como parte de esto, que es el establecimiento de UEFI como estandar en el firmware de todas las plataformas x86.

Por otro lado, como una compañía de Linux, estamos viendo un buen número de comentarios que nos están causando dolores de cabeza, a los que queríamos resolver antes de expresar públicamente nuestros planes en este sentido.

A fin de explicar nuestras inquietudes, vamos a echar un breve vistazo a lo que realmente hace de arranque seguro, en pocas palabras. En el mundo de UEFI, asegurar el proceso de arranque significa establecer una cadena de confianza. La “plataforma” es la raíz de esta cadena de confianza, me inclino a pensar que es la placa base y la memoria firmware de la ROM que esté montada. O, dicho de forma ligeramente diferente, es el proveedor de hardware, y la cadena de confianza que se deriva de proveedor de hardware serían los fabricantes de componentes, los proveedores de sistemas operativos, etc

Desde un punto de vista legal, esta confianza se establece por una gran cantidad de contratos y papeleo legal. En el nivel de bits y bytes, esta confianza se expresa a través de la criptografía de clave pública. El fabricante pone una clave en la ROM, lo que representa la raíz de confianza. Las relaciones de confianza con los proveedores de sistemas operativos y otros se documenta mediante la firma de las claves de la plataforma ROM.

Finalmente, la seguridad se establece al exigir que ningún código será ejecutado por el firmware a menos que haya sido firmado por una de estas claves “de confianza” – ya sea un sistema operativo del gestor de arranque, algún controlador que se encuentra en la ROM de alguna tarjeta PCI Express, o ya sea una actualización del firmware de la misma.

Por supuesto, se podría hacer de esto una cadena muy larga, al exigir que todo lo se ejecute alguna vez en tu máquina este firmado digitalmente: el propio sistema operativo, los módulos que carga, los binarios y las bibliotecas compartidas que carga, todos los scripts ejecutados por cualquier intérprete al azar, e incluso los comandos que se teclea en una sesión de shell.

Así que, es obvio, que esta candena tiene que parar en alguna parte; y en la especificación UEFI, ese punto se alcanza cuando el firmware pasa el control al sistema operativo. Básicamente, si deseas utilizar el arranque seguro, necesitas tener el cargador del sistema operativo firmado con una clave de confianza por el firmware, y necesitas que el gestor de arranque compruebe que carga un kernel en el que se puede confiar.

Es cierto que se estan pasando muchos detalles por alto, pero no son de relevancia para esta discusión.

El quid de la cuestión es que esto entra en conflicto con la forma en que la comunidad de código libre y abierto se viene desarrollando desde hace varias décadas. El movimiento de Código abierto comenzó como un acto de emancipación de los proveedores de sistemas operativos de la época. El Código abierto y libre fue y todavía es y trata de la libertad, no de un modo dogmático, pero sí en realidad en un sentido muy práctico. La comunidad de Linux está donde está hoy porque la gente podía empezar su propia distribución, construir su propio cargador de arranque y el kernel, y formar una comunidad. Se está prosperando la forma en que está prosperando hoy en día porque hay miles de personas en todo el mundo que la desarrollan su núcleo o kernel diez veces al día para corregir errores, para agregar mejoras, o para ejecutar su instrumento de prueba en la última serie de cambios. Y sólo se nutrirá de esta manera si seguimos así.

Desde este punto de vista, Secure Boot está muy en desacuerdo con el modelo de desarrollo de GNU/Linux.

Sólo para que conste, no creo que esto sea una conspiración o una tentativa siniestra para matar a Linux. Eso no va a suceder. Pero al mismo tiempo este Secure Boot puede ser una mejora significativa para muchos, que sin duda crea obstáculos para la comunidad Linux.

Por supuesto, la certificación del logotipo de Windows 8 requiere que los proveedores de BIOS pueda permitir a los usuarios desactivar el arranque seguro en las plataformas x86, y tenemos esperanza de que todos los proveedores de BIOS realmente pongan en práctica esto de una manera que funcione bien para los desarrolladores de Linux. Pero lo ideal sería que, los desarrolladores de Linux no debe ser obligados a quitar una característica de seguridad como esta para ejecutar su sistema operativo.

Por lo tanto, en los últimos meses, nuestras preguntas cuando hemos tratado el tema del “arranque seguro” han sido, ¿cómo podemos hacer que funcione para nuestros clientes, y cómo podemos conciliar las exigencias de arranque seguro con las necesidades de la comunidad Linux.

Tenemos la intención de continuar con esta serie de entradas de blog en breve con una visión general de la forma en que la intención de apoyar de arranque seguro en SUSE Linux Enterprise, y las soluciones que proponemos a la comunidad openSUSE.

He tratado de hacer la traducción lo mejor posible, aunque todo es susceptible de mejora, si crees que hay algo que se pueda mejorar o alguna errata por favor coméntalo y se corregirá si es necesario. Tengo intención de traducir los otros 2 artículos escritos al respecto, si estás interesado permanece a la “escucha”!!

NOTA:

————————————-

Noticias openSUSE. Continuando el proyecto

He traducido este artículo desde la página oficial de openSUSE, publicado el 24/2/2012. Si quieres ver el original pincha este enlace: http://news.opensuse.org/2012/02/24/continue-the-opensuse-weekly-news sobre la continuidad del proyecto del diario samanal de noticias de openSUSE.

 

” El último presidente del equipo de noticias semanales de openSUSE Sascha Manns ha renunciado a finales de 2011 a su cargo después de tres años de trabajo. Ahora que hemos recibido muchas preguntas sobre la continuidad del proyecto de noticias semanales sobre openSUSE. Hemos pensado escribir un poco sobre este tema.

¿Por qué necesitamos este diario semanal sobre noticias de openSUSE?

El equipo de noticias semanales de openSUSE publicó su primer número en la semana del 19/11/2007. El objetivo de este equipo era reflejar qué había pasado en la última semana. Nadie puede leer todas las noticias y blogs sobre un tema en especial. Es cierto que las alertas de Google ayudan un poco en esta tarea, pero no puede ser la solución. Así que el equipo trató de recopilar las noticias de manera colaborativa. También tratan de organizar las noticias de manera que sea fácil para el lector enterarse de esas informaciones especiales. Otro motivo por el que es necesario este diario semanal de openSUSE, es para mantener el nombre de openSUSE vivo entre los usuarios, y también en Google

¿Po qué este diario ha tenido un parón? 

El anterior líder Sascha Manns ya no dispone de tanto tiempo como antes. Y desgraciadamnete no hemos encontrado alguien nuevo para este puesto.

¿Cual es la tarea como presidente? 

La dura realidad es que esto conlleva mucha dedicación y tiempo. Una de las primeras tareas es crear una solución para recopilar noticias. Se pueden recopilar de muchas fuentes: Lectores RSS, vía Twitter, por Facebbok, o mediante Google+. Es una tarea diaria leer todo esto y decidir qué es lo importante para los lectores y ponerlo en el proyecto semanal. También puede ser bueno estar conectado al canal IRC, y subscrito en listas de correo  donde otra gente puede aportar noticias interesantes.

Un día a la semana es el día “freeze”  (congelado). En ese día ninguna noticia más entrará al boletín semanal. Entonces se procede a preparar, y corregir lo recopilado. Si todo está bien entonces puede ser publicado. El antiguo líder publicaba un recordatorio el miércoles en algunas listas de correo como por ejemplo opensuse-kde,- gnome, -proyectos, -marketing. Despues de publicado se creaba un nuevo post en news.opensuse.org y en la lista de correo opensuse-announce explicando cómo conseguir el boletin semanal

¿Cómo crearlo?

El equipo de noticias semanales de openSUSE probó dos maneras diferentes de realizarlo y publicarlo: Mediante la Wiki y Docbook.

- La manera de hacerlo por la wiki era como puede ver en este ejemplo: http://en.opensuse.org/Archive:Weekly_news_134 Cada semana se añadía una nueva plantilla y se rellenaba con los contenidos de la semana. Todo el que quisiera tenía las fuentes para crear una versión propia y traducida. El punto a favor es que cualquiera lo podía leer on-line.

- La segunda forma y la actual, era crear la fuente en un Docbook. Docbook es un lenguaje basado en XML para describir un contenido. El contenido será convertido mediante XSLT para convertirse en un archivo como PDF o EPUB. También el Docbook puede producirse en una versión HTML, pero esto no fue utilizado por el equipo.

Ambos medios tienen sus pros y sus contras. Por ejemplo: el lenguaje Wiki es más fácil de aprender que el Docbook, por contra con el Docbook brinda más formatos de salida. Ambos métodos tienen una función de historial para corregir errores. La wiki ya tiene una solución integrada y el Docbook utiliza SVN para eso.

¿Escoger un método?

El nuevo director de noticias debe crear un equipo, y elegir que opción tomar. Debe tener en cuenta que es lo que prefieren tanto el equipo como los lectores

Traduciendo

Anteriormente teníamos equipos locales en cada país que se encargaban de traducir las noticias a 13 idiomas. Y esperamos que sigamos teniéndolos de nuevo ! :-)

El principal problema está en que el boletín está en inglés. Así que despues de traducir algún artículo el lector pinchará sobre un enlace que le llevará a un artículo escrito en inglés y no en su lengua nativa. así que una de las cosas más importantes para el equipo local de noticias, es recopilar y preparar sus propios enlaces en sus recpectivas lenguas maternas, y añadirlos al boletín en inglés.

Cómo escribir un artículo

Un artículo tiene un título, un enlace y un cuerpo de la noticia. El título tiene el siguiente formato: “Nombre_del_autor/Dónde_se_publicó: título”. El Nombre_del_autor es fácil de localizar. Dónde_se_publicó se refiere en que página o sitio se publicó el artículo original (por ejemplo: linux.com, unixmen.com, victorhckinthefreeworld.wordpress.com …) Y comprobar dónde se publicó el artículo originalmente, ya que a veces algunos artículos son publicaciones, de otros y estos son los originales. Y el contenido es claro. Puedes utilizar para el cuerpo del artículo tus propias palabras, redactándolo o puedes copiar y pegar el primer y el segundo párrafo. Si haces esto debes incluir las comillas “” antes y despues del texto indicando que estas citando literalmente una fuente.

Próximos pasos

¿Que es lo que hay que hacer ahora? Si estás interesado en ser el nuevo director manda un mail a esta dirección: opensuse-marketing@opensuse.org. Si se encuentra un nuevo director se pueden seguir estos pasos: formar un equipo. En este paso el nuevo director puede hacer un llamamiento a la participación en la lista de correo de marketing, y quien quiera y le guste trabajar con noticias puede ayudarle.

El nuevo equipo tiene que decidir junto con los lectores que opción elegir: Wiki o Docbook.

Entonces ya podrán empezar. despues de un tiempo se puede pensar en (re)crear equipos locales para el equipo de noticias semanales de openSUSE

We’re a legion, we’re many, we’re expecting you ;-)

Si está interesado en contribuir con la distro, y tienes curiosidad y ganas de participar en un proyecto como este no lo dudes ponte en contacto y prueba suerte.

Enlaces de interés:

Portal wiki de noticias (en inglés) | http://en.opensuse.org/Portal:Weekly_news

Equipo de noticias (en inglés) | http://en.opensuse.org/openSUSE:News_team

—————————————————————————–

 

Fondos de escritorio para openSUSE

De vez en cuando me da por crear nuevos fondos de escritorio, o wallpapers para openSUSE, y compartirlos con todos en suse-art.

En este caso he hecho un nuevo fondo, del que he hecho 3 versiones. uno con texto en inglés, otro en español y otro sin texto. En resolución de 1680×1050.

Se me ocurrieron hace tiempo, y poco a poco han ido tomando forma. De libre uso y disfrute, aunque se agradece el reconocimiento. Realizados con GIMP y un poco con INKSCAPE. Espero que os gusten.

Pincha sobre las  imágenes para descargar:

Bet on openSUSE

 

Apuesta por openSUSE

 

Sin texto

 

Pincha sobre las imágenes para descargar desde suse-art. Si quieres ver todos mis aportes pincha en este enlace: Victorhck_en_suse-art

 —————————————————————————

 

SuSE cumple 20 años!!

 

De mano de Karggest  conozco la noticia, traigo aqui un extracto traducido. Si quieres ver la noticia oficial, pincha este enlace: http://www.suse.com/company/press/2012/2/suse-celebrates-20th-anniversary-in-2012.html

“Los orígenes de SUSE se remontan a septiembre de 1992 cuando 3 estudiantes universitarios de matemáticas y un recién graduado ingeniero de software (Roland Dyroff, Thomas Fehr, Burchard Steinbild, and Hubert Mantel) formaron una compañía para desarrollar softwarey funcionar como un grupo asesor de Unix. Viendo el potencial que tenía el entonces incipiente Linux se ofrecen al apoyo y desarrollo de este. Se elige el nombre de “SuSE” como acrónimo de un término alemán que significa desarrollo de software y sistemas “Software und Systementwicklung” . El nombre fue acortándose con el tiempo quedando en SUSE.

SUSE tiene una larga trayectoria de servicio contribución a un gran número de proyectos de código abierto. Uno de los mayores y más influyentes es el proyecto de openSUSE ®, que fue establecido en 2005. El software de soporte comercial de Linux de SUSE siempre se había desarrollado y distribuido bajo los modelos de código abierto y licencias, pero openSUSE abrió aún más los procesos de desarrollo, permitiendo a los programadores y usuarios para probar y ayudar a contribuir al desarrollo de su comunidad y las versiones comerciales. “

Buena noticia para los usuarios de Linux, que SUSE siga siendo un referente en desarrollo de software basado en Linux con sus productos para servidores, que sigue estanto entre los más utilizados. Esperemos que el proyecto siga adelante durante muchos más años! Mas info en wikipedia.

Puedes saber más de los orígenes de historia pinchando aqui: http://www.suse.com/company/history/ 

Have a lot of fun!!!

——————————————————————————-