madTeleco

Finalment he trobat el que cercava:

• scim (Gtk). Hi ha paquets a Debian. Encara m'acabaré passant al gnome...
  
• skim (Qt). Basat en l'scim.
  
• scim-qtimm (Qt, mòdul per immodule).

I també n'hi ha d'altres (varis per Gtk...).

Són projectes per a un Input Method bastant menys cutre que el kinput2 (com vaig dir, amb el kinput2 activat no funcionen les dead-keys) Els de KDE es troben en desenvolupament actiu i segurament fins a les Qt 3.4 com a molt prest no hi haurà rès oficial per part de Trolltech. A la branca Qt 3.3.x ara només hi eliminen bugs.

N'estic fins els nassos dels servidors SMTP que filtren per resolució de domini. No serveix de rès!!

Logs de l'exim4:

2004-09-29 15:40:00 1CCega-0006Vq-SK <= XXX@madteleco.net U=miquel P=local S=562 id=20040929134000.GA24855@madteleco.net
2004-09-29 15:40:01 1CCega-0006Vq-SK Remote host mx-ha01.web.de [217.72.192.149] closed connection in response to HELO azathoth
2004-09-29 15:40:01 1CCega-0006Vq-SK Remote host mx-ha02.web.de [217.72.192.188] closed connection in response to HELO azathoth
2004-09-29 15:40:01 1CCega-0006Vq-SK == XXX@web.de R=dnslookup T=remote_smtp defer (-18): Remote host mx-ha02.web.de [217.72.192.188] closed connection in response to HELO azathoth

Provant-ho amb el netcat:

miquel@azathoth:~$ nc 217.72.192.149 25
220 WEB.DE
helo madteleco.net
554 Transaction failed. For explanation visit http://freemail.web.de/reject/?auswahl4=62.43.2.142

WTF!!

[...]
Use of an IP address without a reverse DNS entry for E-Mail dispatch:
WEB.DE does not accept any E-Mail on its incoming mail servers originating from IP numbers without a resolvable DNS entry. Update your DNS zone files and afterwards contact us to re-evaluate your IP number(s).
[...]

Esper que vos adoneu, capullus, de que el bloqueig de dominis m'obliga a:

a) Fer relay a un smarthost reconegut per vosaltres,
b) o bé, contractar un domini on pugui canviar ràpidament i automàticament la IP dels camps A i MX (la meva IP és assignada dinàmicament i pot canviar).

Evidentment un spammer professional pot, fàcilment i de manera relativament barata, passar-se pel forro tant els punts a) com b).

Es pot argumentar que d'aquesta manera s'evita l'spam provinent de les màquines zombies. Però els falsos positius d'aquest sistema de bloqueig arriba al 30%-40% la darrera vegada que vaig llegir sobre el tema.

MORAL: No filtreu ni per blocs IP ni per dominis ni per resolució inversa de domini. En general cal esser molt reticent dels mètodes de filtrat que empren fonts d'informació externes. Cal dissenyar el sistema de correu tenint en compte el grau de falsos negatius i falsos positius que trobeu acceptable, no al tun-tun.

El firefox/mozilla em permet escriure els kanas però no surt la finestra amb els possibles kanji a triar. Des del principi sabia que era un conflicte QT-GTK, o GTK-kinput relacionat amb la gestió de l'entrada de teclat. I efectivament (Bug 90082: Input Methods need to receive any key evnet) [bugzilla.gnome.org]:

[...]
------- Additional Comment #2 From Owen Taylor 2002-08-09 08:12 -------
Bumping priority back down because I have no idea how we can fix this ... best idea so far is that GtkIMContextXIM could connect to ::key-press-event on the toplevel window on focus-in and intercept key events until focus out, but that won't work for things like widgets embedded within a Plug/Socket combination.

[...i després de molta discussio i varis patches...]

------- Additional Comment #25 From ynakai@redhat.com 2004-07-15 05:30 -------
Any progress?
[...]

En altres paraules: el mateix bug de fa dos anys encara està "actiu". Igual que tot el tema d'escritura en múltiples alfabets. Mentrestant segueixo d'aprop del desenvolupament de l' im-ja.

