Esta petición se origina debido a los recortes en Ciencía y Tecnología de los nuevos presupuestos. Si ya de por sí el presupuesto dedicado a estas áreas no era muy esperanzador, con los nuevos recortes la apuesta de este nuevo gobierno por la Ciencía y Tecnología es de risa.

Sin embargo, en las asignaciones a la Iglesia Católica, que sí dispone de dicha casilla en la Declaración de la Renta, no ha habido ningún recorte. Y creo que en las ayudas a los jetas de los “artistas” los recortes han sido demasiado pequeños.

En estos días en los que nos movemos la Ciencía y Tecnología es esencial y es el factor diferencial que puede hacernos crecer en muchos sentidos y no sólo en el Económico, que es lo único en lo que piensan estos gloriosos Gobernantes que hemos tenido desde tiempos inmemoriables hasta nuestros días.

Hoy en día muchos investigadores se están yendo al extranjero a continuar o iniciar su carrera investigadora y con ello produciendo riqueza en sus países de adopción. Van a cotizar allí, invertir su dinero allí. Ni que decir tiene que sus logros beneficiarán, en todos los sentidos, a sus países de acogida. Pero lo mejor es que toda esta riqueza se la hemos pagado todos los Españoles con nuestros impuestos. Una inversión con una rentabilidad impresionante, para ellos.

En España, a pesar de que no se publicita mucho, existen muy buenos investigadores y eminencias en su campo como por ejemplo Juan Ignacio Cirac Sasturain Físico Español que desde 2001 es Director de la División Teórica del Instituto Max-Planck de Óptica Cuántica (Max-Planck-Institut für Quantenoptik). El día que se logre fabricar ordenadores cuánticos que sean utilizables en el día a día el mundo tal y como lo conocemos cambiará debido a las posibilidades que ofrecen estos ordenadores. El ejemplo más conocido sobre esto es que los métodos criptográficos actuales ya no serán válidos y todas las comunicaciones, la gran mayoría, seguras que se realizan hoy en día lo hacen utilizando estos métodos que no serán efectivos con los ordenadores cuánticos.

Las empresas que logren patentarlos tendrán una ventaja y posibilidades de negocio inimaginables. ¿Habrá alguna empresa Española entre ellas?

Y ya sin ser tan materialista, pensemos en la investigación que permita luchar contra el SIDA, Cancer, Alzeimer, Parkinson, enfermedades degenerativas como ELA (enfermedad que padece Stephen Hawking, entre otros) o enfermedades que padece tan poca población que no es rentable invertir en su investigación y en las que es fundamental la inversión de los Estados ya que las empresas privadas apenas destinan fondos debido a su poca rentabilidad.

A raíz de la petición de la casilla en la Declaración de la Renta de ResistenciaNumantina se ha creado una campaña en actuable.es recogiendo firmas para la petición de dicha casilla.

Si estás de acuerdo con esta iniciativa, publicita esta iniciativa de recogida de firmas y el post que lo solicita  a través de las redes sociales a las que tienes acceso, envíalo por correo a tus contactos, etc

La investigación en Ciencía y Tecnología nos beneficia a todos no sólo por los avances científicos, si no que también puede ayudar a crear puestos de trabajo.

Después de este discurso autojustificante vamos a recopilar diferentes inocentadas publicadas en los medios y relacionadas con la ciencia y tecnología. Seguramente me deje algunas. Si algún lector conoce alguna interesante y me la envía la pondré con gusto.

Inocentadas sobre Ciencía

En Gaussianos publican un artículo de investigación sobre la controversia en la autoría del Cálculo Diferencial sugeriendo que Sir Isaac Newton y Gottfried Leibniz podrían haberse puesto de acuerdo en crear la controversia sobre la creación del Cálculo Diferencial.

El Tito Eliatron nos informa que una de las mejores mentes que jamás ha habitado este planeta, Grigori Perelman, vuelve a los círculos científicos y académicos (Ojalá no fuera una inocentada). No contento con esta inocentada vuelve a la carga publicando que ha demostrado que la Hipótesis de Riemann es falsa y sus resultados van a se publicados en una revista de prestigio. Información sobre la Hipótesis de Riemann.

En Francisthemulenews publican una noticia sobre un Español que inauguró la prestigiosa Universidad de Standford. El personaje existió, pero no era Español. Esta me la tragué a base de bien, las cosas como son.

En Xatakaciencia nos informan de que científicos japoneses ha realizado la primera autopsia a un extraterrestre. Y sin lugar a dudas, para mí por lo menos, también publican la que ha sido la mejor inocentada que he visto publicada en muchísimo tiempo: Encuentran un acelerador de partículas bajo la Línea 6 del metro de Madrid. A esta línea se la conoce como “Línea Circular”, chapeau.

Inocentadas sobre Tecnología

En Xatakandroid publican una inocentada sobre unas gafas interactivas desarrolladas en España. Lo que no nos aclaran es si Alain Affeflou ha deslocalizado en España sus fabricas para hacer gafas en España.

