Nuudelisoppa

  • WordPress: Get permalink outside the loop

    $ID = $wp_query->post->ID;
$permalink = get_permalink($ID);

    Adapted from Skippy.

  • [Ratkaisu] Englanninkielisen virheilmoituksen näyttäminen

    Lähtökohta
    Käyttöjärjestelmäni on suomenkielinen, eli locale-komennon antama tuloste näyttää seuraavalta:

    LANG=fi_FI.UTF-8
LC_CTYPE="fi_FI.UTF-8"
LC_NUMERIC="fi_FI.UTF-8"
LC_TIME="fi_FI.UTF-8"
LC_COLLATE="fi_FI.UTF-8"
LC_MONETARY="fi_FI.UTF-8"
LC_MESSAGES="fi_FI.UTF-8"
LC_PAPER="fi_FI.UTF-8"
LC_NAME="fi_FI.UTF-8"
LC_ADDRESS="fi_FI.UTF-8"
LC_TELEPHONE="fi_FI.UTF-8"
LC_MEASUREMENT="fi_FI.UTF-8"
LC_IDENTIFICATION="fi_FI.UTF-8"
LC_ALL=

    Kun suoritan Päätteestä komennon ls /asdfgh, eikä hakemistoa /olematonhakemisto ole, komento antaa seuraavanlaisen virheilmoituksen:

    ls: tiedostoa /asdfgh ei voi käsitellä: No such file or directory

    Virheilmoituksen alkuosa on suomenkielinen, kuten sen kuuluu ollakin.

    Ongelma
    Suomenkielinen virheilmoitus on hakusanana paljon tehottomampi kuin englanninkielinen virheilmoitus, kun etsin ratkaisua ongelmaan. Haluan suorittaa komennon siten, että näen sen antaman virheilmoituksen englanninkielisenä.
    Ratkaisu
    Suoritan komennon siten, että nollaan kielen komennon suorittamisen ajaksi oletukseensa, seuraavasti:

    LC_ALL=C ls /asdfgh

    Tällöin komennon antama virheilmoitus näkyy kokonaan englanninkielisenä:

    ls: cannot access /asdfgh: No such file or directory

    Komennon suorittamisen jälkeen kieliasetus palautuu ennalleen, eli virheilmoitukset ja muut tulosteet näytetään jälleen suomenkielisinä.

  • Kolumni: ReiserFS ja sen vaihtoehdot

    Maanantaina 28.4.2008 tuomittiin kalifornialaisessa oikeusistuimessa muuan Hans Reiser vankeuteen murhasta. Murhaoikeudenkäynnistään muidenkin tietoisuuteen noussut Reiser tunnettiin alkujaan Linux-käyttäjien piirissä hänen kehittelemästään tiedostojärjestelmästä, ReiserFS:stä.

    Minäkin olen ReiserFS:n käyttäjä. Olen alustanut sillä kolme osiota kiintolevyltäni: /homen, /varin ja /mnt/Arkisto -osion. Koska ReiserFS:n kehittäjää odottaa näillä näkymin vähintään 25 vuoden vankilatuomio, tiedostojärjestelmän tulevaisuus näyttää tällä hetkellä hyvin epävarmalta. Näin siitäkin huolimatta, että jotkut arvelevat Reiserin vankilatuomion vain parantavan hänen tiedostojärjestelmänsä kehitystä joko ilman häntä tai hänen avullaan vankilasta käsin.

    Kuitenkin esimerkiksi aiemmin ReiserFS:ää oletustiedostojärjestelmänä SuSE Linux -käyttöjärjestelmässään käyttänyt Novellkin on jo ReiserFS:n pääkehittäjän juridisten vaikeuksien pelottamana siirtynyt käyttämään ext3-tiedostojärjestelmää. ReiserFS:n tilanteen takia päätin hiukan tutkia mitä vaihtoehtoja sille olisi tarjolla. Ext3:n ohella varteenotettavimpia, eli juuri tällä hetkellä realistisia vaihtoehtoja ovat JFS, XFS ja ZFS. Käyn nämä seuraavassa läpi käänteisessä järjestyksessä, lopusta alkuun.

    ZFS:ää pidetään ehkäpä lupaavimpana tämänhetkisistä tiedostojärjestelmistä. ZFS:n ongelmana on kuitenkin sen käyttöä säätelevä lisenssi, CDDL. Vaikka CDDL luetaankin vapaiden lisenssien joukkoon, se ei ole GPL-yhteensopiva. Niinpä ZFS:ää ei löydy Linux-ytimestä, eikä tule löytymäänkään niin kauan kuin lisenssiä ei muuteta — eikä välttämättä sittenkään, riippuen siitä minkä version GPL:stä ZFS:n kehityksestä vastaava Sun Microsystems valitsee.

    Linuxin kanssa ZFS:ää voi kyllä käyttää, mutta se toimii silloin niinsanottuna userland-sovelluksena, eli ytimen ulkopuolella. /homen kaltaisen, ei-kriittisen osion kohdalla tällainen menettely tiedostojärjestelmän kanssa ehkä vielä joten kuten menettelisi. /var-osion olisi kuitenkin syytä toimia kaikissa olosuhteissa, joten sen liittämisen olisi parasta nojata suoraan ytimessä olevaan koodiin.

    XFS on SGI:n kehittämä tiedostojärjestelmä, jonka etu on suorituskyky, joka on suhteessa muihin sitä parempi, mitä isommista tiedostoista on kyse. XFS:n ohella myös IBM:n kehittämä JFS pärjää hyvin juuri isojen tiedostojen käsittelyssä, kuitenkin sillä erotuksella, että JFS käyttää vähemmän suoritintehoja.

    Kaikki ei kuitenkaan ole ruusuisaa, mitä näihin vaihtoehtoihin tulee.

    XFS:llä huhutaan olevan vakausongelmia. Asteen varteenotettavampia ovat kuitenkin puheet siitä, että XFS käyttäytyy huonosti silloin, kun koneesta saattaa katketa virta, tai se kaatuu, tai sammutus tapahtuu muuten vain ennakoimattomasti. Tämä johtuu siitä, että XFS on suunniteltu palvelinkäyttöön. Palvelimet pyörivät yleensä varsin luotettavasti (esimerkiksi sähkönsaanti on turvattu UPS:llä), joten tiedostojärjestelmää suunniteltaessa ei kotikoneita koskevista epävakausongelmista selviytymiseen ole tarvinnut panostaa.

    JFS:n osalta tällaiset huhut eivät ole yhtä laajalle levinneitä, mutta se saattaa ihan hyvin johtua vain siitä, että itse tiedostojärjestelmän käyttökään ei ole kovin laajalle levinnyttä. Ongelmista ei siis ehkä ole raportoitu siksi, ettei raportoijiakaan ole, enkä pidäkään JFS:n vakautta kotikäytössä riittävän hyvin testattuna voidakseni luottaa siihen. Yksi tunnettu ja tunnustettu ongelma JFS:llä on, ja se on Windows-ympäristöistä tuttu tiedostojen pirstaloituminen.

    Kaiken huipuksi JFS:n ja XFS:n tulevaisuus näyttää juuri nyt yhtä epävarmalta kuin ReiserFS:n tulevaisuus, joskin vähän erilaisista syistä. XFS:n kehitys kärsii SGI:n taloudellisista vaikeuksista. IBM on puolestaan menettänyt kiinnostuksensa JFS:n kehittämiseen, koska Linux-maailman isot yritysnimet, Novell ja Red Hat ovat lopettaneet tukensa sille.

    Jäljelle jää näin ollen ext3. Sen etu on iän, ja Linuxin levinneisyyden myötä laajalti tehdyn testauksen tuoma vakaus ja luotettavuus. Löytyy tietysti niitäkin, jotka pitävät tätä mainetta ansaitsemattomana, ja ext3:a kaikkein epäluotettavimpana, mutta ext3:n tuki on kuitenkin kiistatta Linuxissa ja eri Linux-jakeluversioiden kesken kaikkein paras. Ext3:n kiistaton haittapuoli taas perustuu samaan asiaan kuin sen edutkin, eli ikään. Koska ext3 on rakennettu aiempien versioiden (ext ja ext2) pohjalta yhteensopivuus huomioiden, se on jäänyt vauhdissa auttamatta jälkeen yllä mainituista, uudemmista tulokkaista.

    Juuri tällä hetkellä tilanne näyttää siis kaikin puolin heikolta. Tässä luetelluista tiedostojärjestelmistä ext3 on oikeastaan ainoa, jota voisin edes harkita, jos nyt ryhtyisin vaihtamaan ReiserFS:llä alustettujen /var- ja /home-osioitteni tiedostojärjestelmää. Siitäkin maksaisin sitten todennäköisesti käytännössä hinnan kiintolevytoimintojen hidastumisena. Valitsisin kuitenkin ext3:n kaikille osioille siinä tapauksessa, että olisin nyt vasta asentamassa käyttöjärjestelmää, ja kiintolevy täytyisi joka tapauksessa alustaa johonkin muotoon.

    Arkisto-osiolle voisin kyllä ottaa käyttöön JFS:n tai XFS:n niiden mahdollisesta epäluotettavuudesta välittämättä, koska sille osiolle en pitkiksi ajoiksi varastoi muuta kuin sellaista tavaraa, jonka olen jo kertaalleen polttanut rompulle. Näiden etu olisi jo mainittu suurten tiedostojen käsittelyn nopeus, joka pääsisi oikeuksiinsa, koska osio sisältää lähes yksinomaan vähintään useiden megatavujen kokoisia tiedostoja (musiikkia ja videota). Tuen jatkuvuudessa en tällä muutoksella edellä kerrotun perusteella siis kuitenkaan voittaisi mitään.

    /var on täynnä pikkutiedostoja, joten ReiserFS sopii sille kuin nyrkki silmään, sillä ReiserFS:n valtti on nimenomaan nopeus pienten tiedostojen kanssa. /home sisältää sekalaista tavaraa, mutta paljon pieniä (asetus-) tiedostoja sekin, joten ei ReiserFS siihenkään väärä valinta alunalkujaan ollut.

    ReiserFS:n tukikaan ei tietenkään ole loppumassa ihan seinään, sillä olen kaikkea muuta kuin yksi harvoista sitä käyttäessäni. Koska vaihtoehtojen suhteen tilanne on tällä hetkellä melko kehno, olenkin päättänyt pitää pääni kylmänä, ja katsella mihin suuntaan asiat kehkeytyvät. Jos optimistiset ennusteet pettävät, ReiserFS:n kehitys tyssää Hans Reiserin vankilatuomioon. Jos tiedostojärjestelmä alkaa sen jälkeen osoittaa ikääntymisen merkkejä, täytyy tutkia, onko tilanne vaihtoehtojen suhteen silloin yhtään parempi.

  • [Ratkaisu] PAM USB pois päältä XScreenSaverin näytön lukituksen avauksessa

    Lähtökohta
    Pakettienhallinnassa xscreensaver, pamusb-tools ja libpam-usb ovat asennettuna.
    Olen ottanut käyttöön XScreenSaverin näytön lukitsemisen virransäästön yhteydessä sekä pikanäppäintä painettaessa.
    Olen määritellyt PAM USB:n avulla tunnistautumismenetelmäkseni USB-porttiin kytketyn muistitikun. Turvallisuuden vuoksi olen sulkenut tämän tunnistautumismenetelmän pois käytöstä työpöydän sisäänkirjautumisruudun yhteydessä (gdm-palvelu) ja konsolikirjautumisen yhteydessä (login-palvelu).
    Ongelma
    Haluan sulkea USB-porttiin kytketyllä muistitikulla tunnistautumisen pois käytöstä myös silloin, kun näyttö on lukittu.
    Ratkaisu
    Lisään /etc/pamusb.conf -tiedoston <services>...</services> -osion sisään seuraavat rivit:

    <service id="xscreensaver">
  <option name="enable">false</option>