Pel que sé, no és que els xinesos, japonesos, etc. no emprin linux, sinó que utilitzen normalment distribucions d'allà, i a més amb tota la localització en el seu idioma.És curiós notar que s'ha reprès el desenvolupament d'aquest tema des de la notícia dels governs asiàtics d'impulsar linux (gnu/linux?).

I aquesta setmana a més se n'ha parlat a la llista debian-devel. I en concret sobre la falta de coordinació en el tractament d'scripts personalitzats des dels diferents Desktop Managers: XDM, GDM, KDM, WDM shootout :-) [lists.debian.org].

Després d'una tarda més o menys profitosa he aconseguit adaptar l'escritori als meus requeriments amb un moderat èxit. L'objectiu era mantenir la localització (internacionalization - i18n) original del meu GNU/Debian Sid amb KDE (i.e. menús, dates, manuals, etc. en anglès) i alhora ser capaç de llegir i escriure el japonès (multilingualization - m17n) amb tota naturalitat.


El primer de tot és configurar adequadament els locales, "apt-get install locales", i sel·leccionar les que ens interessin, més aquestes (o almenys la EUC):

ja_JP.EUC-JP EUC-JP
ja_JP.UTF-8 UTF-8

Per sel·leccionar-les es pot emprar "dpkg-reconfigure locales", seguit de "locale-gen". El document de Ricardo Galli sobre còm configurar l'€uro al KDE pot servir de referència per aquest punt.

Per a gestionar varies escritures existeix el projecte im-ja, el qual ofereix un IME semblant al de windows. Desgraciadament no hi ha paquet oficial per Debian, i a més els paquets no oficials que he provat han donat un Segmentation Fault a l'executar l' im-ja-config.

Al final he optat pel primer que m'ha funcionat. Una combinació tradicional de canna + kinput2, més diccionaris, més totes les fonts japoneses que pogueu trobar (especialment recomanables les kochi -gothic i mincho-, sazanami, mikachan i les standard d'xfonts).

apt-get install canna canna-shion kinput2-canna edict enamdict kanjidic [fonts]

Per dir-ho molt breument, el canna és un servidor que realitza la conversió ひらがな (hiragana) a 漢字 (kanji). Per aquesta tarea evidentment són necessaris els diccionaris. El kinput s'encarrega de connectar l'aplicació amb el servidor canna i d'oferir-nos les possibles el·leccions gràficament.

Jo normalment inicio l'entorn gràfic amb un startx des de la consola. D'aquesta manera cal editar el fitxer d'usuari ~/.xinitrc amb:

export LC_ALL=ja_JP
export XMODIFIERS="@im=kinput2"
kinput2 -canna &
[...]
startkde

I quan iniciem l'entorn gràfic bastarà prémer MAJUS+ESPAI per canviar entre mode d'escritura normal i mode d'introducció de caràcters japonesos. Quan introduim una sèrie de caràcters en romanji (alfabet llatí) per indicar la fonografia de l'ideograma, el servidor ens ofereix distints kanjis candidats que podem alternar amb espai. Quan tenim el que volem premem ENTER i podem seguir amb la redacció.

Anem-ho a provar al konsole:

miquel@azathoth:~/proves$ mkdir アニメ 漫画 日本語

miquel@azathoth:~/proves$ touch 手紙

miquel@azathoth:~/proves$ ls -a

.  ..  アニメ  手紙  日本語  漫画

miquel@azathoth:~/proves$ vim 手紙

miquel@azathoth:~/proves$ cat 手紙

速達の証明郵便です。

miquel@azathoth:~/proves$

Amb aquest sistema podem escriure en japonès des de [quasi] tot l'escritori de KDE. Però apareixen una sèrie de contrabancs.

El primer de tots és que la variable LC_ALL reflexa un comportament sobre la localització d'algunes aplicacions. Especialment al konsole i aplicacions de consola, des d'on les tecles d'accents no contesten. A més alguns programes que intenten fer la conversió de locales fallen, com per exemple el man. Es pot arreglar aquest problema executant "export LC_ALL=C" per tenir una consola no afectada per aquest problema. O davant del programa que ens interessa, "LC_ALL=C mutt &" per no veure la data en japonès.