En ADSL Zone nos informaban de que en nochevieja los operadores de Telefonía iban a desactivar Whatsapp para evitar el colapso de la red. También hacen una recopilación de inocentadas tecnológicas.

En Amazings directamente publican un post con las inocentadas que publicaron.

Recordemos el problema de la cuadratura del círculo:

“Dado un círculo de radio R se trata de encontrar un cuadrado que tenga el mismo área que el círculo anterior, utilizando sólo regla y compás“

Este problema geométrico se considera irresolubre.Investigadores de la Universidad de FrUtah han presentado un resultado, de forma preliminar, que resuelve este problema en espacios topológicos de dimensión mayor o igual que tres.

Al igual que ocurrió con la demostración del Ultimo Teorema de Fermat se han encontrado unos errores que afectan al caso de espacios topológicos de dimensión dos. En estos espacios es donde se incluye el clásico problema de la cuadratura del círculo. Los investigadores creen poder salvar este último escollo y se encuentran trabajando para solucionarlo.

Dado que la demostración es muy teórica vamos a explicar de forma sencilla la aproximación seguida por estos investigadores particularizando el caso a espacios topológicos de dimensión tres, .

Por simplificar haremos referencia a superficies diferenciables y variedades topológicas indistintamente.

En primer lugar estos investigadores han demostrado que dada una superfice diferenciable cualquiera de clase existe otra de clase y diferenciable a trozos equivalente. Siempre para dimensiones .

Es decir que para se tiene una correspondecia biunívoca entre las superficies diferenciables de clase y las de clase diferenciables a trozos.

Para que la “demostración” sea más facilmente entendible, para el lector no ducho en Matemáticas avanzadas, particularizaremos al caso de transformar una esfera en un cubo.

Dada una esfera existe un único cubo equivalente (mismo volumén) en el espacio topológico de la misma dimensión:

Observar que, al ser la correspondencia biunívoca, si se logra demostrar para el caso no sólo será posible cuadrar el círculo si no que además será posible circuncidar el cuadrado. Algo que sin duda será del agrado de toda la comunidad Matemática Judía. Bueno, en realidad de toda la comunidad Judía.

Para demostrar la la correspondencia biunívoca explicaremos el ejemplo escogido.

Basicamente se ha demostrado que es posible encontrar una única solución a:

pudiendo transformar la esfera anterior de radio al cubo de lado utilizando unicamente regla y compás.

El éxito de esta demostración ha sido que, al contrario de los anteriores ataques al problema, ahora se ha sido respetuoso con las Leyes de la Termodinámica.

Esta vez se han tenido en cuenta las Leyes de la Termodinámica, en concreto la “Primera Ley de la Termondinámica” o “Principio de Conservación de la Energía“.

Los ataques al problema de la cuadratura del círculo se basaban en el principo de “Las gallinas que entran por las que salen“, es decir no tenían en cuenta que para realizar la transformación del circulo en un cuadrado del mismo área es necesario invertir energía. “La regla y el compás no se manejan solos y en nuestra Universidad siempre hemos sido muy respetuosos con las Leyes de la Termodinámica” puntualizaron los investigadores.

Es decir la energía necesaria para la transformación viene dada por:

Al lector quiza le choque la ecuación anterior y piense ¿Pero entonces los volúmenes no serán iguales?

En la ecuación anterior es correcta la observación, pero recordemos que estamos trabajando con superficies diferenciables.

Si definimos la variable:

y definimos:

Se demuestra que el volumen de ambas superficies es igual en el límite.

Para la demostración se define la siguiente sucesión de funciones:

haciendo un cambio de variable:

tenemos que cuando  se tiene que . Esto nos permite utilizar el Teorema de Convergencia Dominada (Lebesgue):

Donde es el volumen del cubo de lado .

La demostración es mucho más detallada ya que interconecta diferentes ramas de la Matemática y aquí la hemos resumido para esbozar a grandes rasgos los fundamentos matemáticos en los que se sustenta.

Los investigadores realizarón experimentos prácticos para comprobar los resultados teóricos resultando muy esperanzadores al lograr “cuadrar” dos melocotones.

Sin embargo, cuando procedieron a intentar cuadrar un círculo de radio se encontraron desconcertados ya que no consiguieron un cuadrado de área , como cabría esperar. El resultado fue una magdalena de calorías. El resultado fue desconcertante ya que no sólo no se obtuvo un cuadrado del área deseada si no que se obtuvo una superficie perteneciente a un espacio topológico de dimensión superior. El que el invariante matemático, área, se conservará aunque fuera en forma de calorías es esperanzador. Se espera que sea un error menor que sólo afecta al caso . La comunidad científica está espectante esperando a que se solucione este error y los resultados sean publicados en el arXiv de forma definitiva. Los investigadores, no obstante, ya han anunciado que una vez resuelvan el problema para el caso estudiarán en profundidad el caso de la magdalena ya que quizá se pueda validar un método científico para la producción de magdalenas, y quiza de otros productos de repostería, de una forma rápida, sencilla y respetuosa con el medio ambiente. Esta afirmación no ha sentado muy bien en el gremio de reposteros que han amenazado con llevar a los investigadores a los tribunales acusados de competencia desleal e intrusismo. La noticia, de confirmarse su aplicación en repostería, del posible nombramiento de estos investigadores para el Premio Nobel de Repostería no ha hecho más que empeorar el malestar del gremio repostero.

