Democracia representativa dinámica: una idea en bruto

12 12 2012
Se suele decir que la democracia (haciendo alusión a la democracia representativa) es el menos malo de los sistemas políticos que ha puesto a prueba la humanidad. La situación actual ha evidenciado que lo de "menos malo", ha pasado de ser un apelativo cariñoso, a un inmerecido piropo. El desgaste de este sistema es cada día más evidente. Y la reciente demostración que ha llevado a cabo el PP de que es posible ganar unas elecciones diciendo "blanco", para luego gobernar haciendo "negro", es un achaque más de esta moribunda democracia.

Desde hace algún tiempo existen propuestas como E-Democracy, que pretenden el uso de las tecnologías de la información para implementar alguna variante de democracia directa. Pero lo cierto es que, al menos hasta el momento, ninguna de ellas ha tenido un grado de apoyo relevante. Las razones pueden ser variadas, pero muchos, entre los que me incluyo, vemos poco factible la idea de que los ciudadanos tengamos que votar todas y cada una de las propuestas llevadas a los distintos órganos, tal y como proponen las variantes más radicales de este sistema.

Por otra parte, si apostamos por una alternativa parcial, en el que sólo se someta a votación una parte de las deciciones, tendríamos un doble problema: mantener vivo el actual modelo de democracia representativa, y a su vez buscar un sistema para determinar qué se vota de forma directa, y qué se delega en los representantes. Este modelo, a primera vista, introduce más problemas de los que resuelve.

Pero, tal vez, en un punto intermedio entre ambos sistemas exista una solución razonable. Tomemos la idea de que existe la tecnología para celebrar elecciones de forma rápida, segura y barata. Esto elimina la barrera que impide incrementar la frecuencia de las mismas. ¿Y si en lugar de para votar las propuestas, usamos este sistema para subscribir o retirar nuestro apoyo a un candidato siempre que queramos?

Esta idea es similar, aunque más conservadora y simple que la democracia líquida. Analicémosla con más detalle:

Prerrequisitos

En el modelo actual, los partidos políticos tienen demasiado peso. Practican el corporativismo sin complejos, tienen intereses propios ajenos a su militancia, defienden a sus protegidos y vigilan que sus nuevos candidatos sean afines a línea marcada por la dirección del partido. En este momento, es posible dirigir el país sin pisar el Congreso, desde un despacho de las calles Génova o Ferraz.

Para que la democracia representativa dinámica sea efectiva, es necesario que los ciudadanos podamos subscribir directamente el apoyo a un candidato, y que éste responda directamente antes sus representados. Y cuando digo responda, lo digo de forma literal. Para poder preservar el apoyo, se verá obligado a prestar atención a la gente. Habrá quien se sirva de las herramientas tradicionales y tenga un equipo de comunicación y los medios de masas a su servicio. Pero también habrá quien pueda lograr un seguimiento, si no igual, al menos sí suficiente, atendiendo directamente las redes sociales y el correo electrónico. Y con el tiempo, la ventaja se situará del lado de éste último.

A su vez, para la elección de los representantes nacionales, es necesario reemplazar la Ley D'Hont por un sistema de estimación directa con circunscripción única.


Características generales del modelo

- Los ciudadanos tendremos a la posibilidad de entregar nuestro a apoyo a un número determinado de representantes, tanto a nivel local, como autonómico y estatal. Podremos verificar y modificar la distribución de dichos apoyos en cualquier momento, haciendo uso de un sistema electrónico.

- Los candidatos registrados, podrán hacer un seguimiento diario del número de apoyos adscritos, así como de la evolución de los mismo.

- Cada cierto intervalo de tiempo (tal vez entre tres y seis meses) se congelarán los apoyos durante uno o más días, y se reconstituirán los órganos de representación de acuerdo a la disposición de dichos apoyos.

- El gobierno se constituirá de la forma tradicional, cada cuatro años y con los votos de los representantes en el Congreso, pero sin necesidad de organizar elecciones para la ocasión. En su lugar, se hará coincidir con alguna iteración del evento comentado en el punto anterior. Obviamente, un gobierno impopular perderá rápidamente el control de las cámaras, aunque seguirá en el ejecutivo.


Características técnicas del modelo

- Para que los ciudadanos podamos verificar nuestros apoyos (lo que, a su vez, sirve como mecanismo para prevenir el fraude), la distribución de los mismos será privada, pero no anónima.

- Para el propósito expuesto en el punto anterior, los ciudadanos tendremos a nuestra disposición, al menos, dos sistemas electrónicos independientes. Una buena opción para ello, posiblemente, sería usar un portal web con autenticación mediante DNI electrónico, y un IVR para móviles (registrando previamente el terminal en una oficina puesta para tal efecto). Este último, además, haría posible que la solución fuera prácticamente universal.