Per altra banda, tant amb el mozilla com amb el firefox puc escriure en hiragana, però no m'ha resultat possible fer la conversió a kanjis. Si algú el sap resoldre seria molt interessant saber-ho.

A més, si el kinput2 es penja, l'escritori kde tindrà un petit problema per a prosseguir amb la introducció de text O:-) De fet a mi se m'ha penjat a l'escriptura de mig article (mentres feia experiments amb l'OO), i afortunadament estava escrivint-ho directament al blogger amb firefox, perquè ha estat necessari matar quasi tots els processos del kde fins deixar les X i el navegador.

Per escriure amb l'OpenOffice també s'ha de configurar el programa adequadament. Bàsicament les passes que s'han de seguir són les següents:

1. Options - Language Settings - Language. Sel·leccionar "Japanese" a "Default Languages for documents", i activar "Asian languages support". Prémer OK.
2. Options - Text Document - Basic Fonts (Asian). Configurar les fonts (a mi m'agraden les Kochi Mincho).

3. Options - openoffice.org - Fonts. Resulta que l'OO gestiona incorrectament la font per defecte. Sel·leccionar "Apply replacement table" i substituir la font que apareix pels menús de l'OO (tinc configurada la Trebuchet MS al panel de control de KDE) per una Kochi.

Amb l'OpenOffice és possible escriure els caràcters furigana sobre els kanji, amb el menú "Format - Ruby".


Bibliografia:

• How to configure an English Japanese capable Debian, per Guillaume "LoneWolf" Estival. (im-ja, oo).
  
• Estudiando japonés en Linux, (latex). Libertonia
• Japanese install configure Mepis Linux (im-ja).
  
• Prise en charge du japonais sous debian, per Charles Plessy
• A Japanese Word-Processor for Linux, per Jim Breen. (oo)
  
• Debian-Japanese List: Problems with Japanese input and KDE

TODO:

• Usar l' im-ja quan el desenvolupament sigui més estable i hi hagui paquets oficials.
• Quan escrir a la consola, no apareix cap senyalitzador del mode actual.
• Les tecles per accents no funcionen quan LC_ALL=ja_JP. Faria falta un altre sistema per evitar localitzacions indesitjades (dates en japonès al mutt...).
  
• Fer funcionar la conversió de hiragana a kanji al mozilla/firebird (i publicar-ho a bulma quan ho hagui aconseguit).
  
• A vegades surten dues finestres "Candidate Selection" en voltes d'una sola (especialment treballant amb OO).
• Sistema i17n de veritat, amb múltiples idiomes alhora.
• No sé quin efecte té tot això sobre els usuaris d'escriptoris windows, amb la codificació S-JIS. Esper que especificant-ho com UTF-8 sigui suficient.
  
• Aprendre japonès (no és escrictament imprescindible) :-)
  

Algú es demana per què a Espanya el comerç electrònic està subdesenvolupat respecte de la resta d'Europa, encara que es troba en creixement. La resposta és molt simple.

Després de comprar llibres, DVDs i hardware a les zones geogràfiques més variades del món com són el Estats Units, la República del Poble de Xina, Alemanya, el Regne Unit... encara ha d'arribar el moment en el que m'he de trobar amb un problema o un venedor sense escrúpols.

La majoria d'aquestes compres les he fetes des de llocs de subhastes electròniques, intentant evaluar sempre que sigui possible el nivell de confiança que puc otorgar al venedor a partir de puntuacions i/o comentaris d'altres compradors. El pagament sempre s'ha realitzat abans de l'enviament del producte, via Paypal o transferència bancària. Així vaig apredre el que eren els codis IBAN.

I ara que he fet una compra a una Editoria espanyola, a contrareembossament (qui és el boig que els hi dóna directament el nombre de targeta de crèdit a aquesta gent?), els desgraciats em venen després de mig any a reclamar que per culpa d'un error informàtic del transportista jo he de tornar a pagar! A que no adivinau qui era el transportista? Corr---. Si un és dolent, l'altre és pitjor.

