Lo hice y lo entendí

El blog de Vicente Navarro
17 nov

SMB connection failed: Insufficient server memory to perform the requested function.

Si al ir a montar un directorio compartido por Windows usando Samba te encuentras con este error:

# mount -t smbfs -o username=supercoco //pcconwindows/compartido /mnt/smb/
Password:
8070: tree connect failed: ERRDOS - ERRnomem (Insufficient server memory to perform the requested function.)
SMB connection failed

no le eches la culpa al Samba (como hizo un usuario de Ubuntu Feisty). Se trata de un problema conocido de Windows (Error message: “Not enough server storage is available to process this command”) y se puede solucionar fácilmente aumentando el parámetro IRPStackSize en el registro (Description of the IRPStackSize parameter in Windows 2000, in Windows XP, and in Windows Server 2003).

El IRPStackSize es:

The IRPStackSize parameter specifies the number of stack locations in I/O request packets (IRPs).

y ahí lo dejamos, porque no me atrevo a tratar de interpretar qué significa eso exactamente.

Su valor por defecto es de 15 (decimal) y el rango de valores permitido es de 11 (0xb hexadecimal) a 50 (0×32 hexadecimal) y se puede modificar en la siguiente rama del registro de Windows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Pero es muy posible que la primera vez no exista, por lo que tenemos que crear una nueva entrada DWORD para IRPStackSize e introducir el valor deseado. Yo he probado con 50 y, tras reiniciar (esto no lo dice el documento de Microsoft), el error ha desaparecido.

La pista sobre este problema me la ha dado un post a la lista de distribución de Samba ¡del 2002!: [Samba] Samba & W2K shares: ERRnomem: Insufficient server memory to perform the requested function

Finalmente, usar valores de 33 a 38 puede causar problemas: Event ID 2021 is logged even though lots of non-paged pool memory is available in Windows Server 2003.

:wq

07 nov

Hojas de estilo CSS para imprimir

Hace unos días patata dijo en un comentario que le gustan tanto algunos de los artículos de este blog que se los imprime, pero que le quedan muy mal y que si podría poner alguna hoja de estilo para imprimir. A cambio, yo no puedo hacer menos que agradecer tales halagos atendiendo su petición, ya que, por otro lado, es algo muy fácil de hacer, siempre y cuando el HTML esté muy estructurado y no se mezcle contenido con estilo, algo que muchas veces se tiende a hacer, especialmente si se usan herramientas automatizadas de creación de páginas web. Yo procuro evitarlo, aunque reconozco que en ocasiones muy determinadas y concretas lo hago.

El HTML está para el contenido y el CSS para el estilo. Idealmente, el HTML no debería de tener ninguna referencia a colores, fuentes, tamaños, alineamiento del texto, etc. Eso nos permite cambiarle muy fácilmente la hoja de estilo y tener otra página de aspecto radicalmente distinto pero con el mismo contenido. Alguna vez le querido explicar esto a alguien y me ha resultado muy fácil hacerlo apoyándome en CSS Zen Garden: The Beauty in CSS Design, una página en la que partiendo del mismo contenido, multitud de autores le dan un aspecto radical y sorprendentemente distinto únicamente cambiando el CSS, la hoja de estilo.

Para especificar una hoja de estilo diferente para impresión, deberíamos de tener en la cabecera del documento HTML (entre <head> y </head>) una entrada de CSS para el diseño en pantalla (media="screen") y otra para el diseño para imprimir (media="print"):

<link rel="stylesheet" href="style.css" type="text/css" media="screen" />

<link rel="stylesheet" href="print.css" type="text/css" media="print" />

Podemos consultar los tipos de media que podemos usar en el estándar CSS 2.1, capítulo Media Types. Vemos que también existe el media handheld para especificar hojas de estilos adecuadas para PDAs y teléfonos móviles.

Para la hoja de estilo de impresión de este blog, yo he decidido intervenir lo mínimo posible. Únicamente escondo todos los elementos que no deberían aparecer en la página impresa: los comentarios, el formulario para introducir comentarios, las cajas laterales, los enlaces de navegación (entrada anterior, entrada siguiente), etc. e intervengo mínimamente en un par de aspectos más.

Sigue leyendo »

02 nov