- Los datos fríos estarán protegidos por un cifrado simétrico, cuya clave estará en posesión de agentes técnicos judiciales.

- El hardware estará provisto de mecanismos anti-tampering, y correrá exclusivamente Software Libre (incluídas las aplicaciones diseñadas específicamente para el sistema de voto electrónico). Cada capa de la arquitectura será gestionada de forma independiente, por equipos de organismos o empresas sin relación entre sí.

- Peritos técnicos de partidos políticos y universidades, previo aviso, podrán inspeccionar cualquiera de los sistemas involucrados en el entorno, bajo la supervisión del personal encargado del mantenimiento del mismo.


Una idea que todavía debe ser pulida

Ésta es la teoría básica que podría fundamentar un modelo como el descrito, una democracia representativa dinámica. Obviamente hay muchos aspectos que he pasado por alto, en parte por falta de tiempo, y también por desconocimiento. Si algún especialista en ciencias políticas desea ahondar en profundidad sobre este asunto, puede contar con todo el apoyo y la ayuda que me sea posible brindarle.


Checking the health of your SSD from GNU/Linux

18 10 2012
As you already know, SSDs degrade over time, as its memory cells support a limited amount of writes (a sacrifice that many people, including myself, find worthy in exchange to get rid of those slow and noisy mechanical disks).

This morning, while talking to a colleague, an interesting question was raised: how do we know when our SSD is near to day of its defunction?

Expensive, enterprise-grade SSD cards, like the ones from TMS, come with monitoring tools and a nice entry in "/proc" that can be easily checked by a script. But I had no idea if there's some similar for consumer SSDs.

Turned out it was quite easy. Most models provide health info via the S.M.A.R.T. feature, so you can obtain it with smartctl (on Fedora, this utility came into the package smartmontools):

[slopez@slp-work ~]$ sudo smartctl -a /dev/sda
(...)
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
9 Power_On_Hours 0x0032 099 099 --- Old_age Always - 23
12 Power_Cycle_Count 0x0032 099 099 --- Old_age Always - 34
177 Wear_Leveling_Count 0x0013 099 099 --- Pre-fail Always - 1
178 Used_Rsvd_Blk_Cnt_Chip 0x0013 077 077 --- Pre-fail Always - 458
190 Airflow_Temperature_Cel 0x0022 067 051 --- Old_age Always - 33
235 Unknown_Attribute 0x0012 099 099 --- Old_age Always - 10
(...)

The most relevant attribute while checking the health of our SSD, is Wear Leveling Count (more info on Wear Leveling on Wikipedia). But don't get fooled by its name, it's not really a count, but an indicator of how healthy are the cells in your disk, where 100 is the best, and 0 the worst.

When this value falls below 20, you should start considering backing up your data and buying a new disk.


Java, Google y Oracle, un triángulo amoroso conflictivo

21 08 2012
Piense por un momento en el número de aplicaciones Java que emplea usted con frecuencia. Ahora, repita el ejercicio con un usuario doméstico convencional. Lo más habitual será que responda "una" o "ninguna" en ambos contextos. Y es que, en la práctica, la presencia de aplicaciones Java en PCs de escritorio se limita en gran medida a un puñado de applets empleados en ciertos sitios web para superar algunas de las tradicionales limitaciones que imponían los lenguajes ejecutados en el navegador. Pero, a medida que estas limitaciones se reducen, lo hace también el ya de por sí estrecho marco funcional de dichos applets.

En el frente de los servicios web, la cosa no pinta mucho mejor para Java. La nueva generación de servidores de aplicaciones incumplieron la promesa de ponerse a dieta, y siguen siendo monstruos pesados, complejos y poco eficientes. Los frameworks más populares, sufren de los mismos síntomas. En conjunto, esto ha provocado que la mayor parte de empresas jóvenes del sector de las TI hayan evitado el uso de estas tecnologías (aunque no de la JVM, que gracias a lenguajes como Scala, Groovy, Clojure o jRuby, parece estar viviendo una segunda juventud), al menos en el corazón de su negocio.

Y no es que no sea posible escribir aplicaciones eficientes en Java. OpenDJ es, probablemente, el servidor LDAP más rápido del planeta. A su vez, la evolución de los garbage collectors concurrentes, ha puesto fin (si el programador toma las precauciones apropiadas) a la temida recolección "stop-the-world", lo que posibilita el uso de la JVM en entornos donde es crítico que los servicios resuelvan las peticiones en un tiempo limitado. El problema es, en mi opinión, el abandono total de cualquier visión pragmática en pos de la aplicación estricta, y casi enfermiza, de formalismos y patrones. Lo cual se traduce en que las tareas más sencillas se hayan convertido en el recorrido reiterativo de stack traces kilométricas.