I després de totes aquestes històries encara ens extranyam que a Espanya la gent tingui tan de recel a la compra via internet. Però en realitat el perill no és internet, sinó la incompetència d'empreses que no es prenen els seus clients seriosament. I a casa aquest problema és crònic.

N'Alan Cox ha finalitzat l'any sabàtic i torna a la seva feina i al desenvolupament del kernel de linux. A partir d'ara podrem tornar a gaudir de les branques -ac i del seu sentit de l'humor:

[*]Subject: Re: [PATCH][2.6][4/14] dvb core update
From: Alan Cox
Date: Fri, 17 Sep 2004 16:58:23 +0100

On Gwe, 2004-09-17 at 15:58, Jesper Juhl wrote:
> And I'll bet there are probably more if I could be bothered to check the
> actual files.

Lots of drivers use C++^WBCPL comments (C++ just borrowed them)

> Besides, didn't C99 make C++ style comments valid for C code as well?

Yes and this leads to such fun as

x = 4 //**/
-1;
if(x == 3)
printf("New C compiler\n");

Les editorials que s'encarreguen de la producció de llibres de text en anglès, per a consum majoritari als USA, usualment venen aquests llibres a uns preus d'escàndol.

El que fan aquestes editorials és publicar edicions més barates, amb portades de tapa blana en lloc de dura i paper de més baixa qualitat i prim. Però el contingut del llibre és el mateix excepte per un canvi de portada i alguna introducció extra en la llengua extrangera el pais de l'edició. El cost de les edicions internacionals pot ser ben bé la meitat o menys respecte de l'americà.

"For sale and distribution in the People's Republic of China exclusively (except Taiwan, Hong Kong SAR and Macao SAR)."

Amb aquest sistema els habitants dels països amb menys poder adquisitiu poden adquirir llibres que d'altra manera seria impossible comprar. Els grans perdedors d'aquesta situació són els estudiants nordamericans, amb unes edicions a l'abast de més qualitat, però el doble de cares que les disponibles a la resta de països i amb el mateix contingut.

El que cada vegada fa més gent és comprar una edició internacional en lloc de l'americana, usualment a través de llocs de subasta per internet. Com és el cas d'aquesta edició de l'RF Microelectronics que aquí present, comprada per ebay a un venedor xinès:

Bibliografia

Edició xinesa:
RAZAVI, Behzad. RF Microelectronics. Ed. Pearson Education Asia Limited & Tsinghua University Press. 2003. ISBN 7-302-07522-0. 342 pàgs. Portada blana. Paper prim (sense espuris).

Edició americana:
RAZAVI, Behzad. RF Microelectronics. Ed. Prentice Hall PTR. ISBN: 0-138-87571-5. 352 pàgs. Portada dura.

Com diu a la web de la comissió europea, secció Societat de la Informació, hi ha una consulta pública sobre la retenció de dades [PDF] relacionats amb serveis de comunicacions (internet, GSM, telefonia...):

DG Information Society and DG Justice and Home Affairs have launched a public consultation on the issue of traffic data retention. They will also hold a public workshop on this matter on 21 September 2004, in Brussels.

This is part of the open consultation process indicated by the Commission in its Communication of 16 June 2004 (see e.g. COM 2004(429)).

The intention is to identify and discuss existing data retention practices for both business and law enforcement purposes in the EU Member States, and to address the extent of the need for, and the possible characteristics of, an EU-wide regime of data retention for law enforcement purposes.

Hi ha més discussió sobre aquest tema a Slashdot.

Aquesta proposta de treball es pot considerar com una nova prova per part de la Comissió Europea per a veure fins on es pot arribar en la retenció de dades. En aquest aspecte és semblant a la legistació sobre patents que es va discutir al Parlament Europeu per ser-hi rebutjat i posteriorment aprovat per la Comissió.

La seguretat ciutadana i el perill terrorista que constantment els nostres polítics es molesten en recordar-nos són l'excusa ideal per a perdre llibertat a canvi de més por. El que hauria de ser obvi és que un pais reprimit no és l'ideal per viure-hi.

Totes aquestes mesures de control d'informació a nivell general impliquen un gran sacrifici per la nostra part a canvi d'un guany ridícul que els criminals poden fàcilment evitar amb contramesures com simple encriptació de dades.