¡Ya se pueden revisar los comentarios!

Hace unos días Ringmaster se lamentaba en un comentario (que ya corregí con sus indicaciones) de no tener una función de “Vista Previa” en los comentarios para revisar el contenido y el formato de sus trabajados comentarios antes de enviarlo definitivamente.

La verdad es que muchos de los blogs que suelo visitar están en Blogger y una de las cosas que siempre me ha dado envidia ha sido la función de preview o Vista Previa.

Hasta ahora había sido muy reacio a instalar plugins de WordPress, entre otras cosas para no atarme a ninguno y que no me dejaran libertad para migrar a futuras versiones de WordPress con las que pudieran no ser compatibles. Además, algunos meten datos propios en la base de datos que después a ver cómo los borras si quieres dejar de usarlo. Sin embargo, esto era algo absolutamente necesario. Por un lado, por Ringmaster y otros visitantes como él, que con los comentarios tan detallados que nos regalan de vez cuando, es lo mínimo que se merecen, que los puedan escribir y revisar en condiciones. Pero por otro lado, es que hay veces que los comentarios llevan una ortografía desastrosa y quiero pensar que en muchos casos son errores que si existiera la posibilidad de revisarlos, sus autores querrían corregirlos.

Que yo pueda instalar un plugin para WordPress o no, en condiciones normales no hubiera merecido una entrada. Sin embargo, la lamentable ortografía, gramática y expresión al más puro estilo hoygan de ciertos comentarios llega a dañar la vista. Y eso sí se merece una reflexión. Y no es sólo aquí, por supuesto. En este humilde blog en realidad se nota bastante poco. Pero a poco que te das un paseo por la blogosfera española, si te consideras un poco respetuoso de la lengua de Cervantes, te puedes quedar absolutamente alucinado con lo que te encuentras. ¿Es de verdad ese el nivel educativo que tenemos en España? ¿Y lo es también el de los países de Sudamérica, que no parece precisamente mejor?

Podría poner y señalar ejemplos concretos, pero no lo voy a hacer, porque se dice el pecado, y no el pecador y lo último que se merecería un amable lector que pasa por aquí y decide dejar un comentario, es que se le ridiculizara.

Y que no se me entienda mal, por favor: prefiero mil veces que un lector deje un comentario, esté escrito como esté, que que no deje ninguno. Yo soy el primero que puedo tener errores por despiste o por ignorancia. La primera vez que una noticia mía salió publicada en la portada de Barrapunto hice el ridículo más espantoso posible poniendo “hoy a salido” en vez de “hoy ha salido“. Sin embargo, hasta donde puedo, trato de ser meticuloso con la ortografía y la gramática.

Por otra parte, también es muy fácil que ocurra que alguien cometa una pequeña equivocación y al releer se dé cuenta de un error que desearía que no estuviera ahí. Esto me ha ocurrido a mí en ocasiones en blogs WordPress que no tienen Vista Previa. Es en estos casos en los que más falta hace una función como esta.

Por todo ello, tengo el gusto de anunciar que he incorporado el plugin WP Ajax Edit Comments a este blog. El autor del plugin ha creado un vídeo que muestra perfectamente cómo se usa, pero es muy sencillo. Durante 10 minutos (así lo he configurado) después de enviar el comentario, es posible hacer click sobre el comentario o sobre el nick del usuario y modificarlo. Además, aparece un mensaje avisando de que es posible editar la entrada y un contador de tiempo mostrando el tiempo que falta de los 10 minutos.

Creo que está muy bien y no ensucia mucho la base de datos. Sólo mete algunas entradas en wp_postmeta para poder seguir los comentarios que se pueden editar:

mysql> select meta_value from wp_postmeta where meta_value like 'wpAjax%';                                                                                                      
+--------------------------------------------------------------------------------------------------------+
| meta_value                                                                                             |
+--------------------------------------------------------------------------------------------------------+
| wpAjax75bfb832b13b8233462531bb34f12bbeb48f6d51a9066cb3470dcbac6960069c364e0d1dbe06c510f0c3735b9dea964e | 
| wpAjax4740ec477fad9cff90b0a8dc1b7c99003cb06da3684bded96018c7f23b7d8096c1fad451916120e01d277a27775ac371 | 
+--------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

