Diuen els de Pimpampum:
Taller de Google Maps
De 19.00 h a 22.00 h.
La sessió es centrarà en la creació d'elements gràfics sobre els mapes del món,
amb una intenció artística. Entre d'altres es faran servir eines com la creació
de línies (polylines) o la superposició d'elements gràfics (bitmaps) creats per
l'ocasió aprofitant el fet de poder associar-los a qualsevol lloc del món.
I més coses.
Ens hi veiem.
Ahir vaig jubilar el KNotes. Des que em vaig passar a KDE el feia servir. Té un parell d’avantatges sobre els post-its: no mates arbres, no se’t queden amagats sota el teclat i els pots replicar des de l’escriptori de la feina al de casa. Tot i així, no m’hi acabo de trobar còmode, diria que des del punt de vista d’usabilitat és millorable.
Però ahir vaig descobrir BasKet. La interfície gràfica és la típica de les aplicacions KDE, un gustàs. Però fa coses sorprenents: a les llistes hi pots arrossegar texts, arxius, imatges, o… qualsevol objecte que el KDE sàpiga manegar. I les llistes poden ser una llista vulgaris, una checklist, una pila… i un parell de virgueries més. I això que tinc la versió 0.5; la 1.0 afegeix unes quantes features que em fan caure la baba.
De tant en tant et trobes de morros amb una aplicació que fa molt més del que esperaves i no tens ni idea de per a que l’estaràs fent servir la setmana que vé. Ara mateix tinc aquesta sensació. :-)
Fas servir BasKet? Li has trobat alguna utilitat especial? Explica, explica…
Sempre és recomanable fer instal·lacions “mínimes” per als servidors. Això redueix la probabilitat de que una actualització trenqui res, perquè tenim menys coses per trencar. Simple, oi?
Però tot té un preu, i una de les ocasions en què el pagues és quan tens un programa que no està empaquetat, i que per tant no fa una gestió “decent” de les dependències, i aquest programa assumeix que hauràs instal·lat el sistema operatiu amb “full equipment”.
Un exemple: l’instal·lador de Matlab. Concretament, l’instal·lem en una maquineta de 64 bits que duu la distro “Scientific Linux” (recompilació dels paquets de RedHat).
# /var/tmp/matlab/cd1/install
/tmp/9835tmwinstall/update/install/abort.sh:
line 15: /tmp/9835tmwinstall/update/install/cleanup.sh:
No such file or directory
Ja podem esmolar les eines. Fem una ullada a l’script, que no presenta cap pega, i acabem veient que peta en executar un arxiu anomenat xsetup.
ldd ens dirà a quines llibreries dinàmiques està linkat aquest executable.
# ldd /var/tmp/matlab/cd1/update/bin/glnxa64/xsetup
libXt.so.6 => /usr/X11R6/lib64/libXt.so.6 (0x0000002a95561000)
libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x0000003764c00000)
libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x0000003765800000)
libXp.so.6 => not found
libmwins.so => not found
libc.so.6 => /lib64/tls/libc.so.6 (0x0000003097e00000)
libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x0000003765e00000)
libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x0000003764e00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003098100000)
/lib64/ld-linux-x86-64.so.2 (0x0000003097c00000)
Caram, ens en falten un parell. Passem-li el nom de la llibreria al yum i ja buscarà ell quin paquet ens cal.
# yum install libXp.so.6
Fem una ullada a totes les ‘shared llibraries’ instal·lades amb ldconfig.
# ldconfig -p | grep Xp.so
libXpm.so.4 (libc6) => /usr/X11R6/lib/libXpm.so.4
Però l’instal·lador de Matlab torna a petar! Perquè? Probablement, perque el yum ens ha instal·lat la versió 32 bits de la llibreria. :-( Què hi farem, ningú no és perfecte.
# rpm -qf /usr/X11R6/lib/libXp.so.6
xorg-x11-deprecated-libs-6.8.2-1.EL.13.37.5.i386
# yum install xorg-x11-deprecated-libs.x86_64
# ldd /var/tmp/matlab/cd1/update/bin/glnxa64/xsetup
libXt.so.6 => /usr/X11R6/lib64/libXt.so.6 (0x0000002a95561000)
libX11.so.6 => /usr/X11R6/lib64/libX11.so.6 (0x0000003764c00000)
libXext.so.6 => /usr/X11R6/lib64/libXext.so.6 (0x0000003765800000)
libXp.so.6 => /usr/X11R6/lib64/libXp.so.6 (0x0000002a956c4000)
libmwins.so => not found
libc.so.6 => /lib64/tls/libc.so.6 (0x0000003097e00000)
libSM.so.6 => /usr/X11R6/lib64/libSM.so.6 (0x0000003765e00000)
libICE.so.6 => /usr/X11R6/lib64/libICE.so.6 (0x0000003764e00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003098100000)
/lib64/ld-linux-x86-64.so.2 (0x0000003097c00000)
Ara si. Sembla que l’altre llibreria que ens falta és “prescindible”, perque la instal·lació es fa sense cap més entrebanc. M’agradaria saber què és aquesta llibreria…
Estem d’estrena. :-) I no sols estrenem vestit, també estrenem esquelet.
Fins ara l’esquelet d’aquesta web era Textpattern. Tot i que té moltes coses que m’agraden, té dues característiques extremadament molestes. Una és Textile, que a aquestes alçades (2.0) segueix fallant en coses bàsiques. L’altre problema és el PHP. ;-) Expliqueu-me el que volgueu, però no m’agrada. Programant en PHP no em diverteixo, ni de bon tros, tan com amb Python.
La meva desgràcia és que no hi ha cap CMS basat en Python amb una mica de cara i ulls, a banda del Plone. Però el Plone no es pot customitzar sense entendre el framework de sota, Zope. I Zope, per postres, pateix de gegantisme. Sols és escalable cap amunt, i jo sóc molt petit.
Per tant, he acabat agafant el toro per les banyes i fent un petit gestor de continguts en Python. Ni se’m passa pel cap fer-ho sense una bona base: Django és un dels frameworks per desenvolupament web de darrera generació. Docutils genera HTML (entre altres) a partir de text llegible, és versàtil i més robust que els editors WYSIWYG.
Combina-ho tot plegat, i surt un CMS petit i gairebé utilitzable. I quan necessito extendre’l puc fer-ho en Python, amb les eines de Python: el que jo volia de bon principi.
I posats a renovar també canviem l’estètica. Un vestit adaptat del tema Skittlish que va dissenyar la Cristi Balan pel gestor de continguts Mephisto.
Arrenquem sota mínims, sense parafernàlies espectaculars, sense web-dos-punt-zero, en beta-beta-beta, però arrenquem. Que sempre és divertit.
Després de l’upgrade a (K)Ubuntu Edgy el Firefox s’havia tornat “temperamental”. De tant en tant petava com una escopeta de perdigons. Serà la 2.0 aquesta, vaig pensar.
Al cap d’uns dies m’adono de que peta sempre que hi ha Flash pel mig. Desinstal·lo el plugin de Flash i el navegador torna a ser estable.
Un cop se t’encén la bombeta els de Can Google aviat et diuen perquè: sembla que ara les X venen amb el “Composite” activat per defecte. I el plugin de Flash, que deu estar compilat als anys 70, es fa la tita un lio amb el nou visual de les X. Corrupció de memòria, crash del plugin de Flash i, per tant, crash del Firefox que està executant un mal plugin. (Interessant: el Konqueror no arriba a petar; no es veu el Flash, i llestos).
Sol·lució ràpida: els de X tenen una variable d’entorn per a que una aplicació concreta no “vegi” les diferències del Composite. Posem-ho a l’arrencada del Firefox.
#/etc/firefox/firefoxrc
#workaround; avoids Flash crashing with X Composite enabled.
export XLIB_SKIP_ARGB_VISUALS=1
Ara que ja sé què buscava :-) veig que està documentat a Can KDE i que fins i tot ho havia explicat en Francesc Rosàs al seu article sobre Composite.
Hi ha unes quantes “habilitats” del Subversion que estàn força amagades a la documentació. Per exemple, ignorar automàticament certs fitxers i directoris en les operacions que fem.
Podem indicar a Subversion que ignori certs patrons allí on els trobi, evitant-nos veure’ls marcats amb interrogants cada vegada que fem un svn status.
Per exemple, treurem del mig els backups i els byte-compiled de Python afegint aquesta línia a ~/.subversion/config:
global-ignores = *.bck *.pyc
També ens permet ignorar fitxers concrets; en aquest cas, la base de dades i un directori “calaix de sastre”.
svn propset svn:ignore 'all-in-one-file.sqlite spool' .
Potser si la llista de fitxers és llarga resultarà més còmode picar-la amb un editor. Recorda, un fitxer per línia.
$ svn propedit svn:ignore .
Vols arrencar l’Apache i a sobre de passar de tu et deixa això al error.log.
[notice] mod_python: Creating 20 session mutexes based on 20 max
processes and 0 max threads.
[error] (28)No space left on device: mod_python: Failed to create
global mutex 0 of 20 (/tmp/mpmtx305410).
Segurament tens així la directiva AcceptMutex d’Apache::
AcceptMutex sysvsem
que, casualment, és el valor per defecte de Debian. Si estàs servint una aplicació amb tendència a causar genocidis dels fills de l’Apache potser t’has quedat sense semàfors. I ara què? Truquem a la Guàrdia Urbana?
Per defecte, el nombre d’arrays de semàfors al kernel de Linux és 128:
# ipcs -ls
------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767
Pots pujar aquest valor amb sysctl o al /proc; el paràmetre del kernel que has de tocar és el kernel.sem. Però valdria més fer neteja dels semàfors que s’han quedat “tirats” i ningú està fent servir.
Atura l’Apache. Fes una ullada als semàfors que ja no haurien d’estar ocupats.
# ipcs -s | grep www-data
Ara, mira fixament aquests semàfors i digue’ls: “Això em fa més mal a mi que a vosaltres”. I endavant, BOFH.
# ipcs -s | grep www-data | cut -d' ' -f2 | xargs -n1 ipcrm -s
Naturalment, pots fer un ipcrm -s de cada semaphore-id, un a un. Però això limitaria innecessàriament l’abast dels teus errors.
Després de l’upgrade de Ubuntu Breezy a Ubuntu Dapper quedaven un parell de coses que es resistien a funcionar. L’escpritori és KDE, però instal·lat a base de ‘aptitude install kubuntu-desktop‘ en lloc d’instal·lar directament una Kubuntu.
Que Google no va. Què estrany, no carrega. L’hauràn apagat? O serà un problema de xarxa del portàtil? El mòdul es carrega, perquè amb ‘ip addr’ mostra la interficie.
Que curiós. En lloc de dir-se ‘eth0′ ara es diu ‘eth1′.
Seràn els scripts de ‘/etc/network/’? O els paràmetres de ‘/etc/modprobe.d/’? Sembla que no.
I aquest arxiu?
$ cat /etc/iftab
# This file assigns persistent names to network interfaces. See iftab(5).
eth0 mac 00:0a:e4:aa:bb:cc
Aquesta MAC no és la de la tarja ethernet! Agafem la que escup ‘ip addr’, modifiquem el fitxer…
# modprobe -r 8139too
# modprobe 8139too
# ifup eth0
Mira: ja han tornat a engegar el Google.
Li enxufes la memòria USB, i ni cas. Li poses un CD, i com qui sent ploure. Això serà cosa del ‘hotplug’, o del ‘udev’ o una cosa rara d’aquestes. Perque la Dapper treia del mig el ‘hotplug’, oi?
A veure com anem de kernels…
$ uname -r
2.6.12-10-686
Apaaa! Despistat!
# aptitude install linux-image-2.6.15-25-686
Que no va, tu. Que arrenca, que veu tots els àlbums, però que li dono al botó de “play” i aquí es queda. I mira que apreto fort, eh?
I el so si que funciona, perquè configurant l’xmms amb ‘output plugin = aRts’ tinc musiqueta.
A veure això…
# aptitude install kdemultimedia
$ pkill amarok
$ pkill artsd
Ah, doncs ara si.
“Pseudoxml” és una forma distesa de referir-se a aquelles sintaxis que converteixen el text pla a HTML, tags inclosos (a.k.a. “plaintext markup syntax”). Posats a generar contingut per la web, són exponencialment més agradables que picar HTML pelat i molt més robustos i portables que els editors WYSIWYG que trobem habitualment.
Aquest text està generat (originalment) patint Textile. És adequat per composicions molt senzilles, però té uns quants “problemets” d’aquells que provoquen enrabiades suficients per disminuir-te l’expectativa de vida.
Des del punt de vista dels tipus d’usuari, li demanaríem a l’eina que fos:
Com que la idea és fer fàcil allò que ha de ser fàcil, la sintaxis dels pseudo-tags és intencionalment simplista. Però tant, que certes coses són impossibles. Com convertir en un enllaç mitja paraula (per exemple, a muggle-friendly enllaçar sols muggle). O subratllar una paraula que va entre parèntesis.
_(textpattern)_
No ens escudem amb que “els muggles no fan aquestes coses”. És cert, no les fan però les demanen.
Primer disgust. Què és el primer que voldrà fer un geek respectable? Penjar codi, naturalment. Acabarà amb una llaga d’estómac.
Tot i que li prohibeixis, Textile s’entossudeix a parsejar certs caràcters. Penjar un codi en Python és tot un desafiament, fins al punt de que per poder publicar
a = array[0]
sense que es confongui amb els “[“… va caler un patch (!) i carregar-se la creació de “footnotes”.
Segon disgust. Un geek no es conformarà amb publicar una imatge: això té poca densitat d’informació. Voldrà una imatge amb un enllaç. En l’idioma de Textile serà
!/common/textist.gif(Textist)!:http://textism.com
Un punt a favor, per que l’opció està contemplada. I mig punt en contra de Textile: la sintaxis de tot plegat és tirant a illegible.
Tercer disgust. Si el pobre paio vol incloure RDF en el text generat… ni ho explico, no cal caure en el “morbo” fàcil.
La impressió final és la d’una sintaxis poc planificada i una eina que no s’ha testejat a fons. Pot ser suficient per usuaris que “sols volen un blog” o per un petit fòrum amb “markup” limitat, però per generar continguts amb cara i ulls ens posarà la traveta. Depenem massa de “truquets” que ens vagin solucionant problemes puntuals. Un exèrcit de problemes puntuals.
Comencem a buscar-li un substitut.
Quan surt una nova versió d’un programa seria un rotllo tornar a traduir tooots els strings que no han canviat des de la versió anterior. Quina mandra.
El gtranslator permet que “l’entrenem” amb la traducció antiga, i després tradueix màgicament el que ja coneix.
$ gtranslator -l old.po
En Benjamí i la “tribu” de traductors del WordPress al català m’han fet adonar que tenim una memòria de traducció enorme al projecte Gnome. Clar que baixar-se 110 fitxers a mà deu fer mandra, oi?
Doncs siguem mandrosos.
$ wget -r -l1 -np -A.ca.po
http://l10n-status.gnome.org/gnome-2.14/PO/
$ find . -name '*.ca.po' | xargs -n1 gtranslator -l