Hi ha gent que diu estar disposada a qualsevol tipus d'acció per tal d'incrementar la seguretat i eliminar el risc d'atac terrorista. Mentida! En primer lloc s'haurien de demanar per què estan disposats a fer-ho, i en segon lloc si fan bé creient cegament en el que prometen els polítics (juntament amb els advocats i taxistes) :-)

L'huracà Ivan s'ha desviat a l'oest lleugerament de la ruta prevista el divendres passat pels centres meteoròlegs. A la imatge es pot veure la posició en espectre visible (NOAA-E) de l'Ivan el diumenge 12, i la ruta prevista inicialment el divendres i per dies successius quan tot indicava que es menjaria Forida.

La setmana passada l'huracà Frances també va donar una passada per Florida.

Després de mirar el changelog del 2.6.9-rc1 m'he adonat de l'enorme quantitat de canvis que ha sofert el sistema XFS en només una revisió del kernel. Encara no entenc com pot ser el sistema de fitxers més estable de tots els que he provat i el més inocu a les interrupcions violentes del fluxe de corrent elèctric.

Seguint amb l'Oops de l'altre dia, pareix que el problema d'assignació de memòria es va crear per un excés de fragmentació del disc dur. O almenys això diuen els desenvolupadors de SGI sobre reports iguals al meu. Els sectors són d'un tamany fixe de 4096 bytes, pel que la fragmentació ha de ser interna. Tenint en compte que tinc espai lliure al disc dur de sobra, aquest error d'assignació de memòria s'hauria de solucionar :-)

Hi ha tants de canvis respecte de l'XFS als changelogs del kernel que m'és impossible veure si s'ha corregit el bug si no és provant la darrera versió (amb el darrer release candidate esper que basti) i recreant les condicions per a l'Oops (¿?).

Mirant l'Oops de més aprop, es pot veure que peta quan l'IP apunta a xfs_bmap_insert_exlist, a l'offset 0xd2. El primer és fer un grep per saber a quin fitxer es troba definida la funció, el qual resulta ser fs/xfs/xfs_bmap.c. A continuació em baso en el procediment detallat per Denis Vlasenko i companyia [kerneltrap]:

/*
* Insert new item(s) in the extent list for inode "ip".
* Count new items are inserted at offset idx.
*/
STATIC void
xfs_bmap_insert_exlist(
xfs_inode_t *ip, /* incore inode pointer */
xfs_extnum_t idx, /* starting index of new items */
xfs_extnum_t count, /* number of inserted items */
xfs_bmbt_irec_t *new, /* items to insert */
int whichfork) /* data or attr fork */

{

xfs_bmbt_rec_t *base; /* extent list base */
xfs_ifork_t *ifp; /* inode fork pointer */
xfs_extnum_t nextents; /* extent list size */
xfs_extnum_t to; /* extent list index */

ifp = XFS_IFORK_PTR(ip, whichfork);
ASSERT(ifp->if_flags & XFS_IFEXTENTS);
xfs_iext_realloc(ip, count, whichfork);
base = ifp->if_u1.if_extents;
nextents = ifp->if_bytes / (uint)sizeof(xfs_bmbt_rec_t);
memmove(&base[idx + count], &base[idx],
(nextents - (idx + count)) * sizeof(*base));
for (to = idx; to < idx + count; to++, new++)
xfs_bmbt_set_all(&base[to], new);
}

A continuació desensemblam el codi:

# objdump -d fs/xfs/xfs_bmap.o > fs/xfs/xfs_bmap.disasm

Cercam la funció xfs_bmap_insert_exlist a dintre del fitxer .disasm:

00006170 <xfs_bmap_insert_exlist><xfs_bmap_insert_exlist>:
6170: 55 push %ebp
6171: 57 push %edi

Per trobar la línia d'interés, sumam l'offset 0xd2 a 0x6170, que resulta en 0x6242:

6242: f3 a4 repz movsb %ds:(%esi),%es:(%edi)
6244: fc cld
6245: eb a9 jmp 61f0 <xfs_bmap_insert_exlist+0x80>
6247: 89 f6 mov %esi,%esi
6249: 8d bc 27 00 00 00 00 lea 0x0(%edi),%edi