Pero como dichas entradas se pueden eliminar muy fácilmente desde la GUI de WordPress, no tienen mayor importancia. Si no tuviéramos la GUI a mano, podríamos hacerlo así:

delete from wp_postmetadata where left(meta_value, 6) = 'wpAjax';

Otro plugin que he probado y he estado a punto de instalar es el Live Comment Preview. Es muy sencillo. Es sólo un fichero .php que consigue mostrarnos debajo del cuadro de introducción del comentario una previsualización de cómo quedará el comentario al mismo tiempo que lo vamos escribiendo. También muy aconsejable para aquellos que no quieran complicarse mucho la vida.

Si quieres probar el plugin, ya sabes: ¡Deja un comentario!

Actualización 21/11/07:

El WP Ajax Edit Comments también guarda su configuración en la tabla wp_options. Para ver los valores almacenados podemos hacer:

mysql> select * from wp_options where option_name="WPAjaxEditComments";

Y para eliminarlos si queremos desinstalar el plugin:

mysql> delete from wp_options where option_name="WPAjaxEditComments";
01 nov

Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio.

Llevaba tiempo queriendo dedicarle tiempo a ver cómo está actualmente el panorama de la hibernación a disco en Linux. Ya lo había estado probando hace varios años, en tiempos del kernel 2.4, y la verdad es que estaba en pañales.

Yo sabía que existía el proyecto Suspend2, recientemente renombrado a TuxOnIce, y que parece ser que está dando muy buenos resultados. Pero fue cuando en la lista de novedades del kernel 2.6.20 leí que ya se incluían en el kernel grandes mejoras en la infraestructura necesaria para soportar la hibernación, que me decidí a retomar el tema.

Según leo en el artículo Suspend2 de la Wikipedia, parece que hay un tira y afloja entre los desarrolladores sobre si la parte que implementa Suspend2 debe de ir en el kernel o en el espacio de usuario. De momento, aún necesita parchear el kernel.

En cualquier caso, no hay que hacer muchas cosas para poder probar el TuxOnIce en una distribución que aún no lo soporte por defecto, y casi todas ellas vienen documentadas en el capítulo 2 del Software Suspend HOWTO. Resumiendo, hay que:

  1. Verificar que tenemos bastante espacio en la swap para almacenar todo el contenido de la memoria. Si no lo hay, se puede usar compresión o un fichero dedicado a esto.
  2. Parchear el kernel, compilarlo, instalarlo y arrancar con él.
  3. Hacer un pequeño cambio en los scripts del initrd.
  4. Añadir una opción de arranque al GRUB/LILO.
  5. Ejecutar el script hibernate.

Sigue leyendo »

29 oct

Las categorías no son etiquetas

¡Vale! ¡Vale! ¡Ya lo tengo claro! Las categorías no son lo mismo que las etiquetas:

Pero la verdad es que yo las estaba utilizando como si lo fueran, lo que me estaba ocasionando que el árbol de categorías creciera a demasiada velocidad, algo que no es lo que se espera de las categorías. Por ello, últimamente estaba siendo muy reticente en crear nuevas categorías, perdiendo así mucha flexibilidad en la clasificación de las entradas, lo que me estaba generando cierta frustración. Así que la reciente salida de WordPress 2.3 con soporte nativo de etiquetas me ha venido como anillo al dedo para racionalizar las categorías, algo que debería de haber ocurrido ya hace tiempo, y para ponerme como loco a ponerle etiquetas a las entradas… y esta vez sin ninguna limitación.

