L’home dibuixat

vi Complete Key Binding List. No és un tutorial, sinó una guia de referència de totes les combinacions de tecles que fa servir l'editor vi.

\b(([\w-]+://?|www[.])[^\s()<>]+(?:\([\w\d]+\)|([^[:punct:]\s]|/)))

Vist a A Liberal, Accurate Regex Pattern for Matching URLs.

Unicode 5.2 Character Code Charts, codis ASCII i una segona taula de codis ASCII.

Una de les coses que sempre em sorprèn del Microsoft Word es que ja pots portar molts anys utilitzant-lo a diari, que ben segur et reserva una sorpresa…

Aquest matí en editar els documents fets amb una plantilla concreta, la mida del cursor es modificava. Enlloc de ser l'habitual barra vertical intermitent, era un petit punt negre, també intermitent. Molt poc pràctic per veure on es troba el punt d'edició.

La solució per restaurar el cursor a la seva mida estàndard?

"Canviar el zoom del document al 500% i, a continuació, tornar al 100%"

Dit i fet. Ha funcionat.

Estic veient que, des de fa uns dies, les entrades d'aquest bloc surten duplicades a Bloglines. És a dir, cada vegada que Bloglines baixa la font RSS enlloc de detectar les entrades ja existents, les considera totes com a noves i les afegeix a les ja existents.

No sóc l'únic bloc al que li està passant això –també ho estic notant a d'altres llocs on estic subscrit–, però no tinc ni idea de quina és l'origen del problema. Certament fa que la lectura del bloc via Bloglines sigui molt pesada.

De moment, l'únic que he pogut veure és que només passa als que estan subscrits a l'adreça directa de la font RSS del bloc (http://caballe.cat/wp/feed/). Els que estan subscrits a la font RSS via FeedProxy (http://feedproxy.google.com/CaballeCat) no tenen aquest problema.

En un principi he pensat que el problema podia estar relacionat amb la migració a WordPress 2.8.5, però ho puc descartar ja que no succeeix amb la font RSS del Diari d'un Llibre Vell.

Actualització: Identificat el problema.

Fa uns dies em vaig adonar que rebia determinades visites adreçades a les URL "lletges" que genera WordPress (per exemple http://caballe.cat/wp/?p=6215 enlloc de http://caballe.cat/wp/google-shell/). Havia detectat que aquestes URL "lletges" es trobaven dins del RSS, generades per la presència d'aquesta instrucció al fitxer wp-includes/feed-rss2.php:

<guid isPermaLink="false"><?php the_guid(); ?></guid>

Fa uns dies vaig eliminar aquesta línia i, d'entrada, no vaig veure cap efecte negatiu. El XML de la font RSS semblava correcte i el Planeta Softcatalà el processava correctament.

Quan el mai9 em va avisar del problema, d'entrada no vaig recordar aquest canvi. Per això no ho vaig associar directament. Ahir a la tarda vaig restaurar la versió original del fitxer i per això s'ha solucionat el problema.

Em penso, de totes formes que potser enlloc d'esborrar-la l'hauria d'haver canviat per:

<guid isPermaLink="false"><?php the_permalink_rss() ?></guid>

d'aquesta forma, els lectors de fonts RSS podrien mantenir l'associació de posts amb la seva URL correcta. Ho provaré amb una web de prova…

Citació a la Història Universal del Estado

Trobat via Google Llibres. La referència és errònia, però, ja que la digitalització no és del document imprès a Barcelona el 1716 sinó d'una reedició feta a Girona el 1775.

Un dels (molts) usos que faig de Gmail és com a dipòsit de còpies de seguretat. Cada dia, de forma automàtica, envio una còpia de la base de dades a un dels comptes de Gmail. Així, en una situació de crash total del servidor hi ha una còpia externa a la que hi puc accedir des de qualsevol lloc.

Fins ara tot perfecte… però avui he arribat a omplir la bústia. No semblava afectar a la recepció de missatges, però no en podia enviar de nous.

He començat a esborrar les còpies antigues (de fa més de dos anys), però certament era una mica pesat. Així que he mirat a l'ajuda com esborrar els missatges anteriors a una data.

És ben simple: l'opció de cerca before:YYYY-MM-DD. D'aquesta forma, cercant els missatges amb:

(database-backup és l'etiqueta que assigno automàticament als missatges que contenen la còpia de seguretat de la base de dades)

Amb això tinc tots els missatges amb la còpia de seguretat de la base de dades anteriors a l'1 de gener. A continuació, els selecciono tots, botó "suprimeix" i buidar la paperera.

Ja torno a tenir espai

Decàleg per a una bona argumentació: Diez consejos para argumentar bien o decálogos del buen argumentador.

[Make HackZine] Gain admin rights in OS X Leopard.

No és la pirateria informàtica… sinó la més principal accepció del terme pirateria (Pràctica de l'assalt i robament d'embarcacions i mercaderies a alta mar o del saqueig de poblacions costaneres). Un mapa que mostra tots els llocs on s'ha informat d'un acte de pirateria durant l'any 2008: Live Piracy Map 2008.

Malgrat que un es pot pensar que al segle XXI aquesta podria ser un problema més aviat puntual o reduït a zones molt concretes (el corn d'Àfrica la Banya d'Àfrica, com no para de sortir a les notícies darrerament), veient el mapa sembla que moltes costes són encara avui força complicades… i que hi ha incidents fins i tot aquí al costat: el 24 d'agost passat hi va haver un abordatge a Còrsega.

Qui treballa normalment amb equips Windows de forma remota segur que està ben familiaritzat amb aquest missatge:

La raó és ben simple: en modalitat d'administració Microsoft limita la funcionalitat a només dues connexions obertes. Sovint, però, les sessions queden penjades sí, com jo faig sovint, per sortir tanqueu la finestra i no feu una desconnexió de la sessió.

Si la màquina està dins del mateix domini, la solució és ben simple: executar el Terminal Services Manager i desconnectar alguna de les sessions que han quedat penjades.

En cas que no estiguin al mateix domini, el que cal fer és el següent:

• Des d'una màquina que tingui connexió per NetBIOS establir una connexió:
  net use /user:[usuari] \\[servidor]\ipc$
• Determinar quines sessions hi ha obertes:
  query session /server:[servidor] veurem un resultat com aquest:
  
• La columna ID ens informa de l'identificador de sessió (una bona candidata és la número 2, a l'exemplea anterior). Per desconnectar-la cal executar
  reset session 2 /server:myserver
• Com a resultat de reset no veurem res per pantalla, però si tornem a executar el query session podem comprovar que la sessió ha estat desconnectada:
  

Linux package management cheatsheet és una taula que recull com realitzar les operacions bàsiques de gestió de paquets a les diferents distribucions de Linux.

[Linux Journal] Rebooting the Magic Way. Això sabia que es podia fer, però entre una cosa i l'altra mai havia mirat com. Avui m'ha arribat per casualitat i he cregut interessant apuntar-ho.

Que es pot fer quan falla el disc d'un servidor i no es pot reiniciar?

    # reboot
    bash: /sbin/reboot: Input/output error

    # shutdown -r now
    bash: /sbin/shutdown: Input/output error

Bé, Linux incorpora un mecanisme per a forçar l'operació de reiniciar el sistema operatiu sense que calgui cap mena d'accés al disc. És el que s'anomena Magic SysRq Key i correspon a la tecla SysRq (PetSis als teclats en castellà), que inicialment estava pensada per a poder aturar el sistema però que ni el DOS i Windows mai no han utilitzat (l'OS/2 tampoc, ja que el bolcat de memòria i reinici era amb la tecla Control-Control-BloqNum). Està disponible sempre que el nucli s'hagi compilat amb l'opció CONFIG_MAGIC_SYSRQ.

D'aquesta forma es poden enviar ordres al nucli del sistema operatiu a través de /proc. Per utilitzar-la, el primer que cal fer és activar-la:

    echo 1 > /proc/sys/kernel/sysrq

I, quan estiguem preparats per reiniciar la màquina, executar això:

    echo b > /proc/sysrq-trigger

En aquest moment, el nucli del sistema operatiu es reinicia sense fer cap dels passos que habitualment es realitzen en una operació d'aturada normal, com buidar les memòries intermèdies, desmuntar els sistemes de fitxers, etc…

Altres usos que permet aquesta funció són fer un bolcat de la memòria, forçar l'operació de sincronització dels sistemes de fitxers, matar tots els processos menys init…

Aquest és un d'aquells trucs que cal tenir sempre a mà… per veure quina és la contrasenya d'una pàgina web emmagatzemada pel navegador.

Senzillament hem d'anar a la pàgina i esperar que el navegador ompli els camps del formulari. A continuació executem aquest codi JavaScript a la barra d'adreces:

javascript:(function(){var s,F,j,f,i; s = ""; F = document.forms; for(j=0; j<F.length; ++j) { f = F[j]; for (i=0; i<f.length; ++i) { if (f[i].type.toLowerCase() == "password") s += f[i].value + "\n"; } } if (s) alert("Passwords in forms on this page:\n\n" + s); else alert("There are no passwords in forms on this page.");})();

I esbrinarem quina és la contrasenya. Això funciona amb l'Internet Explorer, Firefox, Netscape i Opera.

Si fem servir el Firefox, aquest codi JavaScript:

javascript:var els = document.getElementsByTagName('input'); for(var x=0; x<els.length; x++){ if(els[x].type.toLowerCase() == 'password' ){ var test = els[x].type = 'text';}}

substitueix els punts que amaguen la contrasenya pel seu equivalent en text clar.

Igualment, una forma ràpida d'accedir al gestor de contrasenyes del Firefox sense passar per tots els menús és chrome://passwordmgr/content/passwordManager.xul.

Per tant, recordeu sempre de bloquejar el vostre ordinador quan no esteu al davant!

Vist a What's My Pass.

Per a referència pròpia:

• Client Certificate Authentication With Apache (An Example)
• Using Client Certificate Authentication with IIS 6.0 Web Sites