El codi de les instruccions coincideix amb el proporcionat per l'Oops: Code: f3 a4 fc eb a9 89 f6 8d bc 27 00 00 00 00 55 57 56 53 83 ec

Malauradament no sé dir de quina línia de codi prové el repz. Seguim insistint amb la creació del fitxer mig compilat en assemblador:

# make fs/xfs/xfs_bmap.s

Cercam la funció xfs_bmap_insert_exlist a l'xfs_bmap.s:

xfs_bmap_insert_exlist:
pushl %ebp

I miram de trobar la instrucció en qüestió una mica més avall, tot comparant amb l'xfs_bmap.disasm:

.L994:
leal -1(%edx,%esi), %esi
leal -1(%edx,%edi), %edi
movl %edx, %ecx
#APP
std
rep
movsb <--
cld
#NO_APP
jmp .L1010

I personalment em quedo igual que abans, sense saber a quina línia del .c pertany aquest codi. Quin conyàs. Paciència i modificam el .c:

{
[...]
ifp = XFS_IFORK_PTR(ip, whichfork);
asm("#1");
ASSERT(ifp->if_flags & XFS_IFEXTENTS);
asm("#2");
xfs_iext_realloc(ip, count, whichfork);
asm("#3");
base = ifp->if_u1.if_extents;
asm("#4");
nextents = ifp->if_bytes / (uint)sizeof(xfs_bmbt_rec_t);
asm("#5");
memmove(&base[idx + count], &base[idx],
(nextents - (idx + count)) * sizeof(*base));
asm("#6");
for (to = idx; to < idx + count; to++, new++)
xfs_bmbt_set_all(&base[to], new);
asm("#7");
}

Repetim el "make fs/xfs/xfs_bmap.s". Ara hi ha més pistes al .s:

#APP
#7
#NO_APP
addl $16, %esp
popl %ebx
popl %esi
popl %edi
popl %ebp
ret
.L1007:
movl %edx, 8(%esp)
movl %esi, 4(%esp)
movl %edi, (%esp)
call _mmx_memcpy
jmp .L1010
.L994:
leal -1(%edx,%esi), %esi
leal -1(%edx,%edi), %edi
movl %edx, %ecx
#APP
std
rep
movsb
cld
#NO_APP
jmp .L1010
.size xfs_bmap_insert_exlist, .-xfs_bmap_insert_exlist
.p2align 4,,15
.type xfs_bmap_local_to_extents, @function

L'error es troba dintre de la funció for(). El "jmp .L1010" ens torna just davant l'etiqueta 6:

#NO_APP
.L1010:
#APP
#6
#NO_APP
movl 40(%esp), %esi

Malauradament al for() es crida una altra funció, la xfs_bmbt_set_all, la qual expandeix tot el codi en assemblador i fa que ens perdem una altra vegada. Volta a començar amb el mateix a la xfs_bmbt_set_all :-)

Després d'un Oops del kernel aquesta és la notícia suplementària perfecta.

Avui la sonda Genesis ha tornat a la Terra després del seu passeig pel costat del Sol, carregada de mostres de vent solar. Bàsicament un carregament d'ions per estudiar la seva composició i entendre els efectes magnètics del sòl sobre la Terra com per exemple a la magnetització dels pols i les aurores.

Malauradament el paracaigudes no s'ha activat i ha pegat una bleda contra el terra del desert d'Utah que ni deu ni do. Com diuen a la FAQ del projecte:

What if you miss catching it and it parachutes to the ground?

If the sample return capsule lands on its own, some of the delicate collector materials will likely break, making the sample more difficult to identify and categorize. The sample would still be valuable, but it would take longer for scientists to sort through the broken pieces.

A la web de la NASA sobre el projecte hi ha un video de l'impacte de 300km/h.