De las páginas anteriores extraigo una recopilación de aspectos, bastante informales algunos de ellos, que ayudan a entender la diferencia entre categorías y etiquetas:

  • Las categorías se pueden usar como etiquetas pero las etiquetas como categorías, no.
  • En una comparación con un supermercado, las categorías son como los grandes carteles que indican las secciones (droguería, charcutería, congelados, limpieza, etc.) y las etiquetas son como la propia etiqueta de cada producto que nos lo describe.
  • Las categorías organizan jerárquicamente, las etiquetas, no.
  • Las etiquetas proporcionan meta-información (información sobre la información), las categorías, no.
  • Las categorías pueden tener nombres únicos. Las etiquetas tienen que tener nombres conocidos.
  • Las categorías pueden tener nombres largos. Las etiquetas tienen que tenerlos cortos, de una, dos o, a lo sumo, tres palabras.
  • Las categorías no ayudan a los buscadores a buscar información. Las etiquetas, sí, y además, los directorios de etiquetas pueden catalogar tu página.
  • Las entradas estarán normalmente en pocas categorías, pero puede tener muchas, muchas, etiquetas.
  • Las categorías ayudan a los visitantes a buscar información relacionada en la página. Las etiquetas ayudan a los visitantes a buscar información relacionada en tu página y fuera de tu página.
  • Las categorías existen antes de que se cree la entrada que se quiere categorizar, mientras que las etiquetas se crean al crear la entrada: ad hoc.
  • Las categorías normalmente tienen una granularidad constante, mientras que las etiquetas pueden ser muy generales, como “Linux”, o muy específicas, como “ext3″.
  • Las categorías se planifican, las etiquetas son espontáneas, fruto de un brainstorming momentáneo: Como ver una foto y escribir las palabras que te sugiere en ese momento.
  • Las categorías se relacionan como en un árbol. Las etiquetas se relacionan como en una red.
  • Las categorías son algo que eliges. Las etiquetas salen casi espontáneamente del contenido.
  • Las categorías ayudan a clasificar aquello de lo que hablo. Las etiquetas ayudan a compartirlo y extenderlo.

Por cierto, también estrenamos nube de etiquetas.

:wq

28 oct

Linux no mata discos duros, se mueren solos

Me encuentro en Kriptópolis y en Barrapunto lo que parece el notición geek del año:

Pues qué malo que es el Ubuntu ese, ¿no? Pues a mí no me lo parece, la verdad. A mí me parece que los fabricantes de discos duros nos están vendiendo productos artificialmente poco duraderos. Vayamos por partes.

Resulta que hay una tecnología de fabricación de discos duros llamada de Load/Unload (Un Whitepaper muy aconsejable en PDF sobre el tema: Ramp : Ramp Load/Unload Technology in Hard Disk Driver, encontrado en Broken HDDs) cada vez más extendida, sobre todo en discos duros de portátil. Consiste en que el cabezal de lectura/escritura, en vez de estar permanentemente volando sobre el disco, se aparca frecuentemente, lo que teóricamente permite una mayor duración del disco, menor consumo y mayor protección contra golpes.

Ramp Load Unload Technology

Sin embargo, no se puede aparcar la cabeza un número indefinido de veces, sino que estos discos están preparados para un número máximo de ciclos de carga/descarga del cabezal que según el disco en cuestión puede ser de orden de 300K o 600K ciclos (K=1000). No es que justo cuando se llegue a ese número el disco va a dejar de funcionar de repente, sino que a partir de ahí el fabricante ya considera que puede dejar de hacerlo en cualquier momento. Paul nos cuenta que en varios de sus discos ha llegado a 600K, 900K y 1200K ciclos de carga/descarga antes de que empezaran a dar problemas. Pero eso sólo ¡en un año!

Yo me interesé por el problema nada más leer sobre él porque el disco de 2.5″ de marca Western Digital que tengo conectado a la EPIA EX10000EG (apareció de pasada en la entrada Sobre las VIA EPIA (V) ) hacía clicks muy frecuentemente. Lo notaba mucho porque cuando el disco se quedaba idle durante unos segundos, al volver al trabajajo casi siempre hacía un click que me disgustaba mucho pero que pensaba que sería normal (es un disco nuevo y tras varios tests no había encontrado ningún error). Ahora sé que cada vez que se oye uno de esos clicks lo más normal es que sea el cabezal en un ciclo de carga/descarga.

Pues bien, resulta que consultando los parámetros S.M.A.R.T. del disco con el comando smartctl, me encuentro con que el disco ya ha usado 7755 ciclos:

# smartctl -a /dev/hdc | egrep 'ID|Load_Cycle'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7755

Y no penséis que esta máquina se tira encendida semanas y semanas, ¡no!. Para llegar a ese número de ciclos, ese disco sólo ha pasado por una instalación de Debian y por todas las pruebas que le hice a la EX10000EG, incluyendo varios ratos de reproducción de vídeo. Por tanto, que haya consumido ya 7755 ciclos, que podría ser alrededor del 3% de los que el fabricante permite antes de que el disco sea declarado como “envejecido”, es una auténtica barbaridad.

