En recientes días escribí un post sobre cómo hacer nuestra navegación más segura usando Opera (en inglés). El principio de operación es simple: deshabilitar JavaScript por defecto excepto para aquellos sitio en los que plenamente confío.

No fue capricho. En alguna ocasión mordí un anzuelo y, sin intención, mi PC participó en un ataque masivo contra Freenode. ¿Cómo ocurrió? Visité una página que tenía un código malicioso de JavaScript, el cual se ejecutó automáticamente (tal vez gracias a onMouseOver o a onLoad) y mandó spam a dicha red. Me bloquearon varias horas y tuve que contactar a los administradores para explicar el caso. Ellos lidian con este tipo de cosas todo el tiempo (¡señal!).

No es el único tipo de problema de seguridad de JavaScript. Tampoco es el único ataque facilitado por JavaScript: como referencia les dejo XSS, X/CSRF, Clickjacking, Revestimiento de interfaz (UI redressing), fuga de datos personales, etc. No que requieran de este lenguaje, sino que con él son mucho más fáciles de implementar sin que el navegador pueda detectarlos.

Busqué formas de evitar llegar a esa conclusión; después de todo, la mayoría de los sitios Web usan JavaScript. ¿Es posible que el navegador sólo ejecute código bien intencionado? No. Una computadora es tonta. No puede distinguir código malicioso. Incluso existe una broma sobre el tema. ¿Cómo le hacen los antivirus? Se basan en firmas y bases de datos alimentadas por humanos y aún así a veces arrojan falsos positivos. Peor aún, también arrojan falsos negativos.

Sin embargo yo necesito una forma de confiar en mi PC. En el momento en que pierde mi confianza, no sé si está interceptando lo que tecleo o lo que transmito, o si las páginas que me muestra son ilegítimas, o si los programas está alterados de otro modo. No sé si mis passwords y datos de tarjetas de crédito están siendo transmitidos por la red a algún cibercriminal. Y no, no estoy exagerando. Desde el momento en que pierde mi confianza tengo que aplicarle un análisis forense, aunque, por lo general, sale más rápido reinstalar.

Mikko Hyppönen presenta en TED un listado de datos de tarjetas de crédito, como los roba un cíbercriminal.

Lo mismo ocurre con el navegador. Yo confío en que el navegador me permite mantener el control mientras navego. Si no confío en el navegador no puedo confiar en los datos que se envían o se reciben, en el contenido de los sitios que visito o si realmente estoy yendo a los sitios que creo. Si mi navegador está comprometido ni siquiera puedo confiar en el cifrado SSL, por lo que ni con HTTPS puedo asegurar la confidencialidad o integridad de mis transacciones.

No por nada existe NoScript para FireFox.

Analogía con otro error histórico: los privilegios de administrador

No porque sea la opción más popular significa que sea la mejor o la más segura. Me recuerda a los llamados derechos de administrador. Cuando comencé a usar a Linux, en tiempos de Windows 2000 y cuando 98 era todavía lo más popular, los linuxeros me decían que nunca usara mi PC como root (”root” el usuario privilegiado en Linux, similar al “Administrator”). Yo pensaba: pero entonces no puedo instalar programas, no puedo configurar hardware, mi CD-RW no puede pedir todo el CPU y es propenso a fallas de escritura, no puedo ‘tunear’ mi sistema igual, etc. Todos esos “problemas” eran precisamente los motivos para no usar root por defecto. ¡Es bueno que no tan fácilmente se instale un programa o hardware! ¡Es bueno que no cualquier programa se adueñe del CPU! ¡Es bueno que no tan fácil se puedan hacer ajustes al sistema!

No porque sea la opción más popular significa que sea la mejor o la más segura. Windows 9x era lo más popular en ese entonces y 2000, intentando traerse el núcleo de NT, ahora multiusuario, apenas comenzaba a tomar auge. Muchos programas se rompieron por ese cambio de paradigma.

Ese pequeño cambio de pensar tenía muchísimas ventajas. En Linux y en Mac es rarísimo ver un virus. No que no los haya, pero no son tan fáciles de hacer y tenemos más líneas de defensa. Cada usuario tiene su espacio bien segmentado. Un usuario no puede ver el contenido de otro usuario. Un usuario no puede dañar el sistema, sólo su propia cuenta. Si un virus se inyecta en el sistema es porque explotó una vulnerabilidad y se reconoce como tal.

Pero seguía existiendo la necesidad de instalar programas, y no era fácil. Había que resolver el problema. Aquí es donde tenemos que hacer una pausa, quedarnos en “still” y analizar las posibles rutas:

• Considerar que el problema es la falta de privilegios por default y cambiarse a usar root por default, como lo hacía Windows 2000. Windows 9x ni siquiera tenía el concepto de privilegios; todos eran “administradores”.
• Considerar que el problema es el tedio, y crear métodos seguros para hacer fácil la escalación controlada de privilegios, pero manteniendo un nivel aceptable de seguridad. Habría que inventarlo de ser necesario.

Afortunadamente en Linux cuenta con su y sudo. Igual, para Windows XP SP2, Microsoft mejoró significativamente la delimitación de las facultades de los usuarios restringidos. Si en Windows 2000 muchos programas se rompieron, con este cambio hubo otra barrida; era obvio. Muchos programadores se quejaron, pero era necesario. En Windows Vista incluyeron UAC pero el plan estuvo mal ejecutado. Me han contado que en Windows 7 finalmente dieron en el clavo. Se tardaron más de 10 años, pero así se hace un cambio de esta magnitud.

Yo veo el uso de JavaScript como estar en la primera opción, atacando el problema incorrecto, y hay que pasarse a la segunda opción. Con la popularidad actual de JavaScript, el cambio tendría que ser sumamente doloroso, pero igualmente necesario.

De vuelta al tema

La única manera de estar seguros contra ataques de JavaScript es apagándolo. Si no lo hago así, cualquier persona puede ejecutar código en mi navegador con simplemente incluirlo en un sitio que yo visite. El código puede ser confiable o malicioso, y en cualquiera de los casos se ejecuta sin mi consentimiento, es decir, antes de yo validar o aceptar dicha ejecución. La única forma de prevenirlo es que yo lo habilite sólo para los dominios en los que confío.

¿Basta con deshabilitar JavaScript? No. Hay otros modos de atacar, pero JavaScript los facilita tremendamente; la mayoría de los ataques están basados y ofuscados con JavaScript.

¿Qué fue lo que salió mal?

¿Cómo es que pasamos del deseo de ser productivos, a tener corriendo en nuestras computadoras un lenguaje que permite rastrearnos, atacar otros sitios, etc.?

La escalera de la programación

Peldaño 0. Todo comienza por el principio, y en este caso, las computadoras son simples máquinas que harán lo que su operador le diga. A fin de cuentas eso son: viles, patéticas y despreciables herramientas que simplemente siguen las órdenes de un humano. El programa se hace en un lenguaje cualquiera.

Peldaño 1. No todos los humanos tienen la capacidad de hablarle a una PC en su idioma. Las instrucciones son demasiado primitivas y básicas, de modo que se vuelve una mezcla de ciencia y arte. Se requiere de tiempo y dedicación para hacer un programa medianamente complejo. Entonces, otras personas hacen programas por nosotros. Nosotros nos limitamos a instalarlos en nuestra PC. La PC sigue haciendo lo que el operador le dice… o no exactamente: hará lo que le diga el programador por medio de la autorización del operador.

Existe ahora un punto débil: el operador ahora debe confiar en el programador, pues las instrucciones pueden ser maliciosas. ¿Qué tal si el código del programador, como parte del programa, dice que tome archivos y los mande por correo o por fax? La computadora no puede distinguir la intención de esa instrucción. El código puede ser sintáctica y semánticamente válido y aún así realizar funciones maliciosas. Sólo queda, como línea de defensa, que el operador tome la decisión de instalar el programa o no, según su confianza en el programador.

Esto es crucial. Es imprescindible la libertad de autorización del operador. Esta libertad se puede ver afectada por engaños, por ejemplo, si el programador le muestra un código diferente al operador del que se va a ejecutar, o si el operador no es hecho consciente de lo que está instalando.