La vulnerabilidad descubierta implica que es cuatro veces más fácil encontrar la clave del algoritmo de lo que se suponía. Esto significa que en lugar de utilizar un algoritmo AES de 128 bits en realidad estamos utilizando un algoritmo AES de 126 bits, reducir en 2 bits la longitud de la clave que estemos utilizando.

En la práctica esta vulnerabilidad no afecta ya que lo único que supone es que se reduce el espacio de claves pero aún así harían falta todavía billones de años para poder romper una clave de AES-128.

AES es un estándar de criptografía simétrica publicado por el NIST. Dicho organismo publicó una serie de requisitos para establecer un estándar de criptografía dentro de la Administración y la industria Norteamericana dado que el anterior estándar DES estaba ya caduco y obsoleto desde hacía ya algún tiempo y de hecho practicamente no se utilizaba utilizandose en su lugar variantes como Triple DES.

Se impusieron varias condiciones que deberían cumplir los algoritmos propuestos para ser adoptados como dicho estándar:

1. Debían ser algoritmos simétricos de cifrado en bloque y no sujetos a patentes para poder ser libremente implementados tanto vía software como vía hardware y así de esta manera facilitar su adopción.
2. El algoritmo debía permitir claves de tamaño variable, es decir que con el paso del tiempo se pudiera seguir utilizando el mismo algoritmo pero únicamente cambiando la longitud de la clave para ofrecer mayor seguridad a medida que aumenta la potencia del hardware y/o los ataques teóricos que reducen los espacios de claves.
3. Debería ser facilmente implementable no sólo en software si no que también en hardware.
4. El algoritmo debería ser sometido a escrutinio público.

Los motivos por los que se exigian estos requerimientos venían dados por la experiencia con el anterior estándar, el DES:

1. El no estar sujetos a patentes permitiría una adopción fácil, desde el punto de vista económico, ya que no encarecería su implantación.
2. El estándar anterior utilizaba claves de 64 bits, 56 bits efectivos ya que utilizaba un octeto para paridad, pero no permitía el uso del algoritmo con claves mayores. Con lo cual cuando la potencia de computo fue creciendo llegó un momento en el que no era seguro y fue necesario recurrir a variantes como el Triple DES. La implementación de estas variantes no era sencilla, sobre todo en la codificaciones hardware, ya que requería un uso diferente del algoritmo. La adopción de un algoritmo que permitiera el uso de claves de longitud variable solucionaba este problema.
3. El hecho de ser facilmente implementable tanto en software como en hardware facilitaría tanto la adopción como las posibles evoluciones, de haberlas.
4. Uno de los “problemas” que había con el anterior estándar es que se basaba en un algoritmo llamado Lucifer con claves de 128 bits. DES utilizaba una longitud de clave que era la mitad que la utilizada en Lucifer y esto fue debido a “sugerencias” de la NSA. Esta reducción del tamaño de la clave resultó sospechosa a la comunidad internacional que pensaba que o bien había una puerta trasera en DES o bien que la NSA estaba en condiciones de romper en un futuro no muy lejano el algoritmo. Si a este hecho le sumamos que el diseño de DES no fue público y que existían elementos en el diseño de las redes de Feistel que no se entendian muy bien dio lugar a las sospechas sobre que la NSA era capaz de romper este algoritmo. A pesar de este hecho nunca fue demostrado un ataque efectivo distinto de la fuerza bruta. Por este motivo se quería que el nuevo estándar fuera sometido a escrutinio público desde el primer momento.

Al concurso se presentaron varios algoritmos y al final el algoritmo que se adoptó como estándar fue Rijndael desarrollado por dos estudiantes, Joan Daemen y Vincent Rijmen, de la Katholieke Universiteit Leuven.

A pesar de que se habla indistintamente de AES y Rijndael como si fueran el mismo algoritmo existen una serie de diferencias. Rijndael permite un mayor rango en el tamaño de bloque que se procesa y también permite un mayor rango en el tamaño de las claves que utiliza el algoritmo. Mientras que AES encripta en bloques de tamaño fijo de 128 bits y utiliza claves de tamaño 128, 192 o 256 bits Rijndael puede utilizar claves de longitud variable entre 128 y 256 bits siempre que sean multiplos de 32 bits y se puede adaptar a diferentes tamaño de bloque.

Fuimos el primer partner al que se le dió formación sobre el producto cuando aún era una versión beta.