En unas pruebas rápidas he podido ver que el número de ciclos crece muy rápidamente en pocos minutos y sin apenas usar la máquina:

Sun Oct 28 02:11:51 CEST 2007
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7744
Sun Oct 28 02:15:51 CEST 2007
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7753
Sun Oct 28 02:16:28 CEST 2007
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7754

Como se comenta en los enlaces que hablan del problema, con el comando “hdparm -B” podemos modificar el nivel de gestión de energía que ha de tener el disco (usando APM):

# man hdparm
[...]
-B     Set  Advanced  Power  Management  feature,  if  the drive supports it. A low value means
       aggressive power management and a high value means better performance. A  value  of  255
       will disable apm on the drive.
[...]

Podemos reducirlo al máximo:

# hdparm -B 254 /dev/hdc

/dev/hdc:
 setting Advanced Power Management level to 0xFE (254)

O incluso deshabilitarlo:

# hdparm -B 255 /dev/hdc

/dev/hdc:
 setting Advanced Power Management level to disabled

El caso es que tras hacer lo último, el valor de Load_Cycle_Count en la salida del smartctl ya no crece más que en una unidad cuando arranco, así que me lo he puesto en el fichero /etc/rc.local, para que se ejecute siempre durante el arranque. Los clicks también han desaparecido, así que todo es mucho mejor ahora.

Y es que en este sistema, aunque le puse un disco de 2.5″ para que no consumiera mucho porque la fuente es tan sólo de 60W, tampoco necesito que sea muy estricto en materia de ahorro de energía como si se tratara, por ejemplo, de un portátil trabajando con baterías, y prefiero evitar un envejecimiento prematuro del disco.

El problema con Ubuntu, el que ha creado toda esta alarma, es que en modo laptop, que no está habilitado por defecto, el fichero /etc/acpi/power.sh configura el disco para que ahorre energía de la forma más agresiva posible, con -B 1, haciendo que el disco tenga muchos más ciclos de carga y descarga y muchos más clicks:

function laptop_mode_enable {
...
    $HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null
    $HDPARM -B 1 /dev/$drive 2>/dev/null
}

En un bug report del problema que ya tiene bastantes meses, alguien ha probado con distintos valores de -B:

-B 128 -> 23 cycles in 10 minutes
-B 160 -> 29 in 10'
-B 180 -> 0 in 10'
-B 196 -> 0 in 10'
-B 200 -> 0 in 10'

Se ha generado alarma por Ubuntu e incluso en algunas otras distribuciones pero, en realidad, hay firmwares y BIOS que ya activan modos APM agresivos durante el arranque, como leemos en Problem with hard drive clicking, y como me ha pasado a mí mismo, que estaba sufriendo el problema con una Debian que no toca absolutamente nada de los parámetros del disco.

¿Y el problema no pasa en Windows? Pues yo no tengo ningún disco que haga clicks y que tenga Windows para probar si tras un rato de funcionamiento el valor de Load_Cycle_Count crece, pero yo esperaría que sí, ya que Windows suele optimizar bastante bien el consumo de energía en portátiles (los fabricantes de los mismos en realidad lo prueban todo en Windows).

Sí que puede ocurrir que en Linux los ciclos de carga y descarga ocurran mucho más a menudo, porque en Linux el kernel y los procesos se dedican a escribir muy frecuentemente en disco, siendo los periodos en los que el disco está idle mínimos. Cualquiera que haya intentado que un disco duro se quede parado tras un periodo de inactividad del sistema en Linux, se habrá dado cuenta de que no es una tarea fácil:

Pero para mí, me parece que lo más importante a recalcar es que en raíz, esto no es un problema de ningún sistema operativo, ni de ninguna distribución: ni Ubuntu, ni Debian, ni Fedora, ni Windows. No perdamos de vista que esto es un problema generado artificialmente por los fabricantes de discos duros que hacen su hardware con absurdas limitaciones.