XKCD nos cuenta la historia de una madre que le cambió de nombre a su hijo para borrar la base de datos de la escuela de su hijo. Una PC no distingue intenciones buenas de malas.

Sin embargo, se presenta una excepción cuando el programador y el operador son la misma persona. Siempre es más satisfactorio lograr que el programa haga algo que ir a instalar ese programa en la PC, ¡y desmiéntanme! Es sumamente aburrido instalar un programa. Es más aburrido cuando el programador cometió un error y hay que ir a reinstalar una versión nueva, y aún más aburrido cuando esto ocurre una y otra vez.

Peldaño 2. Hay que instalar los programas en PCs que están aquí cerca o allá en el cerro. Su instalación puede requerir cambios en el sistema, potencialmente rompiendo la configuración de la máquina misma. Entonces la industria contempla la posibilidad de ejecutar un programa sin necesidad de ser instalado. Esto simplificaría las implementaciones, ahorraría dinero significativamente y se enfocaría el esfuerzo en el desarrollo del programa, y no en su instalación. La necesidad es obvia: un lenguaje que no requiera compilación, cuyo resultado no requiera una instalación, que funcione en todos lados de forma predecible, que no padezca del infierno de las dependencias (librerías), etc. Y luego existen diferentes computadoras con diferentes características, versiones de sistema operativo, etc.

La escalera de la Web

Por otra parte, se genera otra línea de escalafones de tecnología, la de la World Wide Web:

Peldaño A. El formato de la Web es HTML, que es como hablar de un .doc, pero en lugar de binario, en texto plano. El HTML tiene la característica de que el archivo se renderiza por diferentes programas en diferentes plataformas y da resultados suficientemente similares. Se vislumbra a la Web como algo multiplataforma (vamos a dejar la discusión de los múltiples navegadores para otra ocasión).

Peldaño B. La necesidad de la interactividad de las páginas Web. Más que una necesidad por hacer páginas interactivas, es resolver necesidades de interactividad muy específicas. Por ejemplo, el HTML no incluye semántica para mostrar selectores de fecha o validar direcciones de correo electrónico. El manejo masivo de información comienza a pedir menús de árbol expandibles, tan comúnmente usados en el escritorio. Resulta natural querer poner un menú contraíble en una página. Al iniciar como un lenguaje de texto genérico, HTML no podía dar suficiente semántica para que un navegador ofrezca estas capacidades él mismo. Al final todos pecaron: los navegadores populares no ofrecieron una forma de ofrecer tablas de contenido a partir de las etiquetas H1 a H6. HTML no se extendió con nuevos tipos de elementos INPUT, por ejemplo.

Tabla de Contenido generada automáticamente por Wikipedia para sus documentos. De forma similar, un navegador podría generar automáticamente la TdC según lo indiquen los elementos H1 a H6.

Desafortunadamente para HTML, todo mundo le quiso poner diferentes funciones para hacer algo “innovador”, como las etiquetas MARQUEE, BLINK y FRAME. Tuvo que llegar el momento de estandarizar, simplificar y reencauzar el lenguaje. Esto también demoró su progreso.

Aquí entra el auge de JavaScript. Por sí misma, la interactividad no debería ser riesgosa para los usuarios. El problema es la aplicación de la misma por medio de un lenguaje de programación (es decir, de propósito general) en lugar de un lenguaje de formato, semántico, específico. Aquí es donde se rompe el peldaño 1: el código escrito en este lenguaje se ejecuta en el navegador sin intervención del usuario.

La unión de ambas escaleras

Al final, se unen las dos escaleras para crear un monstruo. En la combinación navegador-JavaScript, los desarrolladores encuentran una plataforma para resolver el problema de la difícil implementación (descrito en el peldaño 2), mientras que el boom de la interactividad (peldaño B) facilita el auge. Lo anterior, a pesar del romper la libertad de autorización del usuario u operador (descrito en el peldaño 1). JavaScript hace que la implementación de programas sea extremadamente simple, pero a costa del usuario. Ahora el usuario tiene una plataforma de propósito mezclado: por una parte la lectura de la Web y por otra la de aplicaciones Web.

Sobre este ladrillo roto se han estado construyendo más tecnologías. Al principio las aplicaciones web eran páginas cuya interactividad se extendía con JavaScript, pero cada vez se depende más de JavaScript. Ahora hay sitios que generan las páginas mismas desde el script. Esto crea un nivel extra de abstracción que los navegadores no pueden optimizar fácilmente. Al final se traduce en mayor consumo de memoria y CPU, haciendo cada vez más lento al navegador en general. Para mi gusto, es un abuso generalizado de JavaScript, pero que también devela una especie de ruta natural, una ruta de menor resistencia, que es mejor atacar por los cuernos.

¿Qué necesitamos?

Lo que deberíamos tener es:

• Una forma de convertir las aplicaciones Web en aplicaciones de escritorio, sin esfuerzo para el programador.
• Una forma de instalar e integrar fácilmente estas nuevas aplicaciones, sin esfuerzo para el usuario.
• Una forma de distinguir entre la mera interactividad de documento y una aplicación hecha y derecha. La única forma que yo veo, infalible, es desaparecer JavaScript de la lectura de la Web, a favor de mejoras semánticas a HTML y CSS y dejar JavaScript para aplicaciones Web, fuera del navegador.

¿Funcionaría, al menos en concepto?

CSS es un lenguaje sumamente poderoso. Sin necesidad de JavaScript se pueden efectos muy interesantes. Esta página muestra 30 efectos con CSS puro que se pueden hacer hoy por hoy.

¿Podría comprar un boleto de avión sin JavaScript? Poco a poco sería más factible hacer una compra de avión menos frustrante. El wizard estaría programado del lado del servidor y se usaría HTML5 (o tal vez sería necesario inventar algo nuevo) para mejorar la accesibilidad y la interactividad (validaciones, controles de fecha y demás). Imagino que el contenido del wizard se va acumulando en la misma página conforme se llena, alimentado por procesos del lado del servidor. De esta forma podría imprimirse todo el wizard una vez lleno. Habría que estar al pendiente del tiempo restante a la expiración de la sesión. El elemento META podría contener un atributo “session_expiration” y el elemento FORM podría contener un atributo de “partial_action” que permitiría al navegador poner un contador en segundos y un botón de “refresh” para mantener la sesión activa y refrescar el estado del wizard.

¿Podría tener validaciones arbitrarias del lado del cliente? Afortunadamente HTML5 ya permite esto con el atributo pattern, en el que se le puede poner una expresión regular a cumplir como requisito para enviar el formulario. HTML5Pattern muestra algunos ejemplos de validación arbitraria por expresión regular.

¿Funcionarían los SSO como Google Accounts, etc.? Probablemente también se necesiten extensiones semánticas, pero quisiera que que el navegador tuviera un indicador de cuentas en las que tengo sesión en este momento, principalmente basados en OpenID, BrowserID y otros protocolos abiertos. Sería responsabilidad de Facebook desarrollar su propio “provider” para Facebook Connect.

Lo que se lograría

• Yo tendría que aceptar antes de permitir la instalación de la aplicación “Facebook”, “Twitter” o “Hangout”.
• Al distinguir una aplicación Web de una página Web, las plataformas de aplicación web (que ya no serían los navegadores) permitirían una más fácil integración entre la aplicación y el escritorio (iconos, lectura de documentos, etc).
• Yo podría confiar en mi navegador.
• La sola lectura de páginas web no consumiría tantos recursos como una aplicación Web.
• Poco a poco el HTML iría evolucionando para soportar nativamente lo que hacen las aplicaciones Web. Así ha ocurrido con HTML5, por ejemplo, con los nuevos elementos INPUT.
• Sería más difícil que me rastrearan, como con Google Analytics y demás.
• Funcionaría mejor el botón de Anterior.
• Funcionaría mejor el botón de Imprimir.
• Las páginas serían mucho más “accesibles”.
• La barra de estado siempre diría la verdad. Hoy en día hay forma de que uno sombree una liga y lo que se muestra en la barra de estado sea diferente que el sitio al que el navegador mande (*cough* Facebook *cough*).
• Se reduce el footprint de los lectores de páginas Web y se dedica JavaScript (o cualquier otro lenguaje) para aplicaciones especializadas.

