|
Aquesta llarguíssima sèrie de columnes (part 1, part 2, part 3, part 4, part 5 y part 6) Va tenir un final aquí. Podria estendre més sobre altres elements de l'escriptori semàntic, però no podré contestar els arguments que es donen en carregaments de guies escampades al llarg i ample de l'Internet que aconsellen sobre les millors maneres de desactivar l'escriptori semàntic, perquè menjaria memòria a preu fet . |
No es preocupin, que l'única manera en què podran tenir una captura com la que veuen en un sistema on Nepomuk funciona adequadament com el meu, és que facin el mateix que jo: es baixin 1 GB en arxius PDF de text que tenen 13 milions d'adreces i els passin per l'indexador Nepomuk (no és broma, ho vaig fer). Tampoc crec que vostès manegen PDFs de literalment milers de pàgines (per la meva feina com a advocat he de gestionar la Història de la Constitució Xilena, 10 PDFs de 1.200 pàgines de text cada un), així que, en un sistema correctament configurat, no haurien de veure aquesta captura mai.
Ara pongámosnos seriosos i tècnics. No és hora d'un altre tutorial més de "desactivi Nepomuk per obtenir bon exercici", sinó del primer tutorial a l'Internet de "com obtenir un gran acompliment amb Nepomuk activat". Estigueu atents.
prerequisits
Potser això va haver d'haver anat primer a la meva guia, i ho sento, però és que havia de justificar per què el JavaScript Nepomuk (que va ser el que vaig fer en les primeres sis entregues) abans de dir-los com activar-correctament. Per això, farem una passejada respecte del que es necessita, i després, anem a configurar.
En primer lloc, cal que siguem estrictes amb les distribucions que farem servir. Aquí hi ha requisits ben clars: les distribucions que agraden d'incorporar programari obsolet no serveixen per a KDE, i això lamentablement inclou Debian. Gràcies a l'enorme treball de Rex Dieter, líder d'l'equip Fedora KDE, hi ha un set de paquets amb KDE 4.10 per a Red Hat Enterprise Linux 6, així que, si necessiten KDE i una distribució estable com la pedra, l'opció és RHEL 6, o un clon de RHEL 6 com a CentOS, amb aquest repositori activat.
En segon lloc, cal estar atents a com s'empaqueta KDE, perquè KDE és extremadament sensible a el mal empaquetat. Fins fa poc, Kubuntu era famós per incórrer en errors grotescs de paquets, a l'barrejar versions no compatibles de paquets necessaris, el que portava com a conseqüència una horrible experiència en Kubuntu i que la gent es preguntés per què Nepomuk era tan lent i consumia tanta memòria , quan en realitat la culpa era de l'empaquetador. La cadena de transmissió de Nepomuk i Akonadi és aquesta (usant els noms de projectes de projects.kde.org i les últimes versions)
kdelibs (4.10.4)
nepomuk-core (4.10.4)
kde-runtime (4.10.4)
nepomuk-ginys (4.10.4)
shared-desktop-Ontologies (0.10.0)
soprano (2.9.1)
akonadi (1.9.2)
Atenció als últims 3: no depenen de la versió del KDE utilitzada, i han de ser les últimes disponibles, tot i que es faci servir una versió de punt estable. La regla és: KDE utilitza l'última versió estable d'aquests paquets en la seva branca estable, i snapshots git en les seves branques beta. Molts repositoris extra d'actualització del KDE s'actualitzen KDE, però no aquests tres últims paquets, el que ocasiona problemes greus.
A això se suma Strigi, tret recentment de Nepomuk, que era un veritable mal de cap per a tots els que tractaven de empaquetar. Les versions noves no s'anunciaven com era degut, i Ubuntu no va empaquetar per un bon temps versions noves d'aquest programa, a tal punt, que vaig haver de armar un escàndol al blog de Sebastian TRUG perquè això es corregís. Afortunadament, aquest problema s'ha acabat en una gran part, i Strigi ja no s'actualitza molt, la qual cosa elimina el problema de la seva empaquetat.
Per això, recomano Chakra com una bona distribució índex. Manuel Tortosa, empaquetador del KDE per Txakra, sap tot això, i per això la qualitat dels paquets és bona, i l'experiència amb Nepomuk i Akonadi, sota Chakra, també ho és. Chakra té algunes limitacions serioses, com el no empaquetar per defecte programes que depenguin de GTK +, però és un bon començament.
També, com veurem a continuació, recomano encaridament una distribució que ja hagi fet el canvi de MySQL a MariaDB. Veurem per què més endavant.
Preparant el terreny
Un cop ens assegurem que complim amb tots els prerequisits, i sempre que tinguem un sistema net, farem alguns canvis en les configuracions per defecte.
Akonadi
Anem a col·locar a l'arxiu .local / share / akonadi / mysql.conf les següents línies.
sync_binlog = 1 innodb_flush_log_at_trx_commit = 1
Si aquest fitxer no existeix, iniciarem Akonadi per crear-lo, i després el tancarem. En consola:
akonadictl start akonadictl stop
¿Per què això? MySQL (o MariaDB) és la base de dades que dóna suport a Akonadi, ja MySQL no li agraden les interrupcions sobtades. Davant de qualsevol caiguda de sistema o interrupció d'energia, MySQL introduirà errors a la base de dades Akonadi, i aquests errors, acumulats, acabaran per trasbalsar al KMail, fent que el seu ús sigui insuportablement lent. Aquestes opcions fan que cada transacció sigui immediatament escrita en disc, minimitzant els riscos de corrupció en Akonadi davant d'una caiguda de sistema o corrupció. Aquesta opció causa errors amb certes versions de MySQL, però funciona molt bé amb MariaDB.
Kernel
Anem a elevar a el límit màxim el monitoratge d'arxius, per millorar substancialment el rendiment de Nepomuk. La següent opció al fitxer /etc/sysctl.conf farà la feina
fs.inotify.max_user_watches = 524288
Després d'aquestes dues coses, activarem Nepomuk. Això es fa a Preferències de Sistema | Cerca d'escriptori. Mantinguem l'ús de memòria en els ajustos per defecte i activem l'indexat de correus electrònics. No oblideu veure els consells de la part 1 respecte a com podem accelerar el indexat, i després d'això ... vegin la resta de les guies, per gaudir l'escriptori semàntic!
Manteniment
Què passa si no hem pogut evitar corrupcions de la base de dades Akonadi i Nepomuk està funcionant lent? Encara hi ha una línia de defensa que el KDE 4.10 implementar: el Netejador de Nepomuk, a més de les poc conegudes eines d'autoneteja que té Akonadi.
$ Akonadictl vacuum: "Aspira" la base de dades de Akonadi. Per aspirar, entengui: s'eliminen totes les entrades que no tenen un reflex en un recurs.
$ Akonadictl fsck: Intenta arreglar les corrupcions de les bases de dades Akonadi. Això no sempre funciona, pel que és necessari impedir que elles tinguin lloc en primer lloc. Com? Amb les opcions que ja vam veure.
$ nepomukcleaner: És un conjunt de scripts preparats per Vishesh Handa per netejar la base de dades Nepomuk, que ell va convertir a interfície gràfica. Premeu el botó "Iniciar" i oblideu-vos. Córrer aquest programa és obligatori si un està actualitzant la versió del KDE.
Amb tots els grans, en un sistema de 64 bits, i amb recursos Akonadi experimentals, la suma de Nepomuk i Akonadi consumeix al voltant de 350 MB de RAM. Molt per a alguns, però adequat, al meu entendre, per les tremendes funcionalitats que es guanyen.
Però Nepomuk encara corre molt lent pel meu gust. Què faig?
Espereu una mica. KDE 4.11 incorpora increments bestials en rendiment per Nepomuk. Això no és cap tipus d'exageració: d'acord amb les xifres de Vishesh Handa, estem parlant del voltant de 5 vegades el rendiment del KDE 4.10 a escriptura a la base de dades, i més de 7 vegades en lectura, tot això, de mitjana . Els canvis que es veuran en el KDE 4.11 són massius i permetran que Nepomuk sigui usat, per fi, com una alternativa per a aquelles aplicacions que requereixen bases de dades.
A més, l'error que impedeix l'inici correcte de l'connector Akonadi-Nepomuk ja va ser arreglat en la branca 4.11, i el netejador Nepomuk experimentarà grans millores. Tindrem un nou indexador de fitxers Office, i podrem gaudir d'altres eines que s'aniran develando després.
Esperem que aquesta guia, ho repeteixo, l'única que trobarà sobre com aconseguir un rendiment espectacular amb Nepomuk activat, l'ajudi a tenir una configuració sense problemes, que li permeti fer el que vam veure en els lliuraments passades i molt, molt més. Gràcies per seguir-me al llarg de totes aquestes entregues, i moltes gràcies a Pablo Castagnino, per publicar aquesta sèrie. Ens veiem aviat.