<?xml version="1.0" encoding="utf-8" ?>

<rss version="2.0" 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:admin="http://webns.net/mvcb/"
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
   xmlns:wfw="http://wellformedweb.org/CommentAPI/"
   xmlns:content="http://purl.org/rss/1.0/modules/content/"
   >
<channel>
    <title>Work In Progress - Software Libre</title>
    <link>http://blogs.nologin.es/slopez/</link>
    <description>cat /dev/mind | grep -e freesoftware -e politics</description>
    <dc:language>en</dc:language>
    <generator>Serendipity 1.3.1 - http://www.s9y.org/</generator>
    <pubDate>Mon, 05 Sep 2011 08:35:45 GMT</pubDate>

    <image>
        <url>http://blogs.nologin.es/slopez/templates/default/img/s9y_banner_small.png</url>
        <title>RSS: Work In Progress - Software Libre - cat /dev/mind | grep -e freesoftware -e politics</title>
        <link>http://blogs.nologin.es/slopez/</link>
        <width>100</width>
        <height>21</height>
    </image>

<item>
    <title>How Intel/AMD (inadvertently) fixed GNU Hurd</title>
    <link>http://blogs.nologin.es/slopez/archives/29-How-IntelAMD-inadvertently-fixed-GNU-Hurd.html</link>
            <category>Software Libre</category>
    
    <comments>http://blogs.nologin.es/slopez/archives/29-How-IntelAMD-inadvertently-fixed-GNU-Hurd.html#comments</comments>
    <wfw:comment>http://blogs.nologin.es/slopez/wfwcomment.php?cid=29</wfw:comment>

    <slash:comments>0</slash:comments>
    <wfw:commentRss>http://blogs.nologin.es/slopez/rss.php?version=2.0&amp;type=comments&amp;cid=29</wfw:commentRss>
    

    <author>nospam@example.com (Sergio Lopez)</author>
    <content:encoded>
    Last Friday, on Hurd&#039;s IRC channel at freenode, we&#039;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&#039;s &lt;a href=&quot;http://en.wikipedia.org/wiki/Extended_Page_Table&quot; title=&quot;Extended Pages Tables&quot;&gt;Extended Page Tables&lt;/a&gt;, which allow the guest operating system to deal with it&#039;s own page faults. I suppose AMD&#039;s &lt;a href=&quot;http://en.wikipedia.org/wiki/Rapid_Virtualization_Indexing&quot; title=&quot;Rapid Virtualization Indexing&quot;&gt;Rapid Virtualization Indexing&lt;/a&gt; could have a similar effect, but I don&#039;t have the hardware to be able to test it (please write to the mailing lists if you&#039;ve been able to check it).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
Let&#039;s see an small example of the difference between running with and without EPT.&lt;br /&gt;
&lt;br /&gt;
&lt;b&gt;Running without EPT (modprove kvm-intel ept=0):&lt;/b&gt;&lt;br /&gt;
&lt;code&gt;root@debian:~# dd if=/dev/zero of=/dev/null bs=256k count=1000&lt;br /&gt;
1000+0 records in&lt;br /&gt;
1000+0 records out&lt;br /&gt;
262144000 bytes (262 MB) copied, 2.08 s, 126 MB/s&lt;/code&gt;&lt;br /&gt;
&lt;b&gt;And with EPT:&lt;/b&gt;&lt;br /&gt;
&lt;code&gt;root@debian:~# dd if=/dev/zero of=/dev/null bs=256k count=1000&lt;br /&gt;
1000+0 records in&lt;br /&gt;
1000+0 records out&lt;br /&gt;
262144000 bytes (262 MB) copied, 0.23 s, 1.1 GB/s&lt;/code&gt;&lt;br /&gt;
I think there will be interesting times for GNU Hurd.&lt;br /&gt;
&lt;br /&gt;
 
    </content:encoded>

    <pubDate>Sun, 04 Sep 2011 10:29:00 +0200</pubDate>
    <guid isPermaLink="false">http://blogs.nologin.es/slopez/archives/29-guid.html</guid>
    
</item>
<item>
    <title>How device size affects disk performance in Linux</title>
    <link>http://blogs.nologin.es/slopez/archives/26-How-device-size-affects-disk-performance-in-Linux.html</link>
            <category>Software Libre</category>
    
    <comments>http://blogs.nologin.es/slopez/archives/26-How-device-size-affects-disk-performance-in-Linux.html#comments</comments>
    <wfw:comment>http://blogs.nologin.es/slopez/wfwcomment.php?cid=26</wfw:comment>

    <slash:comments>3</slash:comments>
    <wfw:commentRss>http://blogs.nologin.es/slopez/rss.php?version=2.0&amp;type=comments&amp;cid=26</wfw:commentRss>
    

    <author>nospam@example.com (Sergio Lopez)</author>
    <content:encoded>
    While running some tests in a client&#039;s environment, we&#039;ve noticed reading from a partition of a multipath device was considerably slower than reading from its parent node:&lt;br /&gt;