So, the whole episode is about analyzing if is MPLS tunneling. Maybe somebody asked the question or maybe there is some disagreement in the industry.

I found it very interesting (and fun, as usual) but after listening to the show it got me thinking: it’s the wrong question. It’s not if MPLS is tunneling, but if MPLS *can be used for* tunneling.

So before going deeper I also have to say that I have never implemented MPLS; I have labbed it but that’s about it. I don’t consider myself to have enough foundations or experience as these guys. I hope not to shoot myself in the foot. With that said…

Tunneling is an application of encapsulation. Transport, multiplexing and delivery are other applications of encapsulation. Protocols encapsulate their payload. I see Ethernet as layer 2 “delivery”, IP as layer 3 “delivery” (or “transport” across multiple layer 2 domains), and 802.1Q as 1-factor multiplexing. I’m thinking TCP and UDP are 2-factor multiplexing.

I think we agree that IPv4 and IPv6 are network protocols, but you can create a tunnel with Hurricane Electric by setting the Protocol to 41 in IPv4, and without using GRE. The tunnel gets created by the way they are stacked and used.

So a valid question can be stated: am I setting up a tunnel when I start LDP and MPLS? So, from my point of view, the following are requirements for a tunnel to be made:

1. It is set up by or for a user outside of the domain of the transport network (even if the user is a network engineer in a data center). If I create a tunnel over the Internet, I’m the user outside of my ISP’s network. Note that I can tunnel over my own enterprise network; there is some interest in doing that and I’m the end user for that particular case. This takes away MPLS, but not MPLS VPN.

2. The tunnels created deliver the packet between two endpoints but neither of them are the final destination; or… well, technically yes, it can, but my point is that there is another endpoint higher in the OSI layers, even if it ends up being the same one. Once a packet gets delivered it gets decapsulated and further processed again for its delivery. Yes, Ethernet may fit here, but it doesn’t fit #1.

3. Two same or different delivery protocols with usually different address spaces are stacked onto each other. As such, there must be source and destination endpoint addresses endpoints in the encapsulated packet and in the lower-layer protocol. You may use the same address space, but most of the time it’s only a trick to get around some weird limitation. Oh, wait, just like tunnels! ;-)

So, by how it works, no protocol is a tunneling protocol (well, except maybe IPSec in tunnel mode). It’s only by what it was designed for that can be called a “tunneling protocol”.

Examples:
* ICMP is not a tunneling protocol but it can be used to create tunnels.
* Same for HTTP.
* It can be said that GRE is a tunneling protocol, but it doesn’t work by creating tunnels, but by encapsulating packets and making it easy to layer a protocol on top of another.

Was MPLS designed to do tunnels?

Best regards.

Ejemplo de uso:

$ ls -s1 | ./stats.gawk
cnt,min,max,sum,avg,stdev:	53	4	33064	78860	1487.92	6125.08

Cartel SuperHappyDevHouse Tijuana, marzo 2012.

Esto es muy simple. A desarrollar se aprende desarrollando. Este 24 de marzo (sábado) de 2012 estaremos reuniéndonos en el SHDH Tijuana a ver qué sale. :-) Algunos van a trabajar sobre proyectos de su página, otros sobre proyectos de negocio, otros van a ver qué hay de nuevo en el desarrollo de software, etc. La mejor forma de conocer en una comunidad local es participando. Así que no hay más: regístrate y llégale.

Nos vemos ahí. Lleva tu laptop y tu multitoma o extensión. Sugiero que te lleves todas las herramientas instaladas porque todavía nadie dice que va a llevar Internet… o mejor aún, lleva Internet. :-)

One of the reasons I do is because it allows me to pretty easily tweak my browsing safety.

There are several aspects to browsing safety. When working on your own computer the most important one after having an updated browser is JavaScript.

JavaScript is really useful, as it allows you to make websites interactive, but it can be easily misused to do all kinds of bad stuff, from personal tracking to attacking IRC networks, passing through personal information stealing, cross-site scripting, clickjacking, etc., even if you use Linux, Mac OS or any other non-Windows operating system. Although not strictly necessary, most of the new browser-related attack vectors require JavaScript to work or be useful.

People using Firefox rely on add-ons like NoScript to disable JavaScript, but Opera provides a surprisingly easy built-in interface to control JavaScript yourself.

Quick Preferences menu

What features of Opera do we need to use to make our browsing safer?

• We’ll use the easily-accessible global JavaScript toggle switch. You can see it by pressing F12.
• We’ll use the global JavaScript restrictions defaults.
• We’ll use the customizable per-domain “Site Preferences”, which include JavaScript toggling.
• We’ll use the easy access for the per-domain “Site preferences”. The dialog, although available through the Tools menu, is also just a right-click away, using the “Edit site preferences…” context menu entry.

What’s my way of using this?

Preferences dialog, Advanced tab, Content section

Navigate to Tools » Preferences…, and in the Advanced tab choose Content from the list on the left. Enable JavaScript using the checkbox just to let the JavaScript Options… button get enabled. Clicking it will get you to the dialog shown.

JavaScript options

This dialog lets you configure the global JavaScript defaults. I do not like websites raising or lowering any windows, and surely not allow changing the status bar, as I want to trust the links appearing on it before clicking on anything.

Likewise, I don’t want websites detecting context menu events, or at least not by default. Facebook is one site that detects right-clicking to prevent you from properly copying and pasting links. On the other hand, Google Maps extensively tweaks the context menu and gives you more options.

Also, I don’t like websites hiding the address bar, at least not by default, as I like to check the URL of each and every website that I browse to. This is helpful to prevent phishing attacks.

I disable pretty much everything by default. After setting it to your own liking click OK. Back in the Preferences window, uncheck Enable JavaScript to disable it back and finally click on OK.

You have just set the default JavaScript settings. You may feel this should be adjusted in the future, but let’s leave it like that for now.

Now, press F12. You will get a quick menu where you can globally enable or disable JavaScript quickly and easily, just in case you are in a hurry and can’t make it work for a specific website. It should be disabled because of what we just did. Leave it that way.

Context menu

Now, you should manually enable JavaScript to each site you actually trust. Let’s go to a site that uses JavaScript, say, Google. You will notice Google works a bit different now. Let’s say you trust Google and you want to let pages from www.google.com to be able to use JavaScript. Right click on any text or blank area of the website and choose “Edit site preferences…”. This will take you to the “Site Preferences” dialog.

In the “Site Preferences” dialog you’ll find a text box for the site (or domain) you want to tweak. You may want to use the current domain or tweak it to use a broader domain.

Site Preferences dialog, General tab

After choosing the domain, go to the Scripting tab. There you can “Enable JavaScript” only for that domain. When you enable JavaScript, the other 4 checkboxes default to the settings you chose in the JavaScript Options window, globally. You can change that too if you trust your site enough, or if the site requires it. I usually leave them unchecked.

Whenever you find a site that may not be working as expected, selectively enable JavaScript for that site only, but only if you trust it enough. “Enough” may have a different meaning for you or me. For some, it may be “enough” that the site doesn’t try to steal your information; others may want the site not to track them in any way (good luck with those, though).

Caveat

Some sites hired too few programmers (or too many potatoes) to code their sites and they work in weird ways without the proper JavaScript in place and don’t offer any kind of graceful degradation. For example, the online banking site I use does multifactor authentication that doesn’t work without JavaScript, so I selectively enabled it for that subdomain (www.somebank.com). However, the final login step gets sent to a different domain (say, loggedin.somebank.com), which uses JavaScript to redirect you to the dashboard page. Because the second domain doesn’t have JavaScript enabled yet, I can’t access it. Since I can’t access it, I can’t drop the context menu down to Edit site preferences for the second domain. This leaves me locked out of my online banking.

However, since the two domains are part of somebank.com, you can easily work around this chicken-and-egg problem by tweaking the “Site” textbox to remove the “www.” part and leave JavaScript enabled for the whole somebank.com domain. Voila!

Les comparto que OpenCharla ya aparece en los listados de iTunes.

Para ingresar el feed de OpenCharla a otro directorio de podcasts o a algún agregador, estas son las direcciones:

MP3 feed RSS: http://opencharla.gultij.org/mp3/feed.xml
MP3 sitio: http://opencharla.gultij.org/mp3/

