sábado, abril 27, 2013

Arrancar con USB con grub2

Tengo un portátil con unos añitos.

Este no incorpora la opción de arrancar desde usb en el setup.

Esto es un inconveniente para hacer instalaciones de linux.


Con grub1 se podía hacer de la siguiente forma http://joseluisestebanaparicio.blogspot.com.es/search?q=grub


Pero ahora tenemos grub2 y es ligeramente diferente


En la pantalla de grub, pulsamos la tecla 'c' para entrar en el modo comandos.

Ahora podemos ejecutar 'ls' para ver los discos y particiones que tenemos disponibles.


hd0 será el disco duro principal


Si está enchufado y detecta el usb, seguramente esté en hd1


La primera partición tiene el número 1. OJO, el primer disco es el 0, la primera partición es la 1. OJO también, porque esto es un cambio en grub2 respecto a grub1 (antes lógicamente la primera partición era la 0)

Cambiamos al disco que creemos tiene el arranque de linux con...


set root=(hd1,1)  

Este comando nos lleva al disco 2 partición 1


para ver que tenemos podemos escribir

find /

y pulsar la tecla tabulador.


Si todo está ok, sólo quedan los comandos...


chainloader +1
boot




lunes, marzo 25, 2013

La puerta perfecta

Es el año 2040 (por no irnos muy lejos).
Tenemos una base lunar permanente.

Allí llegan regularmente naves desde la tierra con materiales, trabajadores y turistas. Las mismas naves llevan materiales de minería a la tierra.

Cada vez que llega una nave, se abre una enorme puerta para que esta pueda pasar  y claro, se escucha siempre...  "esa puerta, que hay corriente"

Como te puedes imaginar, se produce una despresurización brutal, mayor a abrir una puerta de un avión a 10.000 de altura. Eso es incómodo, además de carísimo, hay que volver a rellenar el gran habitáculo con aire respirable a una presión confortable.


Así que se trata de inventar "la puerta". No es una puerta cualquiera, es una puerta especial.

Tiene que cumplir los siguientes requisitos...


1.- Nunca debe estar abierta, no puede abrirse, siempre, siempre está cerrada.
2.- No debe tener ningún poro, debe conseguir un cierre hermético perfecto
3.- Que las naves puedan atravesarla
4.- Que sea barata
5.- Que se pueda construir de verdad (no valen las de "star wars")


Pues esa puerta ya está inventada. "La puerta cerrada", "la puerta perfecta" o símplemente LA PUERTA, ya está inventada.


Para el que no la conozca, aquí hay un par de urls, con detalles, historia, planos, etc... que aproveche


martes, marzo 19, 2013

PI, infinitos dígitos para decirlo todo, todo


Hoy, leyendo en un blog de ciencia, contaban la sensacionalista historia de lo que está codificado en el número PI.

La primera vez que leí esto fue hace mucho en un libro de Martin Gardner.
Pero es una historia clásica, que aparece también en el libro Contact de Carl Sagan.


La historia es la siguiente.


PI es un número irracional (además es transcendente, pero este último curioso capricho no es relevante ahora).

La característica de un número irracional, es que no puede ser representado como una fracción de dos números enteros por muy grandes que elijas estos.

Y eso, provoca que ese número, tenga infinitos decimales que no se repiten periódicamente.

"...si la secuencia en verdad no tiene fin (y no se repite cíclicamente, añado yo) esto implica que cualquier número imaginable, e incluso cualquier combinación de ellos, aparecerá más tarde o más temprano en alguna parte de la secuencia de Pi. O de cualquier otro número irracional"

Parece lógico e intuitivo, pero... no es tan sencillo.

Y basándonos en el teorema demostrado de los infinitos monos nos induce a pensar...

"Todos los libros escritos y por escribir, verdaderos y falsos, con errores y sin ellos; incluyendo el detallado manual de cómo descodificarlos, el catálogo completo (el verdadero y millones de ellos falsos), y la cuidadosa y convincente refutación de todos (incluyendo el auténtico). Todas las cartas de amor jamás escritas, las todavía por escribir, las que se pensaron y nunca llegaron al papel; todos los pensamientos expresados con palabras en todos los idiomas, muertos, vivos o todavía no nacidos… Todo está en algún rincón de Pi"