Por fortuna para Java (y por desgracia para muchos programadores), le queda un reducto donde parece estar a salvo del embite del resto de lenguajes: el entorno financiero. Gracias al empuje que, en su momento, le dieron Sun, IBM y Oracle, este lenguaje se ha convertido (aunque algunos rechacen reconocerlo por las connotaciones negativas que conlleva) en el nuevo COBOL. Y no es de extrañar, ya que son precisamente estas empresas las más proclives a sacrificar rendimiento y flexibilidad, a cambio de la promesa de un entorno estable y predecible (que Java y sus frameworks sean realmente capaces de sostener esta promesa es un asunto bastante discutible, pero ese es otro tema).


Y entonces, llegó Android

Las circunstancias expuestas arriba hacen que, a pesar de ser un lenguaje que suele estar presente en los entorno académicos, Java perdiera el sex appeal entre los nuevos programadores. Pero entonces llegó Android, para el cual Google decidió que se usaría Java con una implementación de la API y la JVM desarrolladas por ellos mismos. Y con Android, la fiebre de las aplicaciones móviles se extendió a un nuevo terreno,siendo Java el vehículo preferente para recorrerlo. Y así, este lenguaje que parecía languidecer por momentos, obtuvo el balón de oxígeno que tanto necesitaba.

Pero a pesar del tremendo favor que Google le estaba haciendo a Oracle al empujar a las nuevas generaciones de ingenieros para que mantuvieran el interés por Java, los chicos de Larry Ellison decidieron denunciar al rey de los buscadores por el uso "inapropiado" de "su" lenguaje. Obviamente, la intención del gigante rojo no era otra que monetizar la inversión que hizo en Sun, y que parecía no encontrar forma de rentabilizar. Y como innovar no parece ser lo suyo, decidió probar por la vía legal. Que los abogados son más baratos que los buenos ingenieros. O por lo menos, visten mejor.

El caso es que así fue, y no puedo decir que me sorprenda. Oracle a los mandos de un negocio distinto de el de las bases de datos, es como un elefante en la cabina de un Boeing 747. Ni siquiera él mismo sabe qué hace allí, y lo más probable es que termine estrellándolo.



El paro y la reforma laboral, análisis de un ciudadano

21 02 2012
Renuncia de responsabilidad

En primer lugar, quiero dejar claro que no soy un experto en economía. Simplemente soy un ciudadano más con cierta curiosidad, que lleva varios días recabando información sobre este tema. Mi intención con esta entrada es consolidar mi opinión, hacerla pública y aprender, si alguien tiene a bien corregirme (os invito a todos los que tengáis algo que aportar a dejar vuestros comentarios).


La evolución de la tasa de desempleo en España

Como muchos habréis visto en repetidas ocasiones, circulan por Internet y otros medios de comunicación un sinfín de gráficas que afirman representar la tasa de desempleo en España. Lamentablemente, muchas de ellas tienen un carácter claramente tendencioso, con la intención de culpar a unos y vanagloriar a otros.