&lt;br /&gt;
&lt;code&gt;[root@none]# dd if=mpath4 of=/dev/null bs=1M count=1024&lt;br /&gt;
1024+0 records in&lt;br /&gt;
1024+0 records out&lt;br /&gt;
1073741824 bytes (1.1 GB) copied, 8.92711 seconds, &lt;b&gt;120 MB/s&lt;/b&gt;&lt;br /&gt;
&lt;br /&gt;
[root@none]# dd if=mpath4p1 of=/dev/null bs=1M count=1024 skip=1024&lt;br /&gt;
1024+0 records in&lt;br /&gt;
1024+0 records out&lt;br /&gt;
1073741824 bytes (1.1 GB) copied, 17.5965 seconds, &lt;b&gt;61.0 MB/s&lt;/b&gt;&lt;/code&gt;&lt;br /&gt;
&lt;br /&gt;
We asked to client support of a well-known GNU+Linux vendor, and they indicated that this behavior was &quot;expected&quot;, since this kind of partitions were created by stacking a &lt;i&gt;dm-linear&lt;/i&gt; device over  the original multipath node. I wasn&#039;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.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;&lt;a href=&quot;http://blogs.nologin.es/slopez/archives/26-How-device-size-affects-disk-performance-in-Linux.html#extended&quot;&gt;Continue reading &quot;How device size affects disk performance in Linux&quot;&lt;/a&gt;
    </content:encoded>

    <pubDate>Wed, 09 Feb 2011 09:04:48 +0100</pubDate>
    <guid isPermaLink="false">http://blogs.nologin.es/slopez/archives/26-guid.html</guid>
    
</item>
<item>
    <title>DRM y Software Privativo van de la mano</title>
    <link>http://blogs.nologin.es/slopez/archives/25-DRM-y-Software-Privativo-van-de-la-mano.html</link>
            <category>Software Libre</category>
    
    <comments>http://blogs.nologin.es/slopez/archives/25-DRM-y-Software-Privativo-van-de-la-mano.html#comments</comments>
    <wfw:comment>http://blogs.nologin.es/slopez/wfwcomment.php?cid=25</wfw:comment>

    <slash:comments>0</slash:comments>
    <wfw:commentRss>http://blogs.nologin.es/slopez/rss.php?version=2.0&amp;type=comments&amp;cid=25</wfw:commentRss>
    

    <author>nospam@example.com (Sergio Lopez)</author>
    <content:encoded>
    Navegando por &lt;a href=&quot;http://reddit.com&quot; title=&quot;reddit&quot;&gt;reddit&lt;/a&gt;, me he encontrado con &lt;a href=&quot;http://www.reddit.com/r/pics/comments/e37ba/this_is_why_we_pirate/&quot;&gt;esta entrada&lt;/a&gt; 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).&lt;br /&gt;
&lt;br /&gt;
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 &lt;a href=&quot;http://es.wikipedia.org/wiki/High-Bandwidth_Digital_Content_Protection&quot;&gt;HDCP&lt;/a&gt;, mañana podría ser cualquier otra prohibición igualmente ridícula y arbitraria.&lt;br /&gt;
&lt;br /&gt;
Y es que este es uno de los principales motivos por los que Richard M. Stallman inició el proyecto &lt;a href=&quot;http://gnu.org&quot;&gt;GNU&lt;/a&gt; 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.&lt;br /&gt;
&lt;br /&gt;
Si en atención a nuestra comodidad entramos en el &lt;a href=&quot;http://en.wikipedia.org/wiki/Walled_garden_(technology)&quot;&gt;jardín vallado&lt;/a&gt; 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.&lt;br /&gt;
&lt;br /&gt;
 
    </content:encoded>

    <pubDate>Tue, 09 Nov 2010 22:24:30 +0100</pubDate>
    <guid isPermaLink="false">http://blogs.nologin.es/slopez/archives/25-guid.html</guid>
    