Es tentador y bonito, además de sensacionalista, que eso mola.

Es más, creo que se cumple para PI, el número e, la raíz cuadrada de dos, la razón áurea y cualquier número irracional no construido con mala leche. ¿Pero quien demuestra que PI o e u otro número irracional no tiene mala leche? ¿Es acaso posible demostrar si PI, e y amigos tienen o no mala leche?

¿Cómo construir un número irracional con mala leche? Entendiendo por mala leche que no cumpla que más tarde o temprano encontraremos cualquier secuencia numérica.


Antes de nada ¿Cómo codificar con dígitos de PI textos?

Podríamos agrupar los números de dos en dos dígitos decimales y asignar a cada valor una letra. Sustitución directa y sencilla.

Los ordenadores sólo trabajan con números. Continuamente utilizan tablas de conversión número a letras para mostrar texto. Pueden utilizar la vieja tabla de conversión ASCII, o el más moderno UTF8, o UNICODE16 o... lo que sea.

¿Dependerá del modelo de sustitución que elijamos para que sea cierto que en PI está todo lo escrito en la historia, y lo que se escribirá?
Aquí está la clave. Parece que no. El que elijas un modelo u otro de sustitución (e incluso una estrategia diferente pero completa de codificación que no sea la sustitución) parece que no influye. El resultado estará más lejos o más cerca.


Vuelvo con los números irracionales con mala leche. Construyamos uno con mala leche.
Obtengo todos los decimales de PI, pero cada vez que aparece un 8, me lo salto. El número resultante será un número irracional (bastante artificial y puñetero, pero irracional total).

Si utilizamos base 127 y tabla de conversión ASCII, y decidimos construir un número irracional con los decimales de PI pero saltándonos todos los dígitos 65 y 95 que corresponden a la 'A' y la 'a', difícilmente vas a escribir algo mínimamente complejo. Y seguro que un libro de Shakespeare tiene unas cuantas aes.


Claro, si elegimos otro modelo de codificación, reaparecerán todos los libros y cartas, pero... eso es menos sensacional. Si elijo el modelo de cifrado para conseguir un resultado... pierde toda la gracia.

Es como preguntar por el siguiente número de una serie. Vale cualquiera, siempre y cuando tenga libertad para elegir la función generadora. Es decir, dado un número finito de elementos de una serie cualquiera, existen infinitas funciones generadoras para la misma.


Pero estas dificultades ocurren con números irracionales con mala leche.

¿Es PI un número con mala leche?
¿Es el número e un número con mala leche?
¿Es la raíz cuadrada de dos un número con mala leche?


Estoy convencido de que no tienen mala leche, no es improbable, ni muy improbable, ni remotamente improblable, es muchísimo más improbable que todo eso. ¿Pero alguien que lo demuestre con una seguridad del 100%?
¿Es acaso demostrable?


lunes, septiembre 24, 2012

Eliminar y recuperar del arranque un servicio ubuntu

Caso real:

sudo apt-get install qpidd


Lo instala y configura correctamente.

Pero además, añade al arranque una instancia de qpidd con una configuración por defecto.

Como no quiero dicha configuración por defecto, para eliminarla...



sudo update-rc.d -f qpidd remove



Para reinstalar el arranque de dicho servicio...


sudo update-rc.d -f qpidd defaults



Para parar arrancar o reiniciar un servicio...


sudo invoke-rc.d qpidd start
sudo invoke-rc.d qpidd stop
sudo invoke-rc.d qpidd restart

Teclas Linux

¿Reiniciar ordenadamente con el sistema colgado?


alt + sysrq +s    sync data
alt + sysrq + u   mount as read only
alt + sysrq + b   reboot


¿Matar las X cuando está desabilitado control-alt-backspace?


kill X  right-alt + sysrq + k

martes, septiembre 04, 2012

Apple e itunes


Sorprendente.

Cuando aceptas los términos de la tienda de Apple, aceptas que todo lo que compres por dicha tienda, cuando te mueras, es para Apple. Libros, música, programas...

Pero ya tenemos un héroe dispuesto a luchar por la justicia contra los villanos, y es... como no... Bruce Willins