</service>

    Tämän jälkeen palvelut määrittelevä asetustiedoston osa näyttää kokonaisuudessaan seuraavalta:

    <!-- Services settings (e.g. gdm, su, sudo...) -->
<services>
  <!-- Disable pamusb for gdm, login and xscreensaver -->
  <!-- (display locking), a password will be asked instead. -->
  <service id="gdm">
    <option name="enable">false</option>
  </service>
  <service id="login">
    <option name="enable">false</option>
  </service>
  <service id="xscreensaver">
    <option name="enable">false</option>
  </service>
</services>

    Kun olen tallentanut tiedostoon tekemäni muutokset, USB-portissa oleva muistitikku ei enää kelpaa tunnistautumismenetelmänä lukitun näytön avaamiseksi.

    Huomautuksia
    • Tämä ratkaisu on sinänsä varsin triviaali sovellus PAM USB:n asetusten tekemisen ohjeissa annetusta GDM:n poissulkemisesta, mutta XScreenSaveriin liittyvää palvelun nimeä ei löytynyt suoraan annettuna mistään, joten päätin kirjata sen ylös tähän, vaikka sekin on sinänsä varsin helppo päätellä (niin kuin itse sen löysin).
    • Koska varsinaisesti haluan käyttää muistitikkutunnistautumista ainoastaan käyttöoikeustason kohottamisen (ainakin sudo ja gksudo) yhteydessä, voisi pitemmän päälle turvallisempi ratkaisu olla sellainen, jossa oletuksena (<defaults>...</defaults> -osiossa) PAM USB on pois päältä, ja määritellään käyttöön vain tietyille palveluille <services>…</services> -osiossa.

  • [Ratkaisu] XScreenSaver ja näytön lukitseminen pikanäppäimellä

    Lähtökohta
    Olen korvannut GNOME-työpöytäympäristön näytönsäästäjän XScreenSaverilla.
    Ongelma
    Haluan, että kun painan näppäinyhdistelmää Control + Break, näyttö lukittuu.
    Ratkaisu
    Liitän näppäinyhdistelmän vapaavalintaiseen komentoon, ja asetan sen jälkeen komennoksi näytön lukitsevan komennon.

    1. Otan esiin Asetusten muokkauksen Sovellukset → Järjestelmätyökalut -valikosta.
    2. Asetusten muokkaus -ikkunassa etsin /apps/metacity/global_keybindings/run_command_1 -avaimen, ja asetan sen arvoksi <Control>Break -merkkijonon.
    3. Etsin /apps/metacity/keybinding_commands/command_1 -avaimen, ja asetan sen arvoksi xscreensaver-command -lock -merkkijonon.

    Kun tämän jälkeen painan näppäinyhdistelmää Control + Break, näyttö lukittuu.

  • [Ratkaisu] Web-sivulla oleva Flash-elementti tekee vierityksestä hidasta

    Lähtökohta
    Pakettienhallinnassa flashplugin-nonfree ja libflashsupport ovat asennettuna. Lataan Firefox-selaimeen YouTube-sivustolta videon. Kaikki sivulla olevat kommentit eivät mahdu kerralla näyttöön, joten alan vierittää sivua pystysuunnassa tarttumalla selainikkunan oikeassa laidassa olevaan vierityspalkkiin hiiren osoittimella, ja liikuttamalla sitä pystysuunnassa.
    Ongelma
    Firefox nielee kaiken suoritintehon, ja sivun vieritys on sen takia hyppelehtivää.
    Ongelman syy
    Adoben flash-liitännäiseen liittyy ohjelmavirhe, jonka takia Firefox nielee liikaa suoritintehoa silloin, kun siihen on ladattu sivu, jolla on flash-sisältöä.
    Ratkaisu
    Suljen Firefoxin. Poistan Synaptic-pakettienhallinnassa flashplugin-nonfree- ja libflashsupport-paketin, ja asennan tilalle mozilla-plugin-gnash -paketin. Tämän jälkeen YouTube-sivustolla olevaa sivua pystyy vierittämään ilman, että Firefox nielisi kaiken suoritintehon, vaikka sivulla olisi flash-sisältöä.
    Mikäli ei-vapaata flash-liitännäistä on pakko käyttää esimerkiksi siinä tapauksessa, että haluan katsella Adobe Flashin versio 9:llä katseltavaksi luotua sisältöä, libflashsupport-paketin poistaminen kannattaa silti, sillä sen jälkeen suoritintehojen hävikkiä ilmenee vain flash-sisällön ollessa näkyvillä selainikkunassa. Kun flash-sisältö vieritetään näkymättömiin, tai jos flashia sisältävän sivun näyttävä välilehti suljetaan, suoritintehon käyttö palautuu normaalitasolle.

  • Firefox 3 wrongly associates logins with password-containing forms without login fields

    They’ve rehauled the Password Manager in Firefox 3, and as a result the pre-filling of forms no longer acts smart when it comes to forms without a login associated with the password field. I’m getting my previous logins to other sites under my domain, as suggestions to fill the input field immediately preceding the password field, on my Wikieditish-powered Blosxom blogs. I was forced to resort to inserting a pseudo-login field into the forms to make Firefox remember which data is associated with the other fields. Now I just have to learn to skip it on my way to the password field, when posting links.

  • [Ratkaisu] Greasemonkeyn skriptien muokkaus ei toimi

    Lähtökohta
    Olen asentanut Firefox-selaimeen Greasemonkey-laajennuksen. Olen asentanut sillä GMailSecure-skriptin. Haluan muokata skriptin lähdekoodia, joten valitsen Firefoxin Työkalut → Greasemonkey -valikosta kohdan Hallinnoi skriptejä.... Valitsen avautuvan ikkunan listasta kohdan GMailSecure, ja painan Muokkaa-nappia.
    Ongelma
    Muokkaa-napin painamisen jälkeen mitään ei tapahdu. Skriptin lähdekoodi ei avaudu muokattavaksi. Haluan, että lähdekoodi avataan Tekstieditorissa muokattavaksi.
    Ongelman syy
    Greasemonkey-laajennuksessa on ohjelmavirhe, jonka takia Tekstieditori ei käynnisty.
    Ratkaisu
    Ohjelmavirhe on korjattu käytössäni olevaa versiota uudemmissa Greasemonkeyn versioissa. Mozillan sivuilla on kuitenkin tarjolla vain vanha versio, joten lataan uusimman version Greasemonkey-kehittäjien versionhallintajärjestelmästä, käännän ja asennan sen.

    1. Lataan Greasemonkeyn uusimman version lähdekoodin seuraavilla komennoilla:
      mkdir ~/greasemonkey