Vino un francés a darnos el curso y lo que ví me encantó. Por aquel momento llevaba ya como un año dando el coñazo en mi empresa con la virtualización en Linux. No por que la cosiderará lista para entornos en producción, de una forma generalista, si no por conocer el producto y posicionarse en el mercado y ser uno de los referentes o el referente para cuando estuviera lista para una adopción de forma generalizada.

Muchos hablarán maravillas de la virtualización en Linux que si el antiguo UML (User Mode Linux), Xen o KVM. La virtualización lleva funcionando en Linux mucho tiempo pero la tecnología no está lo sufucientemente madura como para ser considerada en serio de forma generalizada.

Me explico, hay clientes para los que a día de hoy los sistemas de virtualización basados en tecnologías OpenSource (no confundir con gratis) les pueden servir y les dan garantías para su negocio pero hay otros muchos en los que no.

Hoy por hoy y le pese a quien le pese (y yo soy uno de ellos) VMware es el Rey en virtualización (Intel y AMD) y está a años luz de cualquier competidor desde el punto de vista tecnológico.

El producto de Red Hat es, para mi, la segunda opción más fiable. Me han hablado maravillas del producto comercial de Xen pero como no lo he podido evaluar no voy a dar mi opinión sobre él basandome en leer PDFs como hacen los gurús de hoy en día.

El producto de Red Hat, RHEV, está lo suficientemente maduro como para encajar en los planes de muchas empresas que no necesitan toda la potencia que VMware te ofrece y obviamente pagas.

Las mayores pegas que le encuentro al sistema de Red Hat son:

• No hay posibilidad de hacer Snapshots en caliente. Esto es un gran inconveniente ya que a la hora de hacer actualizaciones nos permite una marcha atrás rápida, comoda y flexible. Sin tener que apagar la máquina.

• No hay posibilidad de añadir hardware virtual en caliente. A la hora de añadir discos en caliente para gestionar el crecimiento de nuestros servidores si tenemos que apagar la máquina deberemos pedir una ventana con el consiguiente impacto.

• Para montar discos en cluster solo se puede hacer por iSCSI. Esto saldrá subsanado en la versión 3.0, o quizá en la 2.3 (ahora estamos en la 2.2).

• Virtualización de Solaris x86. Desde mi punto de vista creo que Red Hat ha decidido no incluir esto debido a la gran campaña que tiene para migrar entornos Solaris a Red Hat. Creo que es un error ya que tengo algún cliente, GRAN CLIENTE, que no se decidió en su momento a considerar a Red Hat como una alternativa a VMware por este motivo decidiendose a favor de Oracle VM. Pero gracias a las políticas de Oracle y a una demo del que escribe estas líneas han vuelto a considerarlo.

• No es posible, de una forma sencilla, el instalar el manager en una VM dentro del entorno RHEV. Esto puede parecer una tontería pero en la vida real es una practica habitual, mientras que en VMware es una tontería en RHEV no es tan sencillo y es necesario montarla mediante libvirt.

Es cierto que estos temas se van a solucionar en las proximas versiones.

¿Cual es la política por la que se decide en que feature se trabaja para añadirla? Pues es muy sencillo y lógico, la demanda de sus clientes. Obviamente si hay más clientes que demandan la característica A en lugar de la B Red Hat va a poner más carne en el asador para implementar A.

Hay que darle tiempo a Red Hat para que se ponga a nivel en características y fiabilidad con VMware. Hay que reconocer que la velocidad que lleva Red Hat a la hora de mejorar su producto es espectacular y no sólo por añadir características rápido, si no por hacerlo con bastante madurez y robustez. Desde luego que hay bugs, uno me lo he comido, pero el trabajo que están haciendo es sensacional.

Voy a comentar los problemas que me he encontrado en esta migración:

1. Después de migrar una máquina, la primera tardó 7 horas en migrar … Me encuentro con un error al realizar la importación “No puede importar la máquina debido a que el tipo de discos no está soportado”. Bueno pues esto es un bug. La solución era modificar el fichero OVF (Open Virtualization Format) y cambiar los discos de tipo Sparse a Preallocated. No me funcionó.
2. Decido probar con una máquina windows más pequeña. Después de convertirla a kvm me dió un fallo debido a que no encontraba unos paquetes. Revisando la documentación me encontré que era necesario instalar unos paquetes adicionales. Esta información se encontraba en la documentación de RHEL 6 y no del hypervisor. Uno de esos paquetes no está disponible para RHEL 5 ¿adivinad que SO tenía la máquina que había montado para la migraciones? Con lo cual me tocó montar un RHEL6.
3. Realizando la conversión con una RHEL6 me encontré el mismo problema de la importación de discos. Salvo que ahora el “workaround” si funcionó.
4. La importación de los windows fue bien, salvo que no se conservó la configuración de red y tuve que replicarla a mano.
5. Con los linux fue todo bien, salvo que no se el motivo por el cual RHEV le asignó una MAC a la VM pero no la cambió en el SO y me toco hacerlo a mano.