http://alt1040.com/2012/09/bruce-willis-y-el-derecho-a-ceder-su-biblioteca-de-itunes-a-sus-hijos




El actor parece estar considerando la idea de llevar a Apple a los tribunales. La razón, la defensa de Willis a dejar su gran colección digital descargada en iTunes a su familia una vez haya muerto. Una batalla contra el gigante sobre quién es el dueño de las canciones descargadas en iTunes.
Y es que aunque muchos no lo sepan, según los términos del servicio que aceptamos, una vez hayamos muerto la colección pasa a ser de nuevo propiedad de Apple. Una situación que sitúa la compra en un “préstamo” bajo licencia.
Esta situación ahora descubierta por el famoso actor le ha llevado a considerar tomar acciones legales contra el gigante tecnológico, ya que pretende ceder toda su colección a sus hijas. Una batalla que de convertirse en realidad se presenta ciertamente difícil para Willis.
La idea de Willis es clara. De la misma forma que su colección de música física puede ser cedida a los miembros de su familia, la gran colección de música digital que ha comprado en iTunes también debería ser posible legítimamente.
Sin embargo los términos de servicio en iTunes son claros. La música que compramos y descargamos no puede ser pasada a otro persona. Es nuestra mientras estemos en vida, luego su dueño será otra vez Apple.
No sólo eso, en los términos se indica la posibilidad de congelar una cuenta de iTunes si se cree que se está pasando la música a otras personas, algo parecido a lo que ocurre con las descargas de libros digitales como el Kindle de Amazon.
Willis parece tener dos vías para comenzar esta batalla. Por un lado, enfrentarse el sólo contra Apple (y las dificultades de llevar a cabo una acción legal de este calibre), tratando de establecer una validez en sus hijos sobre la titularidad de su música descargada.
Por otro, unirse y apoyar las acciones legales en curso en cinco estados de Estados Unidos para ofrecer derechos a los usuarios que compran música digital a que puedan hacer con ella lo que quieran.
De tener éxito, la lucha de Willis no sólo beneficiaría a sus hijos, sino a millones de personas que han comprado música en el popular servicio de Apple.

Detector molecular comprado en méjico


http://en.wikipedia.org/wiki/GT200





Un aparato avanzado para detectar drogas por un mecanismo físico misterioso.

Sin pilas, ni chips, un alambre y dentro del corazón, una hoja enrollada.

Sólo funciona si te lo crees, como la gran mayoría de los bulos.

tipado dinámico vs estático y LISP

http://ib-krajewski.blogspot.com.es/2012/09/static-vs-dynamic-lisp-experiences.html




Monday, 3 September 2012

Static vs Dynamic - the LISP experiences


Maybe you happen to remember my recent post about static and dynamic languages with the main assertion that the type information is maybe superfluous but helpful for documentation and refactoring. You might be tempted to retort: docs & refactoring are for sissies, you wimp! But wait a moment, who are the most notorious hackers out there? You are right, the LISP hackers. From them you'd expect the most ruthless hacks and also despising of the programming aids mere mortals are using. At least as far as the programming folklore is concerned.

But if you a little bit look closer... Heres the answer* given to a simple question "What you dislike the most about Lisp?":
I must say that the lack of static typing really gets in the way on larger projects. Being able to confidently change datatypes and function signatures, knowing that the compiler will point out most inconsistencies that you introduce, is something that I've really come to appreciate after working with Rust and Haskell. Test coverage helps, of course, but I'm not a very diligent test writer, and tend to feel that type signatures are easier to maintain than an exhaustive test suite.
Surprise, surprise, basically he's reiterating my simple argument: why should we give up something that can help us, i.e. automatic checking if all the interfaces are used correctly?

And for the seconds, some  "opinion as a result of ... programming in Lisp in a production environment on non-trivial code"**:
Right off, I can say that the biggest, most glaring thing that causes problems is the lack of static typing. It happens that when the compiler is unable to detect these issues, the end user is left to find them. This can be very potentially damaging to companies. And it is more prominent when you have 100k lines of code, not all of which one can be familiar with.
Lisp takes some steps to help solve these issues. SBCL has very good type inference capabilities, and can warn or error at compile time with type issues. Additionally, Common Lisp allows one to declare and assert argument types, but there’s no guarantee this information can be used. 
And what's SBCL? Let's cite from it's homepage: "Steel Bank Common Lisp (SBCL) is a high performance Common Lisp compiler". What? Even more surprises! Compilers, type inference, assertions? Ok, looks like (at least some of) the LISP hackers came to appreciate the static typing. Who would have thought it?