Després d'actualitzar el kernel al 2.6.7 (que té fama de ser molt estable), la BIOS de la targeta gràfica (emprant un floppy autoarrancable amb DOS!) i els drivers privatius chachipirulis de nvidia, ara ja put emprar el mode AGP (8x) a través de l'NvAGP. I per rematar em trobo amb un Oops del kernel, que afortunadament no m'ha deixat la màquina congelada i que per descomptat no té rès a veure amb tot l'anterior. Però a veure qui envia un report a la LKML d'un kernel contaminat per nvidia.

Pareix que l'XFS es cau de genolls davant la gestió d'arxius grans i d'ocasionals problemes de falta de memòria. O més que falta de memòria, problemes de gestió de memòria; aquí tinc 1GB de swap sense tocar i quasi 250MB de memòria RAM fent de caché. En el meu cas per la lectura/escritura de mitja dotzena d'arxius d'uns 8 GB, amb l'Azureus (sobre java, més programari privatiu, quina causalitat, vull dir casualitat).

Es pot observar que primer ha tingut lloc un error d'assignació de memòria, presumptament per falta de memòria. Posteriorment aquest error no ha estat gestionat per l'XFS de manera, uhm, satisfactòria i apareix l'Oops. A la LKML se n'ha parlat aquí i aquí i es suposa que els de SGI s'ho estan mirant (presto).