cd ~/greasemonkey
svn co http://svn.devjavu.com/greasemonkey/trunk/src/ .
    2. Käännän lähdekoodista asennettavan laajennustiedoston seuraavalla komennolla:
      bash -v build.sh
    3. Asennan itse kääntämäni laajennustiedoston valitsemalla Firefoxin Tiedosto-valikosta kohdan Avaa tiedosto..., ja valitsemalla avautuvassa tiedostonvalitsimessa kotihakemistossani olevasta greasemonkey-alihakemistosta siellä olevan .xpi -päätteisen tiedoston, tässä tapauksessa greasemonkey-0.8.20080429.0.xpi. Sen jälkeen käynnistän Firefoxin uudestaan, jotta laajennuksen päivitys tulisi voimaan.

    Kun tämän jälkeen valitsen asennetun skriptin muokattavaksi, se avautuu Tekstieditorissa haluamallani tavalla.

  • [Ratkaisu] Firefox-ikkunan sisällön vieritys saa musiikin pätkimään

    Lähtökohta
    Näytönohjaimeni on Connect 3D:n valmistama, AGP-väylässä kiinni oleva Radeon 9600 -piirisarjalla varustettu All In Wonder. Olen valinnut näytönohjaimelle avoimen lähdekoodin ajurit käyttöön. En ole määritellyt ikkunointiympäristön asetuksissa kiihdytysmenetelmää (AccelMethod), joten käytössä on oletuskiihdytysmenetelmä, XAA.
    Työpöytätehosteet (Compiz) ovat käytössä oletusasetuksin.
    Käynnistän Rytmilaatikko-musiikkisoittimen, ja panen sen soittamaan musiikkia.
    Käynnistän Firefox-selaimen, ja avaan Launchpadista bugiraportin 177492, joka on pystysuunnassa varsin pitkä sivu. Tartun hiiren osoittimella selainikkunan pystyvierityspalkkiin, ja alan vierittää sivua pystysuunnassa.
    Ongelma
    Vierittäessäni sivun sisältöä selainikkunassa Rytmilaatikon soittama musiikki alkaa pätkiä, eli pysähdellä. Työpöydän alapaneeliin lisäämäni Järjestelmän tila -sovelma, joka näyttää suoritinkäyttöä, paljastaa, että suoritinkäyttö on koko vierityksen ajan täysillä tai lähes täysillä.
    Ongelman syy
    Näytönohjaimen avoimen lähdekoodin ajurissa on ohjelmavirhe, joka ilmenee suorituskyvyn heikkoutena työpöytätehosteiden ollessa käytössä silloin, kun käytetään XAA-kiihdytysmenetelmää.
    Ratkaisu
    Vaihdan oletuksena olevan XAA-kiihdytysmenetelmän EXA-kiihdytysmenetelmään lisäämällä /etc/X11/xorg.conf -tiedoston sisältämään Device-osioon, jossa näytönohjaimen ajuri on määritelty, seuraavat rivit:

    	Option	"AccelMethod"		"exa"
	Option	"MigrationHeuristic"	"greedy"

    Kun tämän jälkeen kirjaudun työpöydältä ulos ja ikkunointiympäristö käynnistyy uudestaan, kiihdytysmenetelmänä on EXA. Tällöin selainikkunan vieritys ei enää saa taustalla soivaa musiikkia pätkimään.

    Huomautus
    Katso myös merkintä Web-sivulla oleva Flash-elementti tekee vierityksestä hidasta.

  • [Ratkaisu] Speaker-test ilmoittaa äänentoiston avausvirheestä PulseAudion kanssa

    Lähtökohta
    Pakettienhallinnassa pulseaudio ja siihen liittyvät paketit ovat asennettuna. PulseAudio on otettu käyttöön ja se toimii.
    Haluan testata, onko 5.1-äänentoistolaitteistoni kytketty tietokoneen ääniulostuloportteihin oikein, joten komennan avaamastani Päätteestä speaker-test -Dplug:surround51 -c6 -l1 -twav.
    Ongelma
    Kaiutintestisovellus speaker-test ilmoittaa seuraavaa:

    Toistolaite on plug:surround51