La batalla ahora mismo no se encuentra en tener un producto de virtualización, de hecho pocas novedades van a haber que sean revolucionarias en este campo. La batalla está en todos los productos que hay alrededor del software de virtualización. Desde hace tiempo VMware tiene una suite de productos que complementan su principal producto, vSphere, como:

• Site Recovery Manager, un software que realiza un BRS de un CPD a otro. Ahora mismo estoy trabajando en un proyecto para implementar esto con dos CPDs a 12.000 km.
• Capacity Planner, te realiza un estudio de tu infraestructura física y te determina el número de servidores y características que necesitas para consolidarlo.
• Charge Back, te permite conocer los costes de tu entorno para poder facturar a departamentos, … Ahora con el Cloud Computing esto es esencial.
• Capacity IQ, te permite tener estimaciones de cuando te vas a quedar sin recursos.

Además de esto VMware está trabajando en otra serie de productos entorno a entornos de virtualización que como no estoy seguro de si puedo mentarlos (confidencialidad) no voy a hacerlo. Es en este campo donde ahora mismo está la batalla y no tenemos alternativas Open Source. No se si Red Hat u alguna otra compañia está trabajando en este área. De no ser así volveremos a perder la batalla, que no la guerra. Pero siendo positivo tendremos que decir que sólo tendremos a un paso de distancia a las alternativas no Open Source.

Una exposición itinerante desarrollada por el Instituto Matemático de Oberwolfach para el Año de las Matemáticas en Alemania (2008). Su propósito es ofrecer visualizaciones, instalaciones interactivas, realidades virtuales, objetos 3D, … También se incide, de una manera atractiva y pedagógica, en algunos aspectos teóricos de su fundamentación en la geometría algebraica y la teoría de singularidades. ¡Es una experiencia científica muy especial!Es una experiencia recomendable, especialmente para todos aquellos que no tienen una base muy sólida en matemáticas y que simplifican las matemáticas a sumar, restar, multiplicar y dividir. Todos aquellos que piensan que las matemáticas sólo son útiles para contar podrán observar una pequeña parte de su potencial. Podrán ver formas facilmente reconocibles de la naturaleza expresadas como una ecuación algebraica. De ese albebra que los atormentaba en el colegio/instituto y al que no veían utilizar en la vida real.

La exposición consta de una serie de “posters” con una imagen de un objeto generado mediante una ecuación matemática y una explicación. Ademas también hay una serie de ordenadores donde los asisentes pueden experimentar con las ecuaciones.

Las fotos no son gran cosa ya que no tenía mucho tiempo y la iluminación no era muy buena debido a los reflejos.

Zitrus (Limón)

Esto no es un limón

Zeck (Peonza)

La ecuación, un nombre inequívoco

Kolibri (Colibrí)

Diálogo entre Geometría y Álgebra

Helix (Hélice)

Más finas que una ponpa de jabón

Nepali (Nepalí)

¿Caben en una bola o se extienden hasta el infinito?

Himmel und Hölle (Comecocos)

Creando nuevas formas

Calyx (Cálix)

Elevarse a dimensiones superiores

Dullo (Manzana)

Fenómenos singulares en la naturaleza

Distel (Destello)

¿Formas caprichosas?

La séptica de Labs

Las Matemáticas son retos

Schneeflocke (Copo de nieve)

Las ecuaciones pueden ser bellas

A pesar de que resulta muy curiosa y vistosa desde mi punto de vista no hubiera estado de mas haber incluido el conjunto de Mandelbrot, conjuntos de Julia o sistemas de función iterada (IFS) dentro de la exposición ya que encajaría dentro de la misma, según mi humilde opinión.

]]> http://www.divulgaciones.net/2011/02/18/imaginary/feed/ 0 http://www.divulgaciones.net/2010/05/21/la-infinitud-de-los-numeros-primos/ http://www.divulgaciones.net/2010/05/21/la-infinitud-de-los-numeros-primos/#comments Fri, 21 May 2010 16:06:39 +0000 jadebustos http://www.divulgaciones.net/?p=237 Los números primos son considerados como los ladrillos de la aritmética. Desde siempre han cautivado a los matemáticos. Son unos entes muy simples de definir y conocidos por todos los infantes desde su más tierna infancia.

A pesar de esto muy pocos conocen el potencial que tienen y la complejidad que hay detrás de ellos.

Muchos y muy grandes matemáticos se han dedicado a su estudio con mayores o menores avances. Pero ninguno de ellos ha sido capaz de sacar una ley general para calcular números primos o conocer su distribución.

Aunque el problema de la distribución de los números primos parezca un problema teoríco sin ninguna aplicación o utilidad práctica, la realidad es muy distinta.Los números primos permiten la construcción de estructuras algebraicas (cuerpos finitos) y gracias a esta estructuras se pueden utilizar:

• Códigos correctores de errores, que posibilitan la corrección de errores en las transmisiones electrónicas de datos (móviles, internet, …), lecturas de datos (CD, DVD, Mini-Disc, …)
• Criptografía, protección de la información.