Y, por cierto, no olvidemos que este es un problema sólo de los discos que se fabrican con esta tecnología de load/unload, a los que también podríamos llamar click-powered hard disks. En otros discos, dicho contador ni se estrena:

# smartctl -a /dev/sdb | egrep 'ID|Load_Cycle'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
193 Load_Cycle_Count        0x0032   253   253   000    Old_age   Always       -       0

Una curiosidad para acabar: ¿Sabías que con la opción -M del hdparm puedes configurar tu disco para que intente hacer menos ruido?

:wq

Actualización 1/1/08: En A vueltas con el “hdparm -B” en Debian Lenny vuelvo a tratar el tema, enfocándolo esta vez a ver cómo están tratando el problema los desarrolladores de Debian en Lenny.

Actualización 2/5/08: Hace tiempo que está en los comentarios, pero creo que es importante recalcar que en lugar de añadir el comando “hdparm -B 254” al fichero /etc/rc.local, es mejor editar el fichero /etc/hdparm.conf y poner algo así (cambiando el fichero de dispositivo y el valor de apm según nuestras necesidades):

/dev/sda {
apm = 254
}

Seguido por el comando:

update-rc.d hdparm defaults

para que el hdparm se ejecute durante el arranque.

Actualización 5/5/08: Parece que en Ubuntu Hardy Heron no hay /etc/init.d/hdparm, de modo que probablemente siga siendo buena idea usar el /etc/rc.local.

Actualización 24/5/08: La página Bug #59695 High frequency of load/unload cycles on some hard disks may shorten lifetime contiene una excelente explicación del problema así como una lista de discos duros afectados y del valor de “hdparm -B” más conveniente para solucionar el problema en ellos. Me ha gustado especialmente el siguiente párrafo:

The disk Load_Cycle_Count issue appears to be caused by a combination of two problems — The first is overly-aggressive power management from what might be considered buggy hardware. The second is that Ubuntu appears to be touching the hard drive on a regular basis for one reason or another.

ya que afirma claramente lo que yo siempre he defendido en esta entrada: Que esto es un problema de los fabricantes de discos duros. Que se agrava por cómo Linux usa el disco duro, de acuerdo, pero en primer lugar es un problema de cómo los fabrican.

28 oct

¡Mamá, mamá! ¡Google me tiene manía!

Acabo de vivir mi segunda actualización de PageRank. La primera fue a finales de Abril y la segunda en las últimas horas.

Para aquellos que no lo sepan aún, el PageRank es el peso que le da Google a una página a la hora de hacer sus cálculos para devolver los resultados. En los servidores de Google dicho valor se está calculando y actualizando constantemente. Google nos deja verlo en forma de valor entero de 0 a 10 en una barrita verde de su barra de herramientas:

PageRank kernel.org

Sin embargo, el valor que vemos ahí no es el actual que están usando los servidores de Google, sino que Google periódicamente (normalmente cada 3 meses, pero esta última vez ha sido mucho más) exporta los valores de PR a determinados servidores (toolbarqueries.google.com) a los que accede la barra de herramientas de Google para poder sacarnos la barrita verde con el valor adecuado. Hasta que llega la siguiente actualización de los servidores de PR, el valor permanece inamovible y las nuevas páginas web que se van creando y no existían cuando la anterior exportación, simplemente no tienen PR.

Hay incluso un módulo de Perl, el WWW-Google-PageRank que nos permite obtener dicha información desde la línea de comandos:

$ ./PageRank.pl http://barrapunto.com
6

Bueno, pues resulta que en la actualización de Abril, unos pocos meses después de comenzar con la andadura del blog, Google le dio nada más y nada menos que un PR de 5 a la página principal y un PR de 6 a la entrada de las reglas udev, que la verdad es que fue muy enlazada.

En la última actualización, el PR de la página principal es de 1 y el de la entrada de las reglas udev es de 3…

El PR es muy importante para los profesionales de la cosa del SEO (Search Engine Optimization) que se llevan grandes disgustos o alegrías en cada actualización del PR, pero es que en ello va su sueldo.