En este artículo, voy a emplear la siguiente gráfica (extraída de este blog: http://oroel.blogspot.com/2011/04/la-encuesta-de-poblacion-activa.html) en la que las proporciones son lineales y se remonta hasta 1976:


En ella podemos apreciar la siguiente evolución:


  • La gráfica comienza en un ciclo ascendente causado por la Crisis del Petróleo de 1973 y el complejo clima político de los últimos días del régimen de Franco y el proceso de transición. [1]

  • En 1985, tres años tras la entrada por primera vez del PSOE en el gobierno, se detiene la destrucción de empleo e incluso se reduce la tasa de paro hasta situarse ligeramente por encima del 15% entre 1989 y 1990.

  • Entre 1991 y 1992 se produce un ligero incremento del paro, hasta 1993 en que la crisis mundial de principios de los 90 irrumpe con fuerza en España. En este punto comienza un ciclo de destrucción de empleo que duraría hasta mediados de 1994, cuando el paro alcanzó el 24.1% [2].

  • A finales de 1994 comienza un nuevo ciclo de creación de empleo. Dicho ciclo comienza con el PSOE de Felipe González todavía en el poder (aunque algunos atribuyen erróneamente el mérito a su sucesor) y mantiene un ritmo de creación de empleo constante en los primeros años del gobierno de Jose María Aznar (PP), a excepción un ligero estancamiento en 1999.

  • Posteriormente, a finales de 2000 y principios de 2001, en la segunda legislatura del gobierno del PP, la creación de empleo se estanca alrededor del 10% y el paro sufre un ligero repunte. Esta circunstancia puede estar ligada a la conocida como "Crisis de las Puntocom", aunque no he encontrado datos objetivos que avalen esta afirmación.

  • Entre 2004 y 2008, con el PSOE de José Luis Rodríguez Zapatero en el poder, la tasa de desempleo se mantiene razonablemente estable (el descenso que se aprecia en la gráfica está ligado a un cambio en el sistema de valoración de la E.P.A.) a pesar de la inyección de población activa que supuso la legación masiva de inmigrantes en situación irregular.

  • En 2008 estalla la crisis de la burbuja inmobiliaria y comienza un ciclo agudo de destrucción de empleo que lo dispara hasta la tasa actual del 20%.


Ideas que se pueden extraer del análisis de la gráfica

El primer hecho que me llama poderosamente la atención, es la tremenda inestabilidad del mercado laboral español, capaz tanto de destruir como de crear empleo en plazos extremadamente cortos. Esto es especialmente significativo cuando se compara con el grado de fluctuación de la tasa de desempleo con la otros países de Europa. En los últimos 10 años, la variación (valor en el punto máximo menos valor en el punto mínimo) en España ha sido de 11.8 puntos, mientras que en Portugal [3], Italia [4] y Francia [5] ha sido de 3.5, 2.4 y 2 puntos respectivamente.

Adicionalmente, la gráfica evidencia un claro efecto rebote entre el ciclo de creación de empleo que comenzó en 1994 y el actual de destrucción, poniendo de manifiesto que las estrategias de crecimiento promulgadas por el gobierno de Felipe González primero, y el de José María Aznar después, aunque fueron capaces de generar empleo rápido, crearon puestos de trabajo de mala calidad y en sectores poco competitivos.

Según la FEDEA (Fundación de Estudios de Economía Aplicada) [6] la inestabilidad de este modelo de crecimiento envenenado se nutre fundamentalmente de la dualidad del mercado laboral, repartido entre contratos temporales altamente precarios y contratos indefinidos ligeramente sobreprotegidos. Asimismo, también señala la falta de flexibilidad del sistema de negociación colectiva.


La reforma laboral del Partido Popular

Hace escasos días, el Partido Popular, esta vez con Mariano Rajoy al frente, promulgó una reforma laboral destinada a atajar la destrucción de empleo. Lamentablemente, dicha reforma no sólo no elimina el problema de la temporalidad, sino que lo empeora introduciendo un contrato de formación hasta los 30 años de edad y un contrato indefinido con periodo de prueba de un año (comportándose como un contrato temporal, a efectos prácticos).

Asimismo, a la hora de incrementar la flexibilidad del mercado laboral, en lugar de buscar un equilibrio de fuerzas razonable entre trabajadores y empresarios, otorga de golpe a estos últimos la potestad de variar las condiciones laborales de forma prácticamente unilateral.

Por otra parte, a pesar de que todos los implicados coinciden en señalar al empleo de baja calidad como la causa fundamental de la inestabilidad del modelo español, el plan del PP no contempla un incremento sustancial de las inversiones en I+D+i, ni una mejora efectiva del sistema educativo que incremente la cualificación de los trabajadores. Tampoco contiene ninguna iniciativa pública para el fortalecimiento del tejido industrial de carácter nacional.

A título personal, hay dos cosas que me llaman poderosamente la atención al respecto:

  • Que esta reforma, en su conjunto, esté claramente inspirada en reformas similares ejecutadas en otros países europeos, a pesar de que los datos señalan que el caso de España es único en la UE, y debería tratarse de forma particular.

  • El hecho de que el PP evite resolver el problema de la temporalidad y la calidad del empleo, a pesar de haber sido ambos reiteradamente señalados como principales causantes de la inestabilidad del marcado laboral. Esto me hace sospechar que su intención real no es otra que intentar reproducir el ciclo de crecimiento rápido que tuvo lugar entre 1994 y 2001, aún siendo sabedores de las consecuencias que esta estrategia ha tenido (y está teniendo). Espero equivocarme, pero todo apunta a que quieren volver a construir un gigante con pues de barro, con la esperanza de que se desplome cuando esté otro al mando.


Referencias

[1] http://es.wikipedia.org/wiki/Crisis_del_petr%C3%B3leo_de_1973
[2] http://es.wikipedia.org/wiki/Crisis_del_petr%C3%B3leo_de_1979
[3] http://www.oecd-ilibrary.org/economics/country-statistical-profile-portugal_20752288-table-prt
[4] http://www.oecd-ilibrary.org/economics/country-statistical-profile-italy_20752288-table-ita
[5] http://www.oecd-ilibrary.org/economics/country-statistical-profile-france_20752288-table-fra
[6] http://www.crisis09.es/propuesta/?page_id=37



Adobe Flash: The misunderstood ugly guy

13 11 2011
Almost everyone hates Flash, and the discontinuation of it's mobile version was seen by many as a triumph.

Being a GNU/Linux user myself, I also suffered all those crappy versions, late releases and crazy development cycles. But, looking back and trying to be fair, I must acknowledge that the availability of a Flash player for the major operating systems has lowered the barrier for multiplatform development for many people, specially for independent companies. And I'm not talking only about embedded videos on websites, but also videogames (like Machinarium or VVVVVV) and applications. In some sense, Flash was more successful than Java at building bridges between platforms.

That said, the failure of Flash on mobile platforms is not surprising at all. Pride seems to be the favorite sin for Adobe. They were barely able to produce decent quality versions for non-mobile platforms, so it was pretty clear their development work force wasn't strong enough to provide properly optimized versions for the more complex Android ecosystem.

Adobe rejected the option of freeing its Flash Player, while keeping Adobe Flash (the content creator) as a commercial product. Apparently, they feared publishing the source code of its player would make easier for its competitors to provide alternative editors. But competition is not a bad thing, as it usually enriches the ecosystem and increases the popularity of a product. And opening the player would have extended Flash to newer platforms, improved the quality of non-Windows versions, and reduced total development cost, giving them more chances to success on mobile platforms. Perhaps they would even won the favor of some other companies (namely Google), which would in turn embed support for Flash on their own products by themselves.

Adobe lost their big chance. Not even them understood the truly potential of their own product.


How Intel/AMD (inadvertently) fixed GNU Hurd

04 09 2011
Last Friday, on Hurd's IRC channel at freenode, we've accidentally noticed some machines were able to run certain operations on Hurd as KVM guest up to 10x faster than others. As antrik correctly guessed, this is the effect of Intel's Extended Page Tables, which allow the guest operating system to deal with it's own page faults. I suppose AMD's Rapid Virtualization Indexing could have a similar effect, but I don't have the hardware to be able to test it (please write to the mailing lists if you've been able to check it).

Since most people (including myself) are running Hurd in a virtualized environment, having the ability of taking advantage of this circumstance by moving to hardware with this technology supposes a great improvement, heavily reducing compilation times and increasing the interactivity of the entire system.

Let's see an small example of the difference between running with and without EPT.

Running without EPT (modprove kvm-intel ept=0):
root@debian:~# dd if=/dev/zero of=/dev/null bs=256k count=1000
1000+0 records in
1000+0 records out
262144000 bytes (262 MB) copied, 2.08 s, 126 MB/s

And with EPT:
root@debian:~# dd if=/dev/zero of=/dev/null bs=256k count=1000
1000+0 records in
1000+0 records out
262144000 bytes (262 MB) copied, 0.23 s, 1.1 GB/s

I think there will be interesting times for GNU Hurd.


Sometimes, swap space still matters

15 07 2011
Most modern, general purpose Operating Systems (OS), come with a full-fledged Virtual Memory (VM) system that generates the illusion of having more memory than the real amount installed in the machine. Whether this virtual memory is backed by real RAM, disk swap or it just isn't backed by any physical device, is something up to the OS.


Continue reading "Sometimes, swap space still matters"


How device size affects disk performance in Linux (II)

16 02 2011
I've just noticed that in a virtualized environment, where roundtrips are more expensive, read speed differences between a page-aligned partition and a non page-aligned one are even more noticeable:

Non-aligned partition (size in sectors: (41929649-63)+1=41929587):

none:~# fdisk -l -u /dev/sdb

Disk /dev/sdb: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 x 512 = 512 bytes
Disk identifier: 0x93dbf2be

Device Boot Start End Blocks Id System
/dev/sdb1 63 41929649 20964793+ 83 Linux

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=0
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 3.80593 s, 27.6 MB/s

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 3.82304 s, 27.4 MB/s

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=200
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 3.83713 s, 27.3 MB/s

Page-aligned partition (size in sectors: (41929654-63)+1=41929592) :

none:~# fdisk -l -u /dev/sdb

Disk /dev/sdb: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 x 512 = 512 bytes
Disk identifier: 0x93dbf2be

Device Boot Start End Blocks Id System
/dev/sdb1 63 41929654 20964796 83 Linux


none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=0
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.618494 s, 170 MB/s

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.582423 s, 180 MB/s

none:~# dd if=/dev/sdb1 of=/dev/null bs=1M count=100 skip=200
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.589081 s, 178 MB/s

NOTE: In both tests, the data is cached in the host (so there is no real I/O to disks but traffic through virtualization pipes), but clean in the guest.

How device size affects disk performance in Linux

09 02 2011
While running some tests in a client's environment, we've noticed reading from a partition of a multipath device was considerably slower than reading from its parent node:

[root@none]# dd if=mpath4 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 8.92711 seconds, 120 MB/s

[root@none]# dd if=mpath4p1 of=/dev/null bs=1M count=1024 skip=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 17.5965 seconds, 61.0 MB/s


We asked to client support of a well-known GNU+Linux vendor, and they indicated that this behavior was "expected", since this kind of partitions were created by stacking a dm-linear device over the original multipath node. I wasn't satisfied by this answer, since AFAIK dm-linear only did a simple transposition of the original request over an specified offset (the beginning of the partition), so I decided to investigate a bit further on my own.


Continue reading "How device size affects disk performance in Linux"


DRM y Software Privativo van de la mano

09 11 2010
Navegando por reddit, me he encontrado con esta entrada en la que un usuario se queja de que no puede reproducir un Blue-Ray legítimamente adquirido, ya que está utilizando como salida de vídeo una TV conectada al puerto HDMI de su portátil (un Macbook Pro).

En dicha entrada se comenta cómo los fabricantes se perjudican a sí mismos con este tipo de prácticas. Ciertamente es un aspecto a destacar, pero también es importante tener en cuenta que dichas prácticas no serían posibles sin que existiese cierto Software Privativo que haga efectivas las limitaciones artificiales impuestas por los fabricantes. Y donde hoy es impedir que se reproduzca un contenido si se visualiza en una TV sin HDCP, mañana podría ser cualquier otra prohibición igualmente ridícula y arbitraria.

Y es que este es uno de los principales motivos por los que Richard M. Stallman inició el proyecto GNU hace 25 años: impedir que los fabricantes tuvieran la capacidad de decidir sobre lo que el usuario puede o no hacer con su computadora. El Software Libre, como su propio nombre indica (al menos en su denominación castellana, más precisa que la anglosajona), trata sobre la libertad, y no sobre la gratuitidad, matización que con frecuencia se suele pasar por alto.

Si en atención a nuestra comodidad entramos en el jardín vallado que nos presentan y damos por buenas este tipo de prácticas (y entre ellas podemos incluir también modelos de distribución de software como el AppStore), le estamos dando vía libre a los fabricantes para que tomen el control de nuestros dipositivos y decidan por nosotros lo que podemos hacer con ellos. Y los peligros que esto entraña en una sociedad donde las TI están presentes a todos los niveles (y cada días más), son impredecibles.


Webs de administración y puertos redirigidos

29 07 2010
Si trabajas administrando sistemas, es posible que te hayas encontrado en la tesitura de tener que acceder a la consola de administración de algún dispositivo a través de un túnel SSH, redirigiendo algún puerto de la máquina de destino a otro local. Al hacer esto, puedes encontrarte con la circunstancia de que la aplicación a la que estás accediendo tiene referencias estáticas a su IP real, lo cual provoca que no puedas acceder correctamente a ella.

Si este es tu caso, y estás utilizando GNU/Linux, puedes hacer uso de iptables para salvar el escollo. Por ejemplo con

iptables -t nat -A OUTPUT -p tcp --dport 9000 -j DNAT --to 127.0.0.1:9000

estaríamos redigiriendo todo el tráfico saliente hacia el puerto 9000, al mismo puerto en nuestra máquina local.



Recuerdos y predicciones

13 04 2010
De pura casualidad, he encontrado una bitácora de Blogspot que abandoné a finales de 2005 (entonces tenía 21 años, ¡cómo pasa el tiempo!). Ciertamente, resulta curioso reencontrarse con le pasaba por la cabeza a uno en tiempos pretéritos. Entre las entradas que publiqué, que debo reconocer que no fueron muchas, hay una que me hace especial gracia. Trata sobre la burbuja inmobiliaria alrededor de un año antes de que explotara, por lo que he decidido rescatarla:


Política/Sociedad: Inversión inmobiliaria, un fraude legal

Mucho se ha hablado sobre el precio de la vivienda. Las viviendas de protección oficial, las "actuaciones", los pisos de 30 metros cuadrados. Pero, esta vez, hablemos directamente sobre el propio negocio inmobiliario.

Veamos, un individuo adquiere un inmueble por una cantidad, y en un tiempo determinado la vende tal y como la compró, sacando un beneficio considerable de dicha operación. Pero para la obtención de ese beneficio, dicho individuo no ha producido, no ha generado nada. No ha utilizado mano de obra (o en todo caso mínima, haciendo un esfuerzo por incluir en este aspecto a las agencias inmobiliarias) ni ha comprado material alguno. El único beneficio que ha devuelto a la comunidad es el correspondiente a los impuestos y canones apropiados, una mínima parte.

Así pues, obtenemos un beneficio que nace de una producción nula. Por tanto, en última instancia, alguien debe sufragar ese gasto. Y creo que es evidente sobre quién recae dicha carga: los jóvenes en busca de su primera vivienda. Pagamos (pagaremos) a lo largo de nuestra vida los réditos obtenidos por los especuladores, mediante unas hipotecas que parecen cadenas perpetuas. Por supuesto los bancos están encantados de tomar parte en este banquete en el que los más pobres pagamos la cuenta.

Por otra parte, se está estirando mucho de una cuerda, que puede terminar de romperse. El equilibrio entre el poder adquisitivo de los nuevos compradores, y el precio de la vivienda agoniza. Los bancos flexibilizan cada día más la concesión de hipotecas para que el convite no cese (ya hemos dichos que son nuestros comensales, y además tienen un gran apetito), pero puede llegar un momento en que sea imposible financiar unos precios tan altos con unas nóminas tan escasas. Entonces, ¿el problema se solucionará por sí solo? No me atrevería a afirmar tal cosa. En ocasiones, cuando la tendencia del precio de la viviendia está a la baja, pueden producirse situaciones de bloqueo, en las que los especuladores prefieren no vender a perder la inversión. En cualquier caso, y mientras llega ese supuesto, se siguen firmando condenas perpetuas en forma de hipotecas cada día.

Un fraude económico del que miles de jóvenes, han sido, son y seremos víctimas, con la única esperanza (algunos) de aliviar nuestro peso pasando la carga a la siguiente generación de jóvenes.


Nacionalismo de Carril

14 01 2010
Señores conciudadanos de Zaragoza,

Como todos sabemos, la ciudad está sufriendo multitud de remodelaciones repartidas por todo el núcleo urbano, que provocan ciertos inconvenientes a la hora de circular por el mismo. Es habitual encontrarse con calles parcial o completamente cortadas. En el segundo caso, hay poco que hacer. En el primero, todos los zaragozanos tenemos una tarea pendiente.

Y es que el hecho de que el carril de una calle se encuentre cortado, no implica que deba abandonarse su uso varios tramos antes del que se encuentra afectado. Por el contrario, aunque algunos no lo crean, es posible distribuirse por todos los carriles de la calle, incluso en el que termina cortado unos metros más adelante, y una vez alcanzado el tramo afectado, ir circulando de uno en uno cediéndonos el paso los unos a los otros, como si fuéramos personas civilizadas (sé que cuesta aparentar lo que uno no es, pero todo es cuestión de intentarlo).

Este método altamente sofisticado (como el sistema de refrigeración autónoma del botijo), permitiría aprovechar mejor los carriles de los tramos en obras, en lugar de la estrategia actual que los infrautiliza y genera colas interminables que se extienden varios cruces más atras (con lo cual entran en juego los semáforos, produciéndose un embotellamiento aún mayor).

Eso sí, queridos amigos, para llegar a este punto, existe una condición previa: abandonar el Nacionalismo de Carril. Y es que, en contra de lo que usted piensa, el carril por donde cirula no es suyo. El hecho de que usted llegara antes no sirve como "precedente histórico" que le otorgue la propiedad del mismo (aunque en vista de lo que sucede con algunos "Estatuts", poco le falta) ni le permite cerrar sus fronteras a los "inmigrantes" que proceden de carriles fronterizos. Recuerde que, antes o después, será usted el que se desplace a otro carril en busca de reconducir su coche a nuevos destinos, y no deseará que se le trate con semejante desprecio.

Una vez superado este problema, podremos empezar a usar de forma eficiente los carriles y, de esta forma, hacer menos duro el largo periodo de obras que nos espera en Zaragoza. No es tan difícil, varios millones de madrileños lo llevan haciéndo desde hace años.

Gracias por su atención.

Linux: Bug in the nozomi driver

05 12 2009
If you have a nozomi based 3G PCMCIA modem (like the Option models from Movistar Spain), you'll probably noticed that, since kernel version 2.6.29, you can no longer establish an Internet connection with it. While it properly answers to AT commands, when the pppd daemon tries to talk to the other side, it simply hangs with no response.

If this is your case, you might be interested in taking a look at this bug (13024). Or, if you're in a hurry (and somewhat brave ;-), you might want to try something like this:

--- nozomi.c.orig 2009-12-05 22:57:43.000000000 +0100
+++ nozomi.c 2009-12-05 22:57:54.000000000 +0100
@@ -1626,10 +1626,10 @@

dc->open_ttys--;
port->count--;
- tty_port_tty_set(port, NULL);

if (port->count == 0) {
DBG1("close: %d", nport->token_dl);
+ tty_port_tty_set(port, NULL);
spin_lock_irqsave(&dc->spin_mutex, flags);
dc->last_ier &= ~(nport->token_dl);
writew(dc->last_ier, dc->reg_ier);




El principio de los tiempos

26 10 2009
Fulianito tenía un plan. Le daba vueltas una y otra vez a la frase que cambiaría su vida: "(...) un número infinito de monos tecleando sobre un número infinito de máquinas de escribir por tiempo infinito, producirían la mejor novela de la Historia (...)".

No recordaba absolutamente nada del contexto, ni siquiera sabía con seguridad dónde la había escuchado, pero poco le importaba. Ahora estaba ocupado analizando los pormenores de los pasos que debía dar. En primer lugar, no le gustaba la idea de producir novelas, de hecho, él mismo aborrecía los libros. ¿Quién podría pagar por leer algo, cuando todas las historias que merecían la pena se proyectaban en los cines? Así pues, decidió que sus monos producirían algo mucho más cool, más vendible y, sobretodo, menos tangible: software para computadoras. No sabía muy buen en qué consistía el proceso de creación del mismo, ni tampoco tenía claro cómo comercializarlo, pero había algo que sí sabía con certeza: algunas personas habían ganado mucho dinero con él.

Una vez tomada esta decisión, necesitaba conseguir un número infinito de monos, y ahí se presentaba la primera dificultad evidente que debía afrontar... ¿Qué raza de monos elegiría para su proyecto? Había leído en alguna parte que ciertas especies eran muy violentas y poco disciplinadas. Luego estaba el problema de la alimentación y la limpieza, ya que por lo visto los monos no eran capaces de conseguir su propia comida fuera de su hábitat natural (por unos instantes se planteó montar la oficina en medio de la selva, pero desechó la idea con rapidez), y tampoco son muy dados a cuidar su higiene.

Pero, ¿qué especie de mono podría encontrar que fuera dócil, razonablemente limpia y fuera capaz de buscar su propia comida en la ciudad? Y entonces le vino a la cabeza: el becario. El becario es el primer caso conocido de involución, o evolución inversa. No estamos hablando del becario temporal, el que lo es durante un tiempo limitado por necesidades de trabajo, sino al de pura cepa, el que lo es toda su vida, aunque ni él mismo se dé cuenta. Originalmente homo sapiens, el becario, como forma de supervivencia, se adaptó a un entorno altamente competitivo convirtiéndose en el equivalente humano de un mono de feria; siempre feliz y contento (al menos en apariencia), a las órdenes de su maestro.

Pero apenas había solventado ésta, su primera gran dificultad, Fulanito se dió de bruces con el problema que estuvo a punto de dar al traste con su proyecto. Cuando solicitó a la agencia gubernamental de trabajo un número infinito de becarios ridículamente pagados, ésta le dijo que no era posible. El motivo que adujeron le pareció sumanente peregrino; la casilla en la que se indicaba el número de personas solicitadas para la oferta sólo admitía números naturales, de tal forma que era imposible especificar "infinito", ni como palabra ni con su equivalente algebráico.

Maldito gobierno, incapaz de hacer nada bien, siempre poniendo trabas en el camino del emprendedor. Pero no a él, Fulanito no dejaría que la futilidad de la administración pública tumbara su proyecto. Así pues, decidió cambiar su oferta y solicitar 100 becarios, que también son un buen montón.

Ahora precisaba de una forma de cuantificar el trabajo de sus mon... de sus becarios, con la intención de facturar a sus clientes en unidades concretas. Como él sabía que todos sus empleados producían la misma cantidad de código con idéntica calidad, decidió establecer una unidad estándar llamada hombre/mes (inicialmente pensó en llamarlo mono/mes, pero la primera resulta más comercial). Y para asegurarse de que el trabajo salía bien, seleccionó una metodología de desarrollo de software, utilizando un sofisticadísimo método basado en contar el número de páginas necesarias para describirla (en realidad es un método tan válido como cualquier otro, al fin y al cabo todas son la misma mierda). Posteriormente, Fulanito patentaría este método como Weight Revision System. O, en otras palabras, selección al peso.

Su proyecto estaba casi completo, pero necesitaba a alguien que pusiera orden en el gallinero. Así pues, seleccionó a los monos (a estas alturas Fulanito sabía de sobra que sus monos iban a ser becarios, pero por algún motivo se sentía más cómodo llamándolos así) más fuertes (que no a los más listos) y los puso al mando. Adicionalmente, y para motivar a todos sus empleados, contrató a un grupo de infrahumanos (hay quien los vincula con algun subespecie de troll) armados con látigos. Habían nacido los Gestores de Proyecto y el departamento de Recursos Humanos, respectivamente. Finalmente, en el séptimo día, Fulanito miró a su obra, y vió que lo que había hecho era bueno (o, al menos, rentable).

Y así, queridos niños, es como nació la primera Consultora de Software.