Euclides fue el primer matemático conocido que dió la primera demostración formal sobre la infinitud de los números primos,  publicada en el libro IX de los Elementos.

Como curiosidad diremos que El Libro de los Elementos de Euclides es la segunda obra que a más idiomas se ha traducido después de La Biblia y no El Quijote.

Alla por el 300 a.C. en Grecia Euclides publicó la siguiente demostración:

Euclides supuso que había sólo un número finito de números primos.

Sean todos los números primos donde .

Construyó el siguiente número .

Es obvio que es distinto de cero y además , es decir no es un número primo, entonces es divisible por algún con .

Ahora bien:

Dado que no es divisible por ninguno de los primos, es decir no es un número compuesto, se deduce que es un número primo.

Habíamos supuesto que teníamos un número finito, completamente identificado de números primos y hemos hayado otro número primo distinto.  Entonces se demuestra que los números primos son infinitos. Si incluimos este núevo número primo en el conjunto de números primos podemos construir el siguiente número:

y siguiendo el razonamiento anterior llegaremos a que es otro número primo y así ad infinitum.

Esta demostración es de una simplicidad y elegancia increibles, maxime teniendo en cuenta de cuando es. No sólo es simple y elegante ya que además es constructiva al enseñar un método de construcción de números primos.

Aún me acuerdo el primer día en la facultad en clase de Algebra cuando el profesor dijo que a él no se le hubiera ocurrido esta demostración a lo que “alguien” le salió del alma “joder ni a mi tampoco y no lo voy comentando“.

Esta demostración no nos ayuda a comprender la problematica de la distribución de los números primos.

Un número es primo sí y sólo sí es divisible por el mismo y la unidad. Es decir no puede ser divisible por ningún número entero menor que él (con la excepción de la unidad). Esta caracterización la podemos refinar diciendo que un número es primo sí y sólo sí no es divisible por ningún número primo menor que él. Y la podemos refinar aún más diciendo que es primo sí y sólo sí no es divisible por ningún número primo menor o igual que .

Cuanto mayor es más condiciones le imponemos para ser un número primo. Una mayor cantidad de números por los que no puede ser divisible.

Ahora ya empezamos a intuir la dificultad del problema.

Pero es posible dar una visión más en profundidad de las dificultades que entraña la distribución de los números primos.

Fijemos un número tal que . Consideremos el siguiente conjunto:

El cardinal del conjunto (número de elementos):

Ninguno de los elementos de es primo ya que:

con

Hemos encontrado un método para construir lagunas de números enteros consecutivos en los que no hay ningún número primo. Este método es válido para cualquier número natural .

Supongamos que (número aproximado de átomos en el universo) entonces podemos no sólo afirmar que existen números compuestos consecutivos si no que además sabemos cuales son. Con esta prueba tan demoledora tenderíamos a pensar que detrás de esta laguna no existen más números primos, es decir existe un número finito de números primos. Craso error. Da igual el tamaño de la laguna que construyamos, siempre habrá números primos por detrás de ella.

Esta nueva gama de servidores permite un aumento de escalabilidad en el crecimiento debido a las posibilidades de ampliación de memoria y desvinculando esta de los procesadores para aumentar el rendimiento de los sistemas y reducir el consumo energético.

Esta nueva arquitectura se suministrará en formatos:

• Servidor enrackable
• Sistemas Blade

de dos y cuatro procesadores INTEL Nehalem de 8 núcleos.

También se incluirán discos de estado sólido para mejorar el rendimiento I/O y consumo energético. Esto me parece más marketing que otra cosa. Es cierto que el rendimiento de los discos de estado sólido es mayor, tanto que no se suelen utilizar, de momento, en arquitecturas SAN.

Los discos de estado sólido dan más I/O de la que se puede utilizar con el HW de hoy en día, aunque se está trabajando para que su adopción en estos sistemas sea generalizada en lugar de utilizar discos de fibra, SAS o SATA y poder aprovechar todas las ventajas que ofrecen los de estado sólido (en los sistemas profesionales de almacenamiento).

Para mí es marketing ya que en la mayoría de las arquitecturas los discos locales, cuando los hay, se utilizan para el SO y los datos se almacenan en una red SAN/NAS (fibra, iSCSI, …) y por este motivo la reducción de costes y aumento de rendimiento hay que matizarla un poquito. También hay que señalar que la configuración típica de SO es dos discos en RAID 1 para tener redundancia, con lo cual sigue siendo necesario tener el doble de espacio.

VMware ya se ha certificado para poder aprovechar esta nueva arquitectura lo que hará que el ratio de consolidación con esta tecnología sea aún mayor generando un mayor ahorro en costes y simplicidad en los CPDs, únido al aumento de rendimiento.

Todo aquel acostumbrado a trabajar en entornos virtualizados sabe, o al menos debería, que el recurso más crítico es la memoria. El parámetro que te indica hasta donde puedes crecer y cuánto es la memoria, nunca la capacidad de procesamiento (salvo un pesimo diseño de arquitectura).