Ogg feed RSS: http://opencharla.gultij.org/ogg/feed.xml
Ogg sitio: http://opencharla.gultij.org/ogg/

Mientras tanto, los dejo con el episodio 2×01 de OpenCharla, donde hablamos un poquito de IPv6, SOPA/PIPA, Plone, WPS, FileZilla y HTTPS.

El problema: estando escribiendo, cualquier rozón —a veces ni siquiera se necesita un rozón— provoca que el ratón se considere presionado en una ubicación diferente a la del cursor. Esto nos mueve súbitamente el cursor a la ubicación del puntero y quienes mecanografiamos debemos detener nuestra escritura para reubicar el cursor y continuar frustradamente (no sin antes corregir las consecuencias de lo ocurrido: salida de foco, tecleo en un lugar incorrecto, etc.).

Estoy usando una laptop Samsung NP-R540-JA09US. Naturalmente, tan pronto como la recibí, le instalé Debian. A diferencia de la IBM ThinkPad T42 la Samsung no tiene TrackPoint. Mi hermana tenía instalado Debian 6.0 en una laptop HP Pavilion dv6700. Lo menciono porque, al ser diferente hardware, me resulta más fácil echarle la culpa al software. Yo estoy usando Debian Sid; no Wheezy, sino Sid: dos versiones adelante de la estable. Lo que no puedo creer es que nadie más haya experimentado el mismo problema en todo este tiempo.

La mayoría de los linuxeros acostumbramos resolver nuestros propios problemas, así que a veces los desarrolladores no se enteran de la problemática que envuelve a los usuarios novatos y no-técnicos. Llamada de atención para los desarrolladores de GNOME.

Al menos por default, en GNOME, las interfaces para ajustar los parámetros del Touchpad son muy pobres. El afán de hacer las interfaces amigables a veces llevan a los desarrolladores a la falacia de eliminar cosas que realmente son útiles, como los valores numéricos que resultan de un control tipo “slider” (de esos que son como para controlar el volumen, pero rectos). Esto hace que sea difícil tener valores de referencia para calibrar algo tan importante como el equivalente del ratón.

Por ejemplo, para la “detección de palma” tienen un slider cuyos extremos dicen algo así como “leve” y “fuerte”. Es un control que no tiene retroalimentación inmediata o visual, con valores sin sentido y sin disponer de una referencia comparativa.

Al usar Debian Sid, actualizar a una versión más reciente de software no es una opción, a menos que quiera arriesgar mi laptop con software experimental y con baja probabilidad de que el problema esté realmente resuelto.

Hecho el berrinche correspondiente, incluyo los pasos que seguí para reducir mi estrés con el uso del Touchpad.

Habilitar de manera personalizada la desactivación del Touchpad mientras escribo

Esta parte la hice bajo GNOME 3. Aunque GNOME Control Center trae una opción llamada “Deshabilitar el Touchpad mientras se escribe”, la realidad es que los parámetros de esta opción son extremadamente conservadores.

Lo que esta opción hace es cargar un programa llamado syndaemon, que monitoriza los eventos de teclado y desactiva el Touchpad mientras se detecta que el usuario está escribiendo. GNOME Control Center, en su versión 3.2.2, al menos en Debian Sid, deshabilita el Touchpad durante 2 segundos después del último teclazo, con el inconveniente de que ni siquiera permite el movimiento del puntero.

Para resolver esto, deshabilité dicha función, dejando que el touchpad siempre estuviera habilitado por default, pero yo cargué manualmente syndaemon desde un “Startup Application” (gnome-session-properties) con los siguientes parámetros:

syndaemon -i 0.8 -K -t -R -d

-i 0.8, que deshabilita el Touchpad por sólo 0.8 segundos después del último teclazo.
-K, que no deshabilita el Touchpad si se usan combinaciones de teclas (como Ctrl+W). Esta opción ya la incluye GNOME.
-t, que sólo deshabilita los taps y los scrolls. El puntero se sigue moviendo.
-R, porque ya la incluía GNOME (usa XRecord).
-d, porque ya la incluía GNOME (carga como demonio).

Con esto, espero menos de la mitad del tiempo para poder hacer un tap (y siempre dispongo de los botones de todos modos) y mientras puedo ir moviendo el puntero. Esto hace que el uso de la computadora sea mucho más fluido.

Calibración de la detección de palma

Esto lo hice a nivel X.org. A falta de parámetros reales para calibrar la palma, opté por usar el siguiente comando fuera de X11:

sudo evtest /dev/input/event6 | egrep 'WIDTH|PRESSURE'

Esta instrucción (cambiando event6 por el valor que corresponda en tu laptop) permite ver los eventos que ocurren con el Touchpad, relevantes a la presión y el ancho del toque.

Después de comparar con algunos taps comunes, toques accidentales, mi palma, etc., decidí que después de una anchura de 7 y una presión de 70, se considere palma. Así, creé el archivo /etc/X11/xorg.conf.d/synaptics con las siguientes líneas:

Section "InputClass"
	Identifier "Touchpad" #Requerido
	MatchIsTouchpad "yes" #Requerido
	Driver "synaptics" #Requerido

	Option	"PalmDetect"	"1"
	Option	"PalmMinWidth"	"5"
	Option	"PalmMinZ"	"70"
EndSection

Para ver los valores que actualmente tiene su driver de Synaptics (el Touchpad), se usa:

synclient

Con pocas modificaciones se puede hacer lo mismo para un archivo local.

Se puede colocar el comando en el arranque de sesión, pero se va a bloquear para pedir la contraseña. Se recomienda tener acceso al servidor remoto por medio de claves públicas para que el agente de SSH automáticamente pida la contrafrase en pantalla.

Puesto que tail -f nunca debería salirse, tal vez sería conveniente agregar una línea después del SSH que mande una alerta de que concluyó el tail -f o de que falló la conexión con el servidor. Tal vez se pueda hacer revisando el código de retorno, pero hay que ver qué ruido le provoca el tubo.

Se puede modificar para que también el icono y la severidad de la notificación sean distintas, pero en mi caso no es necesario.

El comando podría fallar si la cadena a mostrar contiene comillas.

#!/bin/bash

# stail-notify.bash
# Escrito por Octavio Alvarez.
# Licencia: WTFPL

[ $# -lt 3 ] && {
	echo "usage: "`basename $0`" <user@host> <file-to-tail> <alert-title>"
	exit
}

ssh $1 "tail -n 0 -f "$2 | while read M D T ELSE; do notify-send -t 5000 -i dialog-warning -u critical "$3" "$ELSE"; done

Para usarlo, lo ejecutan así:

stail-notify.bash alvarezp@192.168.2.100 /var/log/messages "Alerta de Syslog"

1. USUARIO_NUEVO entra al canal de charla y, después de no percatarse de lo que dice el topic, dice «tengo una pregunta» o «¿alguien me puede aydar?»
2. VOLUNTARIO_1 dice «¿cuál es tu pregunta?»
3. USUARIO_NUEVO le hace la pregunta específicamente a VOLUNTARIO_1.
4. Si VOLUNTARIO_1 no contesta en menos de 2 minutos USUARIO_NUEVO se siente ignorado y repite la pregunta. Además de que no es obligación del resto del mundo estar atento de sus reclamos, es posible que VOLUNTARIO_1 no sepa, pero sí VOLUNTARIO_2, VOLUNTARIO_3 o VOLUNTARIO_N, que no están en el canal en ese momento.
5. En ocasiones, cuando USUARIO_NUEVO no recibe respuesta, adopta una actitud donde VOLUNTARIO_1 está obligado a contestarle, como si fuera un servicio pagado de soporte.

Por eso, en los canales de charla, el protocolo es simplemente entrar, hacer la pregunta y ser paciente, muy paciente.

Obviamente, no todos saben esto y no es su culpa. Siempre entrará gente pidiendo ayuda y, claro, hay que darles la bienvenida. Esto toma tiempo, desde 1) estar al pendiente del canal hasta 2) escribir el mensaje de guía a cada usuario para que escriba su pregunta, dando a entender que yo sólo le doy al bienvenida. Para reducir la parte 2, algunos canales tienen un bot al que se le da la instrucción de darle la bienvenida al “usuario nuevo”. Yo creo que esto sale contraproducente porque la automatización se revela al usuario.