Virran parametrit ovat 48000Hz, S16_LE, 6 kanavat
WAV tiedosto(t)
Äänentoiston avausvirhe: -16, Device or resource busy
Äänentoiston avausvirhe: -16, Device or resource busy

    Äänentoiston avausvirheestä ilmoittava rivi tulostuu yhä uudelleen kunnes keskeytän speaker-testin ajon näppäinyhdistelmällä Control + C. Haluan, että virheilmoituksen sijasta speaker-test toistaa kaiuttimien testaamiseksi ääninäytteitä eri kanavilta.

    Ongelman syy
    Äänentoistosta järjestelmässä vastaava PulseAudio on varannut äänentoistolaitteiston käyttöönsä. Speaker-test ei toimi PulseAudion vaan ALSAn varassa, joten PulseAudio ei voi jakaa sille äänentoistoresursseja.
    Ratkaisu
    Vapautan äänentoiston tilapäisesti speaker-testin käyttöön suorittamalla komennon seuraavasti:

    pasuspender -- speaker-test -Dplug:surround51 -c6 -l1 -twav

    Tällöin kaiutintesti toistaa ääninäytteet kytkentöjen testaukseen soveltuvalla tavalla.

    Huomautus
    Elegantimpi ratkaisu olisi käyttää PulseAudiota tukevaa kaiutintestisovellusta, mutta en toistaiseksi tiedä onko sellaista.