viernes, agosto 24, 2012

Cuando no se usan esas chulísimas metodologías de desarrollo...





Según el propio Linus, el kernel se está complicando cada vez más. En mi opinión como ingeniero informático de primera esto se debe a los siguientes motivos:
  • No se están siguiendo las mejores prácticas de gestión de proyectos establecidas por el SWEBOK [wikipedia.org], con etapas claramente diferenciadas: definición de requisitos, análisis, diseño, construcción, pruebas, etc.
  • ¡No hay ni un solo diagrama UML!
  • Se están empeñando en usar C frente a lenguajes de mayor nivel como Modula-2, respaldado por todas las universidades del mundo.
  • Entre los colaboradores del kernel hay mucho intrusismo, gente de FP, sin título, físicos, matemáticos, industriales. Ello irremediablemente conduce a un código con errores, que no ha sido firmado ni respaldado por el correspondiente colegio de informáticos.
  • Falta un SDK para Windows, cuando en la Universidad casi todas las aulas son Windows.
  • Falta claramente un análisis de riesgos, y una metodología más orientada hacia la verificación de sistemas, lo que conduciría al aseguramiento de la calidad y a la reducción del Time To Market. Esto os lo puede corroborar cualquier consultor de McKinsey o Accenture.

jueves, agosto 23, 2012

Opinión Alan Cox sobre threads

Mi opinión es muy próxima a la suya, pero él es Alan Cox, yo soy... nadie en comparación


A Computer is a state machine. Threads are for people who can't program state machines.
Alan Cox

Y no es el único gurú que tiene opiniones parecidas...


If you think you need threads then your processes are too fat 
Rob Pike



Esto no significa que se esté en contra del proceso simultáneo. En absoluto.

Ni siquiera del proceso simultáneo apropiativo.

Y obviamente no del proceso simultáneo distribuido.


¡¡¡AUPA   EEEEERRRRLAAAAAANNNNNNGGGG!!!


Paralelismo sí, pero en condiciones


¿Porqué podemos querer ejecución paralela?


¿Para que las cosas vayan más rápido?
Rara vez. Y en esos casos, estas limitado al número de procesadores reales.

¿Para hacer la lógica del programa más sencilla?
Entonces Alan Cox tiene razón.

¿Por seguridad?
Entonces las hebras es lo peor, porque te aumenta la inseguridad.


Si lo queremos para escalar horizontalmente (distribuyendo), para simplificar la lógica del programa (en algunos casos de forma radical), o por seguridad, lo mejor son procesos.


Una buena opción es separarlos con un middleware, más que una opción, es una obligación.


Pero podemos combinar esto, con un sistema orientado a procesos de forma que maximicemos al máximo los beneficios de ejecutar en paralelo, CON PROCESOS.



¡¡¡AUPA   EEEEERRRRLAAAAAANNNNNNGGGG!!!



¿Para qué no queremos threads?

O dicho de otra forma, dónde los threads aportan poco.


Para que el usuario no se quede esperando mientras ha pedido algo.



¿Funcionará más rápido?  NO
¿Funcionará más seguro? NO
¿Tendrá una lógica más sencilla? NO

¿entonces, "paqué"?



Yo era uno de esos ingenuos que pensaba que las hebras eran una chulada, la solución a los males del mundo. Y los semáforos, regiones críticas y mutex, nuestra gran ayuda. Eso sí, muy lejos del alto nivel del "rendezvous" de ADA.

Pero la vida real me puso en su sitio. Todos esos mecanismos para evitar problemas con la concurrencia y memoria compartida, destruían la concurrencia al mismo tiempo que complican enormemente el código haciéndolo inmantenible e intocable.

Los errores de la concurrencia apropiativa con memoria compartida, son difíciles de encontrar y pueden pasar en cualquier momento.

En este sentido, estoy compartiendo la opinión de Joe Amstrong y Martin Ordesky (citada en sus respectivos libros de sus respectivos lenguajes de programación)