Para facilitar la parte 2, he configurado en mi X-Chat 2 los siguientes comandos para que la gente reciba un mensaje de mi parte.

/adelante $nick

say %2: adelante, qué pregunta tienes? Tal vez alguien sepa.

/paciencia $nick

say %2, sugiero que esperes un rato. Si alguien te puede ayudar, puede ser que esté ocupado o haya salido un momento.

y sus equivalentes en inglés:

/goahead $nick

say %2, what question do you have? Go ahead and ask; someone around might know.

/patience $nick

say %2, I suggest you wait for a while. If someone can help you, he may be busy or out for a moment.

El de /patience es para cuando el usuario haya repetido su pregunta a escasos minutos.

Aún falta pulir los mensajes para que se vean más naturales pero que, a su vez, abarquen más casos.

De esta manera me facilito el guiar a un usuario nuevo cuyo saludo, con un poco de suerte, yo vea. Creo que sólo siendo amigables con los usuarios nuevos, es como percibirán un valor real en la famosa “comunidad”. Para aumentar la probabilidad de detectar un saludo, es posible hacer cosas como configurar el realzado de palabras como “buenas” u “hola”, pero esto es harina de otro costal (X-Chat está muy limitado en este aspecto, pero se pueden escribir plug-ins).

Obviamente, si alguien va a tomar esta sugerencia, ponga su propio mensaje a su propio estilo. Realmente sería feo entrar a un canal y ver que 5 usuarios diferentes me contesten exactamente con el mismo mensaje.

El Gultij tiene podcast! Después de varios meses de pláticas y pruebas, ya tenemos los primeros episodios de OpenCharla.

OpenCharla se distribuye en formato Ogg por ser un formato libre de patentes y regalías. No necesitas descargar nada para oirlo, pues en la página del podcast disponemos de un reproductor web basado en Flash para oírlo en línea.

Sólo en caso de que quieras descargar el archivo será necesario que utilices un programa que lea archivos Ogg. Dicen que si instalas el filtro de DirectShow para Ogg lo vas a poder tocar en Windows con Media Player. En Linux seguramente ya lo soporta cualquier programa.

Bienvenidos los comentarios. Ah, aún no tenemos el RSS, pero pronto!

Los invito a asistir al ciclo de conferencias CDTI, en Centro de Gobierno (edificio blanco) en Tijuana, B. C. este sábado 13 de agosto de 2011.

Para saber más sobre CDTI y el evento, visiten la página del #cdti

La RAM está para ser usada.

Esta frase es cierta dentro de un contexto en particular. Se usa para permitir que el sistema operativo acelere disco a RAM tanto como sea posible, pues la RAM es significativamente más rápida que los discos duros.

Sin embargo, dentro del contexto de una aplicación de usuario, en realidad es una falacia. Algunos usuarios (e incluso algunos desarrolladores) no saben mucho sobre el funcionamiento interno de su computadora y usan esta frase fuera de su contexto correcto. Lo peor es que algunas veces ni siquiera les importa el consumo de la RAM. No les importan los derrames de memoria o piensan que si ocurren sólo una vez, no pasa nada. O piensan que los lenguajes y plataformas con recolección de basura (garbage collectors) se encargarán mágicamente de todo. Sin darse cuenta, acaban usando la frase en cuestión como un equivalente de:

La RAM está para ser desperdiciada.

Hay algunas cuestiones que en realidad alimentan este modo de pensar, llevándolos a concluir que una aplicación realmente debería poner tanta información como sea posible en la RAM y que, tarde o temprano, el sistema operativo lo manejará eficientemente. Más aún, que no hacerlo es un sacrificio de rendimiento.

Consideremos lo siguiente (sobresimplificaré para efectos de facilidad de explicación, pero el modelo es bueno). Por una parte:

• Cuando una aplicación solicita RAM y el sistema operativo la asigna, esa memoria queda reservada para el uso exclusivo de la aplicación hasta que ésta la libera. Una aplicación no puede saber (y no debería) si otra requiere o solicita RAM.
• Si la RAM física se llena y hay espacio de paginación (swap o paging) disponible en el sistema, el OS descargará algunas de las páginas menos usadas de la RAM hacia el espacio de paginación, sea una partición o un archivo. Cuando la RAM paginada se necesita nuevamente, se intercambia con otras páginas de RAM de las menos usadas. Ambas operaciones requieren de actividad en el disco duro. Eso es lo que hace a la paginación inherentemente lenta.
• El sistema operativo siempre dejará libre algo (digamos, 50 MB) de RAM física sin usar para que haya disponible cuando necesite reaccionar a una emergencia de inestabilidad de sistema.

Por otra parte:

• El sistema operativo usa memoria física para acelerar lecturas y escrituras a disco por medio de caché, de modo que cuando un sector de disco es leído múltiples veces, las subsecuentes se obtienen de la RAM, que es mucho más rápida.
• El OS sólo acelerará lecturas/escrituras a disco hacia RAM física, pues sería inútil “acelerar” de disco a disco.
• Cuando una aplicación solicita RAM, el OS liberará RAM usada para caché antes de asignarla al a aplicación solicitante. Esta operación no requiere actividad de disco si se están liberando lecturas aceleradas o escrituras ya fijadas; sin embargo, sí requiere de escribir en disco si necesita fijar escrituras aceleradas pendientes. Usualmente, el sistema operativo realiza esta fijación cuando la PC está en ocio, de modo que uno no lo nota y, cuando llega el momento, ya no hay escrituras pendientes por fijar.

Por último:

• Linux reporta el “tamaño residente en RAM” para un proceso como “consumo de RAM física”. Si uno quiere medir el consumo de RAM por una aplicación, se debe hacer con la swap desactivada. Por favor indíquenme cómo Windows reporta la RAM consumida por un proceso.
• Las escrituras a disco suelen ser más lentas que las lecturas.

La realidad sobre esta falacia es “cierto, el sistema operativo se encargará de eso, pero se muere el caché de disco y se provoca la paginación, alentando todo el sistema, incluyendo la propia aplicación“. Entonces: sí, el sistema se encarga, pero en realidad está recuperándose del error del programador a costa de una degradación global e innecesaria de sistema y la potencial inestabilida que conlleva.

Analicemos dos escenarios tomados de mi propia experiencia. Repito: estoy sobresimplificando. Úsese esto como modelo.

Caso 1: Un navegador acelera la red a disco en lugar de a RAM

Tienes un sistema con 2 GB of RAM, de los cuales tienes 1 GB libres (como en “tal vez usados por el caché de disco pero ciertamente disponible para las aplicaciones”). Tú ejecutas un navegador que acelera los recursos de red a disco porque es más rápido que el Internet (pues es más rápido que el Internet) y usa unos 300 MB of RAM.

1000 – 300 – 50 = 650

Acabas con unos 650 MB of RAM para aceleración de disco por memoria caché y 50 MB de RAM física real.

Cuando un navegador necesita un recurso de red, intenta cargarlo de disco (pues lo está acelerando). Sin embargo, el disco queda acelerado en la RAM por el sistema operativo y las lecturas subsecuentes se realizan en RAM. La penalidad en rendimiento apenas se nota.

Si el navegador quiere acelerar una página visitada por primera vez, la guardará ne disco. El SO acelerará la lectura a RAM y la pospondrá hasta que el sistema esté ne ocio (cuando estás leyendo el contenido del sitio). La penalidad en rendimiento apenas se nota.

Cuando cualquier otro proceso lee de disco, la probabilidad de pegarle al caché es alta porque hay 650 MB de RAM disponibles par esto. Incluso si se le falla al caché, lo que se lee de disco se acelera en RAM para los accesos subsecuentes. reading.

Entonces, ejecutas una máquina virtual que requiere de 450 MB de RAM. Ocurre lo siguiente:

• El sistema operativo libera 450 MB de caché de disco. Parte de este requiere de escrituras, parte no. Esta operación es sólo tan lenta como la cantidad de escrituras requeridas para fijar las escrituras aceleradas, así que no es tan lento. Además, el usuario en cierto modo lo espera porque le pidió a la PC cargar la VM.
• No hay paginación. No es necesario.
• Finalmente se asignan los 450 MB a la VM.
• La VM escribe a ese espacio físico de RAM asignado.