En mi caso, yo no tengo publicidad en el blog (me horroriza encontrarme los anuncios en las páginas que visito, así que de momento así seguirá) y lo hago sólo por pura devoción, ya que no gano nada con él y sí que pierdo mucho tiempo. Cuando lo empecé dije que era para tener a mano mis “recetas” y que le pudieran servir a alguien más. Tal declaración de intenciones sigue en pie, y en realidad me debería de dar igual la cantidad de personas que puedan llegar aquí y encontrar una solución a sus problemas. Pero no, no es así. Igual que me alegré mucho cuando la página aprobó el examen de Google, me ha fastidiado un montón este muy deficiente.

¿Y cuál puede ser la causa? Pues no tengo ni idea. Que yo sepa, no incumplo ninguna de las directrices de calidad de Google. Hay páginas que copian íntegramente el contenido de entradas de aquí, lo que puede ser malo de cara a Google, pero no puedo hacer nada al respecto. Si citan el origen, cumplen la licencia CC que le he dado a los contenidos.

Esta actualización de PR está siendo notoria por grandes bajadas de PR de muchas páginas que vendían enlaces, pero yo ni vendo, ni compro enlaces, que no está el bolsillo para tales trotes. Sin embargo, sí que veo de vez en cuando páginas de agregación de enlaces que se dedican a añadir enlaces a entradas sin ton ni son. ¿Se pensará Google que todos esos enlaces los estoy comprando?

En fin, que en principio los únicos que salen perdiendo son aquellos navegantes de Internet que podrían encontrarar una solución a su problema o a su duda en estas páginas y no lo hagan porque Google no les ha traído. Pero yo también pierdo un poco de la satisfacción de ver que lo que haces le pueda servir a más gente. Al fin y al cabo, si esto fuera sólo para mí no me esforzaría tanto…

Por otra parte, también es cierto que los lectores habituales, esos que te tienen en el agregador de feeds y que ves a menudo en los comentarios son mucho (¡qué digo! ¡muchísimo!) más satistfactorios que el lector esporádico de Google que te visita, lee lo que necesita y desaparece (aunque digo yo que alguno se quedará, ¿no?). Con el lector habitual se establece una relación en ambos sentidos, se nota lo que ha resultado interesante y lo que no, se percibe una evolución en el tiempo y se encuentran nuevas cosas sobre las que leer y opiniones realmente útiles. En definitiva… ¡es más humano!

¡Y que no se me olvide! Por favor, dejad comentarios en las entradas de los blogs que os gusten. Los que no tenemos publicidad, lo único que cobramos es teneros y sentiros ahí, al otro lado del cable.

¡Gracias por leerme!

PD: Y que yo tenga que aguantar que me venga a estas alturas el Google este a catearme;-)

:wq

28 oct

Los DPI en los navegadores web de Windows y Linux

En la entrada anterior, Los DPI en pantalla en Windows y Linux, hemos visto cómo gestionan los sistemas operativos los DPI de la pantalla. Sin embargo, tanto en Windows como en Linux podemos encontrarnos con que tras modificar la configuración de los DPI, las fuentes de los textos del navegador no sean escaladas proporcionalmente al valor de DPI del sistema operativo. Es importante aclarar que no estamos hablando de las fuentes del menú, barra de aplicacione, iconos, etc. que esas sí que se escalan correctamente, sino a las fuentes del texto de las páginas a las que se accede.

Para intentar aclarar el problema, primero nos tenemos que fijar en las unidades de medidas que define el estándar CSS 2.1. Por un lado tenemos las unidades de medidas relativas a otra unidad:

  • em: the ‘font-size’ of the relevant font
  • ex: the ‘x-height’ of the relevant font
  • px: pixels, relative to the viewing device

Podemos pensar que un número de pixels px no es una unidad de medida relativa, pero sí que lo es si pensamos que la página se puede mostrar en papel si la imprimimos o en monitores muy grandes, muy pequeños, en un proyector. Tú pones px cuando diseñas la página web pero luego ese pixel puede medir físicamente un centímetro si se muestra en un proyector. De ahí la relatividad de dicha medida.

Para una pantalla, el estándar indica como referencia que estando los ojos a una distancia de un brazo (28″) de la pantalla, un pixel ha de verse con un tamaño de 0.26mm (1/96 in) o, lo que es lo mismo, 96 DPI:

CSS 2.1 pixel