</item>
<item>
    <title>Linux: Bug in the nozomi driver</title>
    <link>http://blogs.nologin.es/slopez/archives/21-Linux-Bug-in-the-nozomi-driver.html</link>
            <category>Software Libre</category>
    
    <comments>http://blogs.nologin.es/slopez/archives/21-Linux-Bug-in-the-nozomi-driver.html#comments</comments>
    <wfw:comment>http://blogs.nologin.es/slopez/wfwcomment.php?cid=21</wfw:comment>

    <slash:comments>0</slash:comments>
    <wfw:commentRss>http://blogs.nologin.es/slopez/rss.php?version=2.0&amp;type=comments&amp;cid=21</wfw:commentRss>
    

    <author>nospam@example.com (Sergio Lopez)</author>
    <content:encoded>
    If you have a nozomi based 3G PCMCIA modem (like the Option models from Movistar Spain), you&#039;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. &lt;br /&gt;
&lt;br /&gt;
If this is your case, you might be interested in taking a look at this bug (&lt;a href=&quot;http://bugzilla.kernel.org/show_bug.cgi?id=13024&quot;&gt;13024&lt;/a&gt;). Or, if you&#039;re in a hurry (and somewhat brave ;-), you might want to try something like this:&lt;br /&gt;
&lt;br /&gt;
&lt;code&gt;--- nozomi.c.orig	2009-12-05 22:57:43.000000000 +0100&lt;br /&gt;
+++ nozomi.c	2009-12-05 22:57:54.000000000 +0100&lt;br /&gt;
@@ -1626,10 +1626,10 @@&lt;br /&gt;
 &lt;br /&gt;
 	dc-&gt;open_ttys--;&lt;br /&gt;
 	port-&gt;count--;&lt;br /&gt;
-	tty_port_tty_set(port, NULL);&lt;br /&gt;
 &lt;br /&gt;
 	if (port-&gt;count == 0) {&lt;br /&gt;
 		DBG1(&quot;close: %d&quot;, nport-&gt;token_dl);&lt;br /&gt;
+		tty_port_tty_set(port, NULL);&lt;br /&gt;
 		spin_lock_irqsave(&amp;dc-&gt;spin_mutex, flags);&lt;br /&gt;
 		dc-&gt;last_ier &amp;= ~(nport-&gt;token_dl);&lt;br /&gt;
 		writew(dc-&gt;last_ier, dc-&gt;reg_ier);&lt;br /&gt;
&lt;/code&gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
 
    </content:encoded>

    <pubDate>Sat, 05 Dec 2009 22:35:05 +0100</pubDate>
    <guid isPermaLink="false">http://blogs.nologin.es/slopez/archives/21-guid.html</guid>
    
</item>
<item>
    <title>CentOS 4.6 sobre VirtualBox 1.6.0</title>
    <link>http://blogs.nologin.es/slopez/archives/12-CentOS-4.6-sobre-VirtualBox-1.6.0.html</link>
            <category>Software Libre</category>
    
    <comments>http://blogs.nologin.es/slopez/archives/12-CentOS-4.6-sobre-VirtualBox-1.6.0.html#comments</comments>
    <wfw:comment>http://blogs.nologin.es/slopez/wfwcomment.php?cid=12</wfw:comment>

    <slash:comments>0</slash:comments>
    <wfw:commentRss>http://blogs.nologin.es/slopez/rss.php?version=2.0&amp;type=comments&amp;cid=12</wfw:commentRss>
    

    <author>nospam@example.com (Sergio Lopez)</author>
    <content:encoded>
    Si has intentado instalar CentOS 4.6 sobre VirtualBox 1.6.0, probablemente te habrás encontrado con una desagradable sorpresa; tras la instalación, durante el primer arranque desde el disco duro, el sistema se queda congelado. El problema, aparentemente, es que VirtualBox sigue teniendo problemas lidiando con ciertas operaciones de la arquitectura x86, en este caso con la inicialización del soporte multiprocesador (MPS o ACPI, falla de las dos formas).&lt;br /&gt;
&lt;br /&gt;
Puedo entender que, al contrario que otras soluciones de virtualización, VirtualBox todavía no pueda mostrar al sistema operativo varios procesadores, pero que no soporte las estructuras de SMP, aunque sea dando soporte a 1 sólo procesador, me parece bastante lamentable.&lt;br /&gt;
&lt;br /&gt;
En el caso de CentOS (y supongo que otros sistemas GNU/Linux), en el primer arranque deberos entrar el menú online de GRUB para seleccionar el núcleo sin soporte multiprocesador y su &lt;i&gt;initrd.img&lt;/i&gt; correspondiente. Una vez arrancado el sistema, modificaremos el archivo &lt;i&gt;/boot/grub/menu.lst&lt;/i&gt; para hacer permanente este cambio. 
    </content:encoded>

    <pubDate>Fri, 18 Jul 2008 15:32:24 +0200</pubDate>
    <guid isPermaLink="false">http://blogs.nologin.es/slopez/archives/12-guid.html</guid>
    
</item>

</channel>
</rss>