Aún quedan 200 MB disponibles para caché de disco, que el SO procurará usar eficientemente.

Ahora, el navegador quiere cargar algo de su “cache de disco”. Hay una probabilidad, claro que mayor que 0, de pegarle al caché y que el SO sirva el dato directamente desde la RAM. Supongamos que no, que fue leída desde disco. El navegador aún está acelerando la navegación pues el disco local es más rápido que el Internet. Más aún, el SO acelerará este objeto en la RAM para sus accesos subsecuentes.

Claro: la VM continúa corriendo desde la RAM sin necesitar de ningún tipo de paginación (o hiperpaginación). El sistema responde perfectamente. El usuario sabe (o debería saber) que si quiere liberar memoria, debe cerrar la VM o el navegador.

Caso 2: Un navegador usa más RAM que la que requiere, para su aceleración

Tienes un sistema con 2 GB of RAM, de los cuales tienes 1 GB libres (como en “tal vez usados por el caché de disco pero ciertamente disponible para las aplicaciones”). Tú ejecutas un navegador que acelera los recursos de red a disco porque es más rápido que el Internet (pues es más rápido que el Internet) y usa unos 300 MB of RAM.

1000 – 600 – 50 = 350

Acabas con unos 350 MB of RAM para aceleración de disco y 50 MB de RAM física real.

Cuando el navegador necesita un recurso de red, trata de cargarlo desde su asignación de RAM, así que es muy rápido (aún así, tiene que leerlo primero de disco si no estaba previamente disponible en RAM).

Cuando cualquier otra aplicación lee de disco hay una baja probabilidad de pegarle al caché. En cualquier caso, la probabilidad general de que otra aplicación le pegue al caché es más baja, pues la memoria está exclusivamente asingada para el navegador. Esto incrementa significativamente la probabilidad de acceder a disco, lo que puede llevar a una alentar todo el sistema.

Minimizar el navegador no libera memoria para otras aplicaciones. la memoria aún está asignada para su uso exclusivo para éste.

Entonces, ejecutas una máquina virtual que requiere de 450 MB de RAM. Ocurre lo siguiente:

• El sistema operativo libera 350 MB de caché de disco. Parte de este requiere de escrituras, parte no. Esta operación es sólo tan lenta como la cantidad de escrituras requeridas para fijar las escrituras aceleradas, así que no es tan lento.
• Determina los 100 MB menos usados de RAM y las mueve al espacio de paginación. Esta operación es lenta pues implica varias escrituras inevitables a disco.
• Finalmente se asignan los 450 MB a la VM
• La VM escribe a ese espacio físico de RAM asignado.

El sistema ya no tiene caché de disco. Cuando otra aplicación necesita leer de disco, no le pegarán al inexistente caché y el SO tendrá que acceder físicamente al disco para servir esta petición. Esto es lento. Lo peor es que el acceso a disco no será acelerado para sus subsecuentes lecturas.

Ahora, el navegador quiere cargar algo desde su propia “caché de memoria” (que, por cierto, tal vez está paginada a disco). Puede pasar una de dos:

Si el recurso a extraer del caché de RAM de la aplicación está paginado en disco, el SO necesitará leerlo de vuelta. Puesto que los datos leídos ahora serán memoria “más reciente usada”, el SO podría intercambiarlos de disco contra algo de la RAM de la VM o de otra aplicación menos usada. Esta operación es lenta pues implica varias escrituras inevitables a disco. O:

Si el recurso aún está en la propia “caché de memoria” de la aplicación, será extraída como de rayo de la RAM. Sin embargo, la VM aún necesita su propia RAM para continuar al igual que las demás aplicaciones. Esto fuerza al sistema operativo a usar paginación nuevamente. Además, no hay RAM disponible para caché de disco y otras solicitudes de disco estarán continuamente siendo servidas desde disco sin la posibilidad de acelerar las subsecuentes hacia RAM. Esto genera una actividad constante a disco, alentando todo el sistema incluyendo al navegador. El “caché de memoria” de la aplicación no sirvió para nada.

Claro que la máquina virtual continúa corriendo y su RAM se necesita constantemente, así que la escritura a disco por paginación se vuelve una constante. El sistema operativo se alenta por lo que se llama hiperpaginación. En casos extremos, el sistema deja de responder, impidiendo al usuario de siquiera cerrar una de las dos aplicaciones para recuperarlo.

Conclusiones

Sí, la RAM está ahí para ser usada cuando se necesita, no para desperdiciarse. La RAM es un recurso limitado. Hay maneras de usar la RAM eficientemente. Por ejemplo, cargar los índices de un buzón de correo en RAM (sin cargar el contenido completo del buzón) puede, si se hace correctamente, acelerar significativamente la búsqueda de mensajes.

Sin embargo, acelerar disco a RAM puede que no sea una buena idea. La aceleración ya se hace por el SO, así que sólo se desperdicia una función eficiente del sistema operativo. A veces puede ser una buena idea, pero lo más probable, especialmente en aplicaciones de escritorio, es que no.

RAM is there to be used.

This phrase is true within a particular context. It is used to let the operating system cache as much disk as possible into RAM, as RAM is significantly faster than hard disks.

However, within the context of a user-space application it is actually a fallacy. Some users (and even some developers) don’t know much about the inner workings of their computers, and use this phrase outside of its proper context. What is worse, sometimes they don’t even care much about RAM consumption. They don’t care about memory leaks, or think that if memory leaking occurs only once, it’s fine. Or they think garbage-collected frameworks or languages will take care of everything by magic. Without knowing, they end up using the aforementioned phrase as the equivalent of:

RAM is there to be wasted.

There are some issues that may lead to actually feed this thought, leading them to think that an application actually should put as much information as needed in RAM, and that, sooner or later, “the OS will handle it efficiently”. Furthermore, that not doing this is just a performance sacrifice.

Consider the following (I’ll oversimplifying for the sake of easy explanation, but the model is true). On one hand:

• When an application requests for RAM and the OS allocates it, the memory is being reserved for its exclusive use until the application frees it. An application can not know (and should not know) if another application requires or requests RAM.
• If physical RAM gets topped and there is swap space available in the system, the OS will move out some of the least used RAM pages out to swap space, be it a partition or a file. When the paged-out RAM in swap space is needed, it gets swapped with other least-used physical RAM pages. Both operations require hard disk activity. That’s what makes swapping inherently slow.
• The operating system will always leave some (say, 50 MB) physical RAM unused, so it has RAM available to react to a system instability emergency.

On the other hand:

• Operating systems use free physical memory to cache disk reads and writes, so when a disk sector is read multiple times, subsequent reads are read from RAM, which is much faster.
• The OS will only cache disk reads/writes to free physical RAM, as it would be useless to “cache” disk to disk.
• When an application requests for RAM, the OS will free RAM used by disk cache before allocating it to the requesting application. This operation doesn’t require disk activity if freeing up RAM-cached reads or flushed disk writes; however, it does require disk writes if freeing up unflushed RAM-buffered disk writes. Usually, the OS flushes cached disk writes when system is idle, so you don’t really notice it, and when the time comes, everything is already flushed.

And last:

• Linux, report “resident RAM size” for a process as “physical RAM usage”. So if you measure your application RAM requirements, you should do it with your swap partitions disabled. Please enlighten me about how Windows reports RAM for a process.
• Disk writes are usually slower than disk reads.

The actual truth around this fallacy is “sure, the OS handles it, but you kill the disk cache and encourage memory swapping, slowing the whole system down, including your own application“. So yes, the system “takes care” of it, but it is actually recovering from the programmer’s mistake at the cost of overall, unnecessary, system slow down and potential instability.

So let’s analyze two scenarios taken out of my own experience. I repeat: I am oversimplifying. Use this as a model.

Case 1: A browser caches on disk instead of RAM.

You have a system with 2 GB of RAM, out of which you have 1 GB free (as in “maybe used by disk cache but surely available for applications”). You fire up a web browser that caches resources on disk (because it is faster than the Internet) and needs about 300 MB of RAM.

1000 – 300 – 50 = 650

You end up with about 650 MB of RAM for disk cache optimization and 50 MB of actual free physical RAM.