Hace una semana fue necesaria una intervención en un cliente en horas de producción debido a un upgrade. Debido a esto se balancean VMs de un servidor ESX a otro para proceder a actualizar el ESX libre. Como resultado de esto se tenía que al terminar de balancear las VMs había servidores ESX con 15,5 GB de memoria ocupada de los 16 GB disponibles. Al cabo de unos minutos el consumo de memoria se había reducido hasta los 13 GB llegando en algunos casos a 11 GB.

Esto es debido a que el ESX detecta el consumo excesivo de memoria y empieza a utilizar sus algoritmos para el manejo de memoria (I love these guys!!!):

• Transparent Page Sharing
• Ballooning

Estos algoritmos se encargan de reducir el consumo de memoria y “cortarle los vuelos” a las VMs para que no desperdicien la memoria.

VMware es sin duda el Rey en la virtualización en entornos x86 y el resto de aspirantes, ya que desde el punto de vista tecnológico no se les puede llamar competidores, estan a años luz todavía aunque se van acercando cada vez más pero en el tema de la gestión de memoria es donde VMware no admite, de momento, comparaciones.

• Sólo es divisible por el mismo y la unidad.

No se le considera un número primo.

El no considerarse como un número primo no es un capricho y, como todo en matemáticas, tiene su razón de ser.

El Teorema fundamental de la Aritmética nos dice que todo “número entero positivo admite una descomposición única en factores primos salvo el orden“.

Es decir:

Supongamos por un momento que el número 1 fuera un número primo entonces tendríamos:

Lo que nos daría no una si no varias descomposiciones diferentes  contradiciendo el Teorema fundamental de la Aritmetica.

Aunque pueda parecer un “apaño” para justificar un Teorema el hecho es que este “apaño” es necesario debido a la definición de número primo que incluye la divisibilidad de un número por el número 1. Esta condición de divisibilidad es obvia ya que cualquier número entero siempre será divisible por la unidad y esta ambiguedad es la que origina esta “pequeña contradicción” que hay que superar.

En este artículo pretendo mostrar como instalar Red Hat Linux para PowerPC en un cliente virtual en pSeries haciendo boot from SAN.

Dado que lo que voy a describir no es una configuración estándar que se vea todos los días, empezaremos con un poco de literatura.

Para los que lo desconozcan pSeries es la “gama media” de servidores de IBM considerando:

• Gama baja: servidores x86. (xSeries)
• Gama alta: mainframe. (zSeries)

Este hardware utiliza procesadores Power, antiguamente RS6000. El sistema operativo “nativo” para esta arquitectura es AIX (UNIX de IBM).

Existía una categoría intermedia denominada iSeries (AS/400 o S/390). Estos “servidores” eran mainframes “de juguete”. Hoy en día IBM ha incluido esta gama de servidores dentro de pSeries y en ellos también corre Linux.

En este hardware es posible hacer particiones y particionar el “hierro” repartiendo todos sus recursos entre las diferentes particiones lógicas o LPARes. En realidad este esquema se podría considerar como una especie de virtualización. En esta arquitectura los LPAR acceden directamente al hardware asignado.

IBM dió un paso de tuerca más y mediante Virtual I/O Server (VIO Server) permite crear clientes virtuales que acceden al hardware/recursos asignados por el VIO Server. En esta arquitectura los clientes virtuales acceden al hardware asignado a través del VIO Server.

El VIO Server es un servidor AIX al que se le asignan todos los recursos del pSeries que queramos asignar a los clientes virtuales y será el encargado de asignárselo a los clientes virtuales.

En un diseño típico instalaremos dos VIO Servers para evitar que el VIO Server sea un punto único de fallo y si cae nos tire todos los clientes virtuales.

A la hora de crear un cliente virtual deberemos crear la máquina virtual mediante el HMC (Hardware Management Console). EL HMC es un servidor xSeries con un Linux personalizado que gestiona los recursos del pSeries.

Le ofrecemos el disco de sistema operativo, a través de un VIO Server y realizamos la instalación.

Se recomienda hacer la instalación en un disco en la SAN en lugar de en los discos internos. El motivo es muy sencillo, la SAN nos ofrece un gran rendimiento y tolerancia a fallos. Si utilizamos discos internos deberemos, si queremos tener redundancia, crear un RAID 1.

Basándome en mi experiencia, podemos encontrarnos con problemas si se degrada el RAID:

• Caerse el cliente virtual.
• Caerse el VIO Server que le ofrece el disco.

Los problemas se manifiestan cuándo se intenta volver a sincronizar el RAID para tener redundancia.

Por este motivo es recomendable utilizar discos en la SAN.

Una vez realizada la instalación en un disco en la SAN deberemos ofrecerle el disco de sistema operativo por el otro VIO Server y configurar el multipath.