Sep 8 20:25:51 azathoth kernel: java: page allocation failure. order:5, mode:0x50
Sep 8 20:25:51 azathoth kernel: [__alloc_pages+728/848] __alloc_pages+0x2d8/0x350
[...]
Sep 8 20:25:51 azathoth kernel: Unable to handle kernel paging request at virtual address 0001483f
Sep 8 20:25:51 azathoth kernel: printing eip:
Sep 8 20:25:51 azathoth kernel: c019d3c2
Sep 8 20:25:51 azathoth kernel: *pde = 00000000
Sep 8 20:25:51 azathoth kernel: Oops: 0000 [#1]
Sep 8 20:25:51 azathoth kernel: PREEMPT
Sep 8 20:25:51 azathoth kernel: Modules linked in: nls_cp437 sd_mod vfat fat snd_seq_oss snd_seq_midi_event snd_seq nls_iso8859_1
isofs nvidia ipt_MASQUERADE iptable_nat ipt_REJECT ipt_state ipt_LOG ipt_limit iptable_filter ip_tables 8250 serial_core w83627hf
i2c_sensor i2c_isa i2c_dev i2c_core snd_via82xx snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_mpu
401_uart snd_rawmidi snd_seq_device snd soundcore dv1394 video1394 ohci1394 raw1394 3c59x via_rhine mii crc32 usb_storage usbhid u
hci_hcd usbcore
Sep 8 20:25:51 azathoth kernel: CPU: 0
Sep 8 20:25:51 azathoth kernel: EIP: 0060:[xfs_bmap_insert_exlist+210/224] Tainted: P
Sep 8 20:25:51 azathoth kernel: EFLAGS: 00210602 (2.6.7)
Sep 8 20:25:51 azathoth kernel: EIP is at xfs_bmap_insert_exlist+0xd2/0xe0
Sep 8 20:25:51 azathoth kernel: eax: 0000a850 ebx: c4abba2c ecx: 00009ff0 edx: 00009ff0
Sep 8 20:25:51 azathoth kernel: esi: 0001483f edi: 0001484f ebp: 00000a86 esp: c4abb82c
Sep 8 20:25:51 azathoth kernel: ds: 007b es: 007b ss: 0068
Sep 8 20:25:51 azathoth kernel: Process java (pid: 22342, threadinfo=c4aba000 task=c6f2d990)
Sep 8 20:25:51 azathoth kernel: Stack: db0a6330 00000001 00000000 00000000 df850000 00000a85 00000030 db0a6330
Sep 8 20:25:51 azathoth kernel: c019a2a8 db0a6330 00000a85 00000001 c4abba2c 00000000 c01d1c71 df850000
Sep 8 20:25:51 azathoth kernel: df850000 df850000 df5fd158 c01d4232 00000000 00000000 00000000 00000000
Sep 8 20:25:51 azathoth kernel: Call Trace:
Sep 8 20:25:51 azathoth kernel: [xfs_bmap_add_extent_hole_delay+824/1328] xfs_bmap_add_extent_hole_delay+0x338/0x530
Sep 8 20:25:51 azathoth kernel: [xlog_assign_tail_lsn+33/128] xlog_assign_tail_lsn+0x21/0x80
Sep 8 20:25:51 azathoth kernel: [xlog_state_release_iclog+34/224] xlog_state_release_iclog+0x22/0xe0
Sep 8 20:25:51 azathoth kernel: [xfs_bmbt_get_state+47/64] xfs_bmbt_get_state+0x2f/0x40
[...]
Sep 8 20:25:51 azathoth kernel: Code: f3 a4 fc eb a9 89 f6 8d bc 27 00 00 00 00 55 57 56 53 83 ec

Al jugar amb el Quake3 la pantalla s'ha congelat i el sò bloquejat i repetint-se en un bucle infinit. Un símptoma clar de problemes als drivers ALSA, o als drivers de NVIDIA. Possibilitat d'enviar un report a qualsevol banda d'un kernel tainted per nvidia i que em facin cas: zero. Després de matar el procés del quake3 des d'una consola, el servidor d'X rep el senyal de SIGHUP i mor.

Aproximadament, el que vol dir és que el servidor X es desconecta del terminal on s'ha iniciat. El kernel hi envia aquest senyal per a que rellegeixi la configuració. I Crakcatapum!. Diria que el problema és dels drivers de la targeta gràfica, o al menys la "T" corrupta resulta bastant sospitosa (podria ser pel canvi de mode gràfic :-? ). Aquests drivers propietaris són bazura.

El dia 6 de març de 1997, Microsoft va entregar una petició de patent. La patent en qüestió, la nº 6,785,865 fou validada i expedida el passat dia 31 d'agost per la USPTO dels USA. Es titula "Discoverability and navigation of hyperlinks via tabs". O com diu la seva descripció:

A user may discover and navigate among hyperlinks through the use of a keyboard. For example, a user may press a tab key to discover and navigate to a first hyperlink that is part of a hypertext document. The first hyperlink is, in response, given focus and a focus shape is drawn around the text or graphics for the hot region of the hyperlink. If the user again presses the tab key, the next hyperlink is given focus and a focus shape (i.e., an outline that surrounds the next hyperlink) is drawn around the next hyperlink. A user may also tab to a placeholder for an image in order to make a decision whether the image should be downloaded or not.

És acollonant fins a quins límits ridículs i absurds ha arribat el sistema de patents de software. Vull dir, al 1994 ja existien browsers com el Mosaic o el lynx, i ambdós permetien navegar amb el teclat sense problemes. Especialment el lynx (i altres), que és en mode text per consoles. Jo llavors no sabia ni el que era TCP/IP. No va ser fins un parell d'anys després que el meu papi (jo encara feia l'EGB) em va comprar un modem a 14400bps i m'otorgà una certa carta blanca amb limitacions i vigilància contínua sobre l'ús que en feia de la línia telefònica.

Desafortunadament l'època de les BBSs ja havia passat. Però va arribar una cosa millor. Una xarxa anomenada Internet que contenia múltiples màquines enllaçades entre sí. Interessant per mi en aquell temps pel contingut elevat de documents acadèmics, howto's i material didàctic que hi podia trobar. Apart d'altres aventatges per la comunicació com l'email i l'IRC.

És impressionant que ara vingui Microsoft i patenti l'ús d'una tecla per navegar sobre els enllaços d'una pàgina web o sobre un llistat d'arxius. Només falta que patentin el control-alt-supr. Sobretot quan durant aquells primers anys només repetien una i altra vegada que Internet era una inútil parida que s'esvairia sense èxit. Evidentment uns anys després, al voltant del 97/98, a Redmond es van adonar de l'errada i en Bill Gates va corregir la seva profecia amb un gir de pi radians.

Els de l'Oficina de Patents (de qualsevol part, en general) sembla que es fiquin cavall a l'hora de revisar les peticions. Però ni n'Edgar Allan Poe, en moment de màxima concentració i estat de pre-coma etílic, deixaria passar tot aquest fems.

Nota: M'he adelantat per dos dies i mig a slashdot :-P