Whenever the browser needs a network resource it tries to load it up from disk. However, disk gets cached on RAM by the OS, so subsequent reads will be read out from RAM. Performance penalty it is barely noticeable.

If the browser wants to cache a newly-visited website, it will save it to disk. The OS will buffer the write to RAM so it will postpone it until the system is idle (when you are reading the website). Performance penalty it is barely noticeable.

Whenever another application reads from disk there is a high probability of hitting the cache because there is 650 MB of RAM available for this purpose. Even if missing the cache, whatever was read from disk will be cached in RAM for subsequent reading.

You, then, fire up a VM that requests 450 MB of RAM. The following occurs:

• The operating system frees up 450 MB of disk cache. Some of it requires writing, some not. This operation is only as slow as the disk-writes required for unflushed writes, so it’s not really that slow. Besides, the user somewhat expects it because he just commanded the PC to load up a VM.
• There is no swapping at all. There is no need.
• It finally allocates 450 MB to the VM.
• The VM writes to that physical RAM allocated for it.

There is still 200 MB available for disk caching, which the OS will try to efficiently use.

Now, the browser wants to load something from “disk cache”. There is some probability, higher than 0 of course, of hitting the cache and the OS serving the data directly from RAM. Let’s assume not: it was read from disk. The browser is still accelerating web surfing, as the local disk is still faster than the Internet. Furthermore, the OS will cache the object on RAM for subsequent access.

Of course, the VM continues running from RAM without ever needing of any kind of swapping or disk trashing. The system is fully responsive. The user knows (or should know) that if it wants to free up RAM it will close the VM or the browser.

Case 2: A browser uses more RAM than it should, for caching.

You have a system with 2 GB of RAM, out of which you have 1 GB free (as in “maybe used by disk cache but surely available for applications”). You fire up a web browser that could work really nice with 300 MB of RAM but instead caches everything up for the sake of speed and ends up using 600 MB of RAM.

1000 – 600 – 50 = 350

You end up with about 350 MB of RAM for disk cache optimization and 50 MB of actual free physical RAM.

Whenever the browser needs a network resource it loads it up from its own RAM allocation, so it is really fast. (It still has to load it first from disk if not previously available on RAM).

Whenever any other application reads from disk there is a lower probability of hitting the cache. In any case, the overall probability of the other applications of hitting the cache is lower, as memory is exclusively allocated for the web browser. This significantly increases the probability of accessing disk, which may lead to slow the whole system down.

Minimizing the browser does not free memory for other applications. Memory is still being allocated for exclusive use by it.

You, then, fire up a VM that requests for 450 MB of RAM. The following occurs:

• The operating system frees up 350 MB of disk cache. Some of it requires writing, some not. This operation is only as slow as the disk-writes required, so it’s not really that slow.
• It determines the least used 100 MB of physical RAM and moves it out to swap space. This operation is slow, as it involves a lot of unavoidable on-the-fly disk writes.
• It finally allocates 450 MB to the VM application.
• The VM writes to that physical RAM allocated for it.

The system has no memory for disk cache anymore. Whenever other applications need to read from disk, they will miss the cache and the OS will have to physically access the disk to serve the request. This is slow. What is worse, the disk access will not be cached for subsequent reading.

Now, the browser wants to load something from its own “RAM cache” (which, by the way, may probably be out in swap space, now). It may happen one of two things:

If the RAM cache resource is on swap space, the OS will need to read it back. Since that data will be now a “more recently used” memory page, the OS might swap RAM and disk with some contents of the VM or another least-used application. This operation is slow because it requires another lot of unavoidable on-the-fly disk writes. Or:

If the resource is still in the application own “RAM cache”, it will be retrieved flash-fast from RAM. However, the VM still needs its own RAM to continue, and so do all other applications. This forces the operating system to swap memory again. Also, there is no RAM available for disk cache, and other applications disk requests will still served continuously from disk without the possibility of RAM caching for subsequent access. This generates constant disk activity, slowing all the system, including the browser. The browser “extra RAM cache” did no good at all.

Of course, the VM continues running and its RAM will continuously be needed back, so disk writing becomes a constant. The whole system slows down by what is called disk trashing. In really bad cases, the system may become unresponsive, restricting the user from even being able to close one of the two applications to recover the system back.

Conclusions

Yes, RAM is there to be used when it is needed, not wasted. RAM is a limited resource. There are ways to use RAM efficiently. For instance, loading the indexes of a mailbox in RAM (but not the whole mailbox content), if done correctly, may significantly speed up mail searching.

However, caching disk to RAM might not be a good idea. The caching is already done by the OS, so it is just discarding an efficient OS function by an application. Sometimes it may be a good idea but most probably, particularly in desktop applications, it is not.

Gratis vs. Libre

Cuando no se requiere de pago alguno para usar plenamente un programa se dice que es “gratuito”. Dos ejemplos son Skype y OpenOffice.org. Sin embargo, existe una diferencia radical entre ambos: las libertades legales que la licencia de OpenOffice.org garantiza. Por eso se le llama software “libre”.

OpenOffice.org es más que simplemente gratuito y más —incluso— que simplemente “de código abierto”. Disponer del código fuente de un programa no implica la libertad legal de hacer públicas las mejoras.

La diferencia entre ambos programas ha quedado de manifiesto comparando la adquisición de Sun Microsystems por Oracle frente a la de Skype por Microsoft.

Antes de ser adquirido, Skype proveía su producto en tres plataformas: Windows, Mac y Linux. El programa era privativo y el protocolo cerrado. Al Microsoft adquirir a Skype, el producto y el modelo de negocios de Microsoft habrán de ajustarse uno al otro. Aunque Microsoft expresó su intención de continuar el soporte para todas las plataformas, es obvio que esto puede cambiar si no le resulta conveniente. Además, como ha ocurrido en otros casos, la disponibilidad del programa para otras plataformas no implica la sincronía con las liberaciones para Windows. Lo cierto es que lo más barato para Microsoft es eliminar el soporte para las plataformas ajenas y mantenerlo sólo para la plataforma que mejor conoce. Lo puede hacer, pues con la compra de Skype se ha adueñado de sus derechos de autor.

Analicemos el escenario en que Microsoft decida terminar con el soporte para Mac y Linux de Skype. Cualquier alternativa sería subóptima en comparación con una implementación nativa:

• Implementación un cliente alterno por terceros: Requiere de ingeniería inversa del protocolo, lo cual puede estar en contra del EULA. Además, los cambios en el protocolo podrían ser unilaterales, arbitrarios e incompatibles, lo que se convertiría en desconexiones para los usuarios del cliente alterno hasta la siguiente actualización del programa.
• Usar el cliente en un ambiente virtualizado: Requiere de un consumo extra y significativo de memoria. Además, requeriría de una licencia válida de Windows e implica el mantenimiento de actualizaciones, antivirus, etc.
• Usar el cliente sobre una capa de abstracción de Windows (Wine): Sólo si Wine fuera perfecto sería viable el uso masivo del cliente nativo de Skype. Sin embargo, el efecto “burro con zanahoria” descrito en el primer punto se traslada al sistema operativo. Microsoft puede mejorar Windows realizando cambios unilaterales, arbitrarios y potencialmente incompatibles, lo que perjudicaría y comprometería el funcionamiento de Wine. La realidad es que Wine dista mucho de proveer la plena compatibilidad con Windows y, debido a la alta velocidad con la que cambian y surgen nuevos API, es un trabajo más arduo que alcanzable.

En contraposición con lo anterior, antes de la adquisición de Sun Microsystems, OpenOffice.org era software libre bajo la licencia GPLv3. Cuando Oracle apagó el proyecto openSolaris, la comunidad de desarrollo de OpenOffice.org decidió reaccionar ante un posible cierre de OpenOffice.org: crearon The Document Foundation. Con las garantías ofrecidas por la licencia libre de OpenOffice.org se bifurcó el código para formar LibreOffice. De esta forma, independientemente del proceder de Oracle con respecto a OpenOffice.org, sea que apagara el proyecto o lo comercializara como producto, la opción nativa sigue existiendo.

Por último, considerando que Skype es un cliente de red y dada su popularidad, bastaría con que Microsoft abriera y mantuviera libre el protocolo actualizado para que la comunidad hiciera un cliente compatible con la plataforma de su preferencia e, incluso, multiplataforma. Al final, es más importante la especificación abierta y libre del protocolo que la del cliente.