¿Pero qué es el multipath? Al ofrecerle el disco de sistema operativo, usualmente /dev/sda, por el otro VIO Server tendremos que escanear el bus SCSI y a partir de ese momento el sistema operativo verá “otro” disco, /dev/sdb. En realidad es el mismo disco visto por dos caminos, uno por VIO Server.

Si un VIO Server cae o hay algún problema con el acceso a ese disco por el camino que controla un VIO Server el cliente virtual dejará de ver el disco y si lo está utilizando por ese camino tendremos problemas.

La solución es configurar el multipathing para que el sistema operativo sea consciente de que /dev/sda y /dev/sdb son el mismo disco. Cuándo falle un camino lo detectará el sistema operativo y conmutará de forma transparente al otro camino.

Existen dos formas de configurar el multipathing en Linux, sin software de terceros:

• mdadm.
• device mapper.

Veremos como hacerlo con mdadm. Dejaremos device mapper para otro artículo.

Utilizando mdadm para configurar multipathing en un disco en la SAN será necesario que en la instalación del sistema operativo no utilicemos LVM. Sí lo utilizamos no nos dejará configurar el multipathing en el volume group  donde resida el sistema operativo al estar activo y siendo utilizado.

Un esquema de particionado típico en esta arquitectura es:

• /dev/sda1 (/deb/sdb1) PPC PReP boot partition donde se instala el cargador de arranque YABOOT. En iSeries se incluye el kernel para el arranque en esta partición.
• /dev/sda2 (/dev/sdb2) partición /boot donde residirá el kernel para el arranque en pSeries. En iSeries no será necesaria.
• /dev/sda3 (/dev/sdb3) swap.
• /dev/sda5 (/dev/sdb5) partición /. Por simplificar instalaremos todo en /.

Editamos el fichero /etc/modprobe.con y añadimos la línea:

alias multipath multipath

De esta forma nos aseguramos de cargar el módulo de multipath en el arranque. Posteriormente tendremos que regenerar el initrd del sistema.

Ahora tendremos que crear los dispositivos multipath:

mdadm -C /dev/md0 -n 2 -l mp /dev/sdb2 /dev/sdc2
mdadm -C /dev/md1 -n 2 -l mp /dev/sdb3 /dev/sdc3
mdadm -C /dev/md2 -n 2 -l mp /dev/sdb5 /dev/sdc5

Una vez generados los dispositvos de multipath tendremos que modificar el fichero /etc/fstab para utilizar los dispositivos /dev/md? en lugar de los /dev/sda?.

En los sistemas Power, pSeries, el cargador de arranque no es ni GRUB ni LiLO, es YABOOT. El fichero de configuración del cargador de arranque se encuentra en  /etc/yaboot.conf y será algo similar a esto:

# yaboot.conf generated by anaconda

boot=/dev/sda1
init-message=Welcome to Red Hat Enterprise Linux AS!\nHit <TAB> for boot options

partition=2
timeout=20
install=/usr/lib/yaboot/yaboot
delay=5
nonvram

image=/vmlinuz-2.6.9-34.EL
label=linux
read-only
initrd=/initrd-2.6.9-34.EL.img
append=”console=hvc0 rhgb quiet root=LABEL=/”

Tendremos que realizar los siguientes cambios:

• Añadir el multipath para la partición PPC PReP boot. Ello lo haremos incluyendo /dev/sdb1 en el apartado boot del fichero anterior. No confundir con la partición /boot.
• Es recomendable el regenerar el initrd con otro nombre para tener la configuración original y poder arrancar la máquina en caso de problemas “just in case“.
• Por defecto Red Hat monta las particiones por etiqueta para evitar que si cambia de nombre un dispositivo se pueda seguir montando sin problemas. Dado que hemos creado un multipathing tendremos tres dispositivos, que en realidad son el mismo, con la misma etiqueta: /dev/sda5, /dev/sdb5 y /dev/md2. Si seguimos utilizando el montaje por etiquetas es posible que no se utilice /dev/md2 que es el dispositivo que proporciona multipath. Por lo tanto en la claúsula append quitaremos el parámetro root=LABEL=/ y habrá que indicarle a YABOOT la partición root del sistema.

El fichero /etc/yaboot.conf quedaría:

# yaboot.conf generated by anaconda

boot=/dev/sda1 /dev/sdb1
init-message=Welcome to Red Hat Enterprise Linux AS!\nHit <TAB> for boot options

partition=2
timeout=20
install=/usr/lib/yaboot/yaboot
delay=5
nonvram
image=/vmlinuz-2.6.9-34.EL
label=linux
read-only
root=/dev/md2
initrd=/initrd-2.6.9-34.EL-mp.img
append=”console=hvc0 rhgb quiet”

Una vez realizado todo esto deberemos regenerar el initrd:

mkinitrd /boot/initrd-2.6.9-34.EL-mp.img 2.6.9-34.EL

Dependiendo de la versión de linux que estemos instalando, kernel, quizá necesitemos utilizar mkinitramfs para regenerar el initrd.

Después de esto podremos reiniciar el sistema utilizando multipathing y haciendo boot desde la SAN.