Por otro lado, tenemos las unidades de medida absolutas para las que es necesario conocer las dimensiones físicas del dispositivo de salida:

  • in: inches — 1 inch is equal to 2.54 centimeters.
  • cm: centimeters
  • mm: millimeters
  • pt: points — the points used by CSS 2.1 are equal to 1/72nd of an inch.
  • pc: picas — 1 pica is equal to 12 points.

Vemos que pt se define como puntos de 72 DPI.

Sigue leyendo »

27 oct

Los DPI en pantalla en Windows y Linux

Los DPI (dots per inch o puntos por pulgada) es una medida de resolución de impresión que especifica cuántos puntos de tinta o tóner pone la impresora por cada pulgada de papel. Son valores típicos, por ejemplo, 300 DPI o 600 DPI. El término se usa incorrectamente en pantallas y en escáneres, aunque en realidad dichos usos están muy extendidos. En las primeras, el término correcto es el de PPI (pixels per inch o pixels por pulgada), y en los segundos, es el de SPI (samples per inch o muestras por pulgada). En castellano podemos usar PPP que lo mismo valdría para puntos-por-pulgada que para pixels-por-pulgada. Yo voy a usar DPI, que es el término que se usa en todos los diálogos de configuración de Windows y Linux.

En esta entrada, vamos a intentar entender qué supone un valor u otro de DPI en distintos entornos y cómo configurarlo:

Sigue leyendo »

15 oct

La resolución 1366×768

Hace mucho, mucho tiempo, los usuarios de ordenadores con nuestros monitores de tubo sólo teníamos unas pocas resoluciones entre las que elegir, en función de las características del monitor y de la memoria de la tarjeta de vídeo: 640×480 (VGA), 800×600 (SVGA), 1024×768 (XGA), 1152×864 (XGA+?), 1280×1024 (SXGA), 1600×1200 (UXGA). Todas ellas son 4:3 excepto la 1280×1024 que es 5:4… ¿Te habías fijado en que usando esta resolución en en un monitor de tubo 4:3 las fotos salen un poco achatadas? ¿Te habías fijado en que posiblemente tu monitor LCD de 17″ o 19″ con esta resolución nativa tenga físicamente relación de aspecto 5:4 y no 4:3?

La llegada de los DVD, con películas con relación de aspecto 2.35:1 y 16:9 trajo los primeros televisores 16:9 de tubo. Dado que en España las emisoras nunca se han propuesto emitir en serio en PALplus, era para lo único que servían, para ver DVDs. Por cierto, ¿soy el único en el mundo al que le desagrada extremadamente ver emisiones 4:3 achatadas hasta la exageración en lugares públicos y casas de amigos?

Poco a poco, se fueron introduciendo en el mercado monitores LCD, portátiles y televisores con relaciones de aspecto 16:10 y 16:9.

En el mundo de la informática, la relación de aspecto 16:10 es la que está partiendo la pana ahora mismo. La mayoría de portátiles tienen resolución nativa 1280×800 (WXGA), 1440×900 (WXGA+) o 1920×1200 (WUXGA) y en sobremesa, 1680×1050 (XSXGA+) también se ha popularizado en LCDs de 20″-22″. Y es curioso que sean tan populares, porque cualquiera puede darse cuenta que a igualdad de diagonal, una pantalla cuadrada tiene más área que una rectangular, por lo que a menos que el mayor uso de nuestro ordenador sea ver películas, una pantalla alargada , además de que suele ser más incomoda para trabajar, tiene menos área de trabajo. Pongamos un ejemplo en el que la pantalla alargada parte con un poco de ventaja por tener 0.4″ más de diagonal:

Típica pantalla 16:10 de 15.4″ de diagonal:

15.42=(16x)2+(10x)2 → x=0.8162"=2.0731cm

Área=16x·10x=678.67cm2

Típica pantalla 4:3 de 15″ de diagonal:

152=(4x)2+(3x)2 → x=3"=7.62cm

Área=4x·3x=696.77cm2

En cualquier caso, al final esto es algo en lo que los usuarios finales tienen poco poder de decisión, ya que si los grandes departamentos de marketing han decidido que al usuario le atrae más una pantalla alargada que una cuadrada, pantallas alargadas tendremos hasta en la sopa.

Sigue leyendo »

Tema LHYLE09, creado por Vicente Navarro