Pantallazo de Superkb v0.10.

Bueno, Superkb 0.22 fue liberado hace un par de semanas. Las teclas se pintan ahora usando gradientes. Esto, además de los múltiples modos de rendereo de las teclas que se introdujo en la 0.15 (Feb 2008) y el uso de la biblioteca Cairo en 0.20 (Nov 2009), han cambiado drásticamente la apariencia en general. Ayer corregí la presentación de caracteres UTF-8, que ahora me permiten usar flechas para las teclas de cursor y otras más. Este es el resultado:

Superkb con el cambio más reciente para la versión 0.23.

También es una nota de agradecimiento a los usuarios que me han proveído con su retroalimentación tan útil.

Superkb v0.10 screenshot.

So, Superkb 0.22 was released a couple of weeks ago. It featured a gradient-based rendering of the keys. This, in addition to the multiple key-rendering modes introduced in 0.15 (Feb 2008) and the use of the Cairo library in 0.20 (Nov 2009), have drastically changed the overall appearance. Yesterday I fixed the display of UTF-8 characters, which have allowed me to use arrows for the cursor keys and others. This is the result:

Superkb with the most recent change for version 0.23.

This is also a thank you note to the users that have provided me with their useful feedback.

Teclado Logitech K200

En la fotografía se alcanza a distinguir a la derecha de la barra espaciadora que sólo hay tres teclas. Se trata de Alt, Menu y Ctrl.

¿Y la tecla Super_R apá? Me di cuenta ya cuando tenía el teclado instalado y funcionando.

Yo uso Superkb para lanzar aplicaciones. Para mí, lanzar aplicaciones es una de las cosas que podrían hacerse con shortcuts y por eso reservo la tecla de Super para esto. La tecla Super_R es importante porque no puedo presionar la Super izquierda simultáneamente con F12 usando una sola mano. Esto se necesita cuando tienes una hamburguesa en la otra mano, jaja!

Pues bien, Superkb admite en $HOME/.superkbrc tiene dos líneas de configuración: SUPERKEY2_STRING y SUPERKEY_REPLAY, con lo que quedará resuelto este pequeño problema.

“SUPERKEY2_STRING Menu” me permite indicar que la segunda tecla mágica a usar será Menu, y no Super_R.

“SUPERKEY_REPLAY 1″ me permite indicar a Superkb que si la tecla se presiona antes de mostrar el teclado en pantalla y no se usó para lanzar nada, que le envíe el tecladazo a la aplicación que actualmente tiene el foco. De esta manera, puedo seguir contando con la tecla Menu para mostrar los menús contextuales en cualquiera que sea la aplicación en la que esté trabajando.

Superkb es un lanzador de aplicaciones basado en atajos de teclado con pistas gráficas en pantalla. Está escrito en C usando Xlib con la ayuda de Cairo graphics, Pango, Imlib2, Xinerama, etc. y con su código fuente manejado con Git.

Tus atajos de teclado pintados por Superkb 0.22

Algunas de las características de Superkb:

• Fácil de usar. Se selecciona una tecla mágica (por omisión Super) como la base de los lanzadores y basta con presionar Super+Tecla para ejecutar cualquier comando configurado o aplicación seleccionada.
• No estorboso. Siendo basado en atajos no se necesita nada en pantalla. Al mantener presionada la tecla mágica mostrará en las pistas en pantalla y al soltarla desaparecen.
• Soporte para diferentes geometrías del teclado según lo provea el servidor de X Window System.
• Provee indicadores en pantalla sobre las acciones invocadas.
• La configuración se escribe en un archivo. Instalar la misma configuración en otra computadora es tan simple como copiar el archivo.
• La tecla mágica no se desperdicia. Se puede usar F8 como tecla mágica y al presionarla sin lanzar nada se envía a la aplicación que actualmente tiene el foco. Yo uso esto para la Thinkpad T42.

Superkb is a shortcut-based launcher with on-screen graphical hints. It is written in C using Xlib, with the help of Cairo graphics, Pango, Imlib2, Xinerama, etc. and the source code is managed using Git.

Your keyboard shortcuts painted by Superkb 0.22

Some of Superkb features:

• Easy to use. You select a hotkey (Super keys by default) as the base for your launchers and just hit Super+Key to execute whatever command you configured or launch whatever application you chose.
• Non-obstructive. Being shortcut based, you don’t need anything on your screen. Holding the hotkey down will invoke the on-screen hints and releasing it will dismiss them.
• Support for different keyboard geometries as provided by the underlying X server.
• It provides on-screen feedback for whatever action you have launched.
• Configuration is written on a file. You take the configuration with you to install it on your other computer as simple as copying a file.
• The hotkey isn’t wasted. You can choose F8 (or any other) as your hotkey if you please and hitting it will still send it to the currently focused window. I use this for the Thinkpad T42 that has no Super keys.

¿Qué opinas Octavio? ¿Debemos dejar que entre un nuevo participante al negocio de los diccionarios? Este dice que tiene “25mil palabras”. La RAE tiene mas de “88mil lemas”. Además, para definiciones pues siempre podemos recurrir a Ramón García-Pelayo y Gross. Creo que el problema real esta en el manual de ortografía, no en las definiciones.

Me acordé de cuando cambiaron tuxpam por tuxPAN por onda politica o cuando ponían: “este imeil a sido escrito sin asentos para fasilitar su lectura” y no por falta de ortografía.

Otros diccionarios han existido, por ejemplo, el Larousse. Su existencia no implica autoridad. Sin embargo, existe una necesidad implícita de unificación de reglas.

Todo depende de la reputación, seriedad y preparación académica del nuevo “jugador” que venda el diccionario. Si entra Juanito de los Papeles a hacer diccionarios, realmente sólo provocará caos si la gente le hace caso. El jugador debe ser respetado por la sociedad, por los estudiosos del idioma, los interesados en el habla culta y demás que busquen una referencia seria.

Sin embargo, hay que considerar que la tendencia del idioma la define la gente con el uso. Es decir, si por populismo se decreta que “ya todos podemos escribir k por /k/, como en komo estás o ke onda” y la gente lo sigue, se va a provocar una competencia caótica entre “autoridades”. Aunque al final una gane, el proceso no necesariamente será agradable.

En este sentido, los diccionarios son sólo documentadores del uso de los vocablos del idioma, aunque no sólo de los vocablos se componga el idioma. Los diccionarios deberían formar parte de un juego que contenga la función de distinguir y justificar las diferencias entre el uso culto y el coloquial.

En cuanto a la RAE, yo he observado que rápidamente recoge vocablos de España pero para Latinoamérica es muy burocrático. La misma RAE está buscando, tal vez sin propia iniciativa, perder esa autoridad; por “autoridad” también entiéndase “mercado”. Por ejemplo, hay términos que figuran en el Diccionario Breve de Mexicanismos de la Academia Mexicana de la Lengua, más no en el Diccionario de la RAE. Al final, lo único que significa es que de usar alguno de estos mexicanismos ante un español, probablemente éste no lo entienda.

Pensemos en la competencia entre Britannica y Wikipedia. Comparemos esto con las diferencias entre el conjugador de RAE contra Onoma, el conjugador de Molino de Ideas.

A la RAE le falta modernizarse. Apenas lo están haciendo con su departamento de “Español al día“. Sin embargo, están muy atrás de en términos de intercomunicación comunitaria. Ahí está WordReference.com que con sus foros y diccionarios de traducción llena este hueco.

Personalmente, aunque mi referencia central es la RAE, por lo general utilizo otras fuentes para confirmar y formarme un criterio.

Cuando la RAE cambia arbitrariamente las normas ocurre lo que recientemente fue noticia: que la gente reaccionó: “me estuviste dando lata durante 30 años para corregirme, y ahora por tus pistolas me la cambias… lo rechazo.” La actitud de la RAE fue de autoridad e imposición y no de “estos son los nuestros humildes resultados de 10 años de estudio del idioma; los motivos son A, B, y C para estos casos”.

En conclusión, un jugador nuevo es bienvenido si es una entidad estudiosa del idioma, seria y reconoce el valor de la comunidad de lingüistas en la región donde trabaja.