The Bizarre Cathedral esittää käyttöjärjestelmät kahveina:

Kehittelin huvikseni ajatusta hieman edelleen; lisäideoita sain kaveriltani Juhalta.

Windows

Nescaféta vuotavasta mukista, jonka korva on katkennut.

OS X

Kermavaahdolla ja makusiirapilla maustettua kahvijuomaa yksinkertaisen mutta tyylikkään näköisestä lasista, lusikalla. Juoman valmistaa barista nimeltä Steve, joka väittää tuotoksensa olevan yliveroista muihin verrattuna. Sinä uskot häntä ja maksat itsesi kipeäksi tuosta himoitusta juomasta.

Linux

Kaikki Linux-kahvit perustuvat reilun kaupan kahviin.

LFS

Pussillinen kahvipapuja.

RHEL vs. Fedora

Työpaikan kahvion kahvi vs. taukotuvan porukalla ostettu ja itse keitetty.

SLED, OpenSuSE

Samaa kuin edellä, mutta firma on saksalainen.

Mandriva

Café au lait.

Debian

Nokipannukahvia mustana, kuksasta.

Ubuntu

Nokipannukahvia maidon ja sokerin kera vaaleanruskeasta mukista.

*BSD

Tässä (kuten toki edellisissäkin) on edelleenkehittelyn varaa, sillä en tunne BSD-variantteja tarpeeksi hyvin keksiäkseni niille yhteisiä piirteitä, jotka erottaisivat ne edellisistä, tai mikä kussakin on keskeisintä.

FreeBSD

Edullista mutta hyvää peruskahvia.

NetBSD

Kaikki tykkäävät tästä kahvista.

OpenBSD

Pastöroidusta vedestä ja laboratorio-olosuhteissa kypsytetyistä pavuista valmistettu kahvi. Valmistaja, hullu professori, haistattelee sinulle jos yrität puhutella häntä.

Tämän blogin päivitystahti on viime aikoina hiipunut, mutta se ei suinkaan merkitse sitä, etteikö ongelmanratkaisu minua enää kiinnostaisi. Kaikki ensiasennuksen jälkeen kohtaamani pulmat, jotka yleensäkään ovat ratkaistavissa, alkavat vain olla ratkaistut — nykyisin jotakuinkin kaikki vain yksinkertaisesti toimii niin kuin pitää tai niin kuin haluan. Päivitysten myötä järjestelmä ei tietenkään pysy täysin muuttumattomana, mutta pelkät turvallisuuspäivitykset eivät kuitenkaan yleensä juurikaan horjuta hyvin toimivaa järjestelmää.

Koska ongelmanratkaisu siis edelleenkin kiinnostaa minua, en aiokaan pysyä Hardy Heronissa loputtomiin, vaan aion päivittää järjestelmäni myöhemmin tänä vuonna julkaistavaan versioon 8.04.1 ja edelleen Intrepid Ibexiin loppuvuodesta. Kuten Hardynkin tapauksessa, otan luultavasti lievän ennakkolähdön, ihan vain jännityksen vuoksi.

Sillä välin saan jännitystä ja haasteita tarpeekseni, kiitos VirtualBoxin. En enää muista mitä kautta tutustuin Innotekin kehittelemään ja nykyisin Sun Microsystemsin omistamaan virtualisointiratkaisuun, mutta veljet kuinka tyytyväinen olenkaan, että tutustuin! Alunalkujaan asensin VirtualBoxin, koska halusin kokeilla olisiko mahdollista ajaa Microsoftin Messengeriä siinä. Ei pidä käsittää väärin; pääasiallinen pikaviestimeni on ollut Pidgin jo pitkän aikaa — se oli sitä jo silloin, kun vielä käytin Windowsia — mutta joudun silloin tällöin käyttämään Messengeriä videopuhelimena vaihtoehdottoman kontaktin takia.

No, Messengerhän toimi mitä parhaiten, ja itse asiassa se oli lopullinen niitti ei-virtualisoidun Windowsin arkkuun tietokoneessani: poistin Windows-osion ja laajensin Ubuntun osiot kattamaan koko kiintolevyni. Nyt voin aina Messengeriä tarvitessani potkia virtuaalikoneen käyntiin yhdessä ikkunassa työpöydälläni, mikä on paljon yksinkertaisempaa kuin kaksoiskäynnistäminen. Ehkä kaikkein parasta VirtualBoxissa on sen joviaali lisensointi: ohjelmasta on tarjolla avoimen lähdekoodin versio, ja lisäksi yksityis- ja arviointikäytössä ilmainen suljettu versio. Avoimen lähdekoodin versiosta puuttuu joitain vaativia ominaisuuksia, joiden joukossa on USB-tuki. Joudun siksi itse käyttämään suljettua versiota, koska webkamerani (jota tietysti tarvitsen videopuheluihin) on tyypillinen USB-liitäntäinen vekotin.

Tätä nykyä pääasiallinen VirtualBoxin käyttöni ei kuitenkaan vaadi USB-tukea, ja tämä käyttö on sitä joka tarjoaa minulle haastetta: asentelen hullun lailla kaiken maailman käyttöjärjestelmiä VirtualBoxin virtuaalitietokoneisiini. Käyttöjärjestelmistä kiinnostuneelle VirtualBox onkin unelmien täyttymys. Virtualisointi mahdollistaa niiden asentelun tuotantojärjestelmää (jos peruskäyttäjän työpöytäkonetta sellaiseksi voi kutsua) vaarantamatta. Olen kokeillut Debian GNU/Linuxia (vakaata ja epävakaata jakeluversiota), Gentoota, Fedoraa, asentanut tietysti rinnakkaisen Ubuntun (monta kertaa), Slackwarea, LFS:ää, Debian GNU/Hurdia, FreeBSD:tä, OpenBSD:tä, ReactOSia, Syllablea… ja vielä on jäljellä paljon kaikenlaista, mitä aion kokeilla!

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.

Omien tiedostojen järjestely kiintolevylle on useimmille tuttu logistinen ongelma, jonka ratkaisutapa lienee kullekin hyvin ominainen. Minä tallennan nykyisin lähes kaiken työpöydälläni oleviin kansioihin. Työpöydällä vallitseva kansiojako näyttää tältä:

• Yksityiset
• Ei-vapaat
• Vapaat
• Työn alla
• Arkisto

Arkistoa lukuunottamatta nämä kaikki ovat aitoja hakemistoja, eli tiedostoja kotihakemistoni juuressa olevan Työpöytä-hakemiston alla.

Varsinainen pyhä kolmijako tässä päätasolla on jako Yksityisiin, Vapaisiin ja Ei-vapaisiin. Nimensä mukaisesti Yksityiset pitää sisällään kaikki visusti yksityisinä pidettävät tiedostot. Ei-vapaat/Vapaat -jako puolestaan perustuu siihen onko tiedosto vapaasti käytettävissä ja edelleen jaettavissa. Vapaat sisältää siis julkisomaisuutta ja copyleft-kamaa, jota voi käyttää ja jaella esimerkiksi netissä huoletta.

Näiden kolmen sisällön olen edelleen jakanut mediatyypin mukaan seuraaviin alihakemistoihin:

• Asiakirjat
• Kuvat
• Musiikki
• Video
• Muut

Kuten näkyy, nimen monikkoudessa häilyn kahden välillä. Sen suhteen minulla on täysin subjektiivisena periaatteenani se, miltä kukin sana yksikössä ja monikossa maistuu. Esimerkiksi Musiikki kuulostaa paremmalta kuin Musiikit, Video paremmalta kuin Videot (joka assosioituu mielessäni vahvasti VHS-nauhuriin), mutta Kuvat taas paremmalta kuin Kuva.

Musiikin ja Videon keskinäinen suhde on pikemminkin käytännön sanelema kuin ontologisesti perusteltu. Korvaisin Musiikin kovin mielelläni Äänellä, mutta kokemuksesta tiedän, että näin nimetty kansio sisältäisi kuitenkin loppujen lopuksi vain sen Musiikki-alikansion. Äänitiedostot, jotka eivät sisällä musiikkia, ovat työpöydälläni niin harvinaisia, että olen nostanut Musiikin suoraan Videon rinnalle, ja aion sysätä mahdolliset ei-musiikilliset äänitiedostot Muut-luokan alle yhdessä muiden sekalaisten mediatyyppien sekä kokoelmien kanssa.

Mikäli Video sisältäisi satunnaisten videoleikkeiden lisäksi vain yhtä tiettyä formaattia, kuten vaikkapa Elokuvia, voisi sen nostaa Videon tilalle Musiikin rinnalle, ja sysätä Videoleikkeet ei-musiikillisten äänitiedostojen tavoin Muut-luokkaan. Elokuvien lisäksi Video sisältää kuitenkin myös Televisio-ohjelmia, joten yhdessä Videoleikkeiden kanssa niitä on jo kolme, mikä tekee Videon itsenäisyydestä mielestäni pragmaattisesti perustellun ratkaisun.

Mediatyyppijaottelu ei ole sikäli täysin ehdotonta, että esimerkiksi pakatut asiakirjat, joiden avaamiseen siis tarvitaan ensisijaisesti pakkauksen purkava ohjelma eikä asiakirjojenlukuohjelma, luokittelen Asiakirjoiksi. Sen sijaan esimerkiksi kuvatiedostoksi skannattuja asiakirjoja en kykene luokittelemaan samoin, vaan hyytävästä epävarmuudentunteesta huolimatta olen ainakin vielä tähän saakka luokitellut ne Kuviksi.

Mikäli tiedostoja ei ole yhteensä kovin monta, sijoitan ne suoraan mediatyyppikansion juureen. Tarvittaessa jaottelen sisältöä kuitenkin edelleen uusiin, ad-hoc -alikansioihin. Ainoa vakio tällä tasolla on Muut-kansio muihin luokkiin sopimattomia tiedostoja varten.

Palataanpa takaisin työpöydälleni. Siellä sijaitseva Arkisto on pikakuvake, joka viittaa /mnt/Arkisto -hakemistoon, jonne olen liittännyt kakkoskiintolevyni. Arkistoon menee kaikki sellainen kama, minkä olen jo kertaalleen polttanut optiselle levylle. Esimerkiksi musiikkihan on sellaista, että siitä on käytännöllistä pitää kopioita kiintolevyllä vielä irtolevyille polttamisen jälkeenkin. Hätätapauksessa (tyypillisesti tilanpuutteen iskiessä) Arkiston voi kuitenkin pyyhkäistä vaikka kokonaan tyhjäksi.

Arkiston sisäinen jaottelu noudattaa työpöydän päätason keskeisintä kolmijakoa (Yksityiset, Vapaat ja Ei-vapaat), sekä näiden sisäistä jakoa mediatyypin mukaan, sillä sen sisältö on työpöydältä sellaisenaan Arkistoon siirrettyä. Arkisto on siis nimensä mukaisesti arkistoitua työpöydän sisältöä.

Työn alla on nimenä kankea, mutta kuvaavampaakaan en toistaiseksi ole keksinyt (esimerkiksi Työt olisi harhaanjohtava). Tähän hakemistoon tuuppaan tavaran, jota en vielä ole ehtinyt tai viitsinyt jaotella Yksityisiin, Vapaisiin ja Ei-vapaisiin, sekä lisäksi työpöytäympäristössä väliaikaisesti pyörittelemäni tiedostot. Työn alla -kansion sisältä löytyy yllä listatun kaltainen mediatyyppijako, sillä mediatyyppiä ei yleensä uutta tiedostoa tallennettaessa tarvitse miettiä.

Olen luonut lisäksi työpöydälleni mediatyyppien mukaan nimetyt linkit, jotka vievät Työn alla -kansion alla oleviin, vastaavannimisiin kansioihin. Sisääntulevat tiedostot on helppo paiskoa niihin odottelemaan myöhemmin tapahtuvaa, tarkempaa lajittelua.

Vielä tänä aamuna olin varma siitä, että ohjelman pääikkunan sulkemisnapin valitsemisen tulee sammuttaa ohjelma riippumatta siitä, onko ohjelmalla ilmoitusaluekuvaketta vai ei. Ajattelin, että sellaisen ohjelman, joka haluaa tarjota käyttäjälle mahdollisuuden sulkea sen pääikkuna sammuttamatta itse ohjelmaa, tulee tehdä niin vain erillisen valitsimen kautta. Tyypillinen esimerkki tällaisesta erillisvalitsimesta on Tiedosto-valikossa oleva Pienennä-kohta.

Sitten luin Launchpadissa tästä aiheesta käytyä keskustelua, joka pyörii Rytmilaatikon pääikkunan sulkunapin ympärillä. Tämän kirjoitushetkellä Rytmilaatikko toimii niin kuin yllä mainostin vielä aiemmin vankkumattomasti uskovani ohjelmien pitävänkin toimia. Nähtävästi se on jossain vaiheessa toiminut toisinkin. Jotkut käyttäjät haluaisivat palata entiseen käytäntöön, ja yllätyin huomatessani pitäväni joitakin näiden käyttäjien argumentteja varsin pätevinä.

Olin ajatellut, että ohjelman pääikkunan sulkemisnapin tehtävä on sammuttaa ohjelma, ja niinpä tästä käytännöstä poikkeaminen rikkoo napin toiminnallisuuden. Mutta mikäli luen vastustajien argumentteja oikein, heidän tulkintansa on, että ikkunan kuin ikkunan sulkemisnapin tehtävä on sulkea ikkuna, eikä sen takia ole johdonmukaista, jos sulkemisnappi sulkee ohjelman silloin, kun sen graafisena ilmentymänä näytöllä on ikkunan lisäksi ilmoitusaluekuvake. Huomasin oman kantani alkavan horjua, kun en ainakaan ihan suoralta kädeltä kyennyt tyrmäämään tätä näkemystä perusteettomana.

Itse asiassa ajatus ikkunan sulkemisesta ikkunan sulkunapin ensisijaisena tehtävänä tuntuu niin viehättävän yksinkertaiselta, että haluaisin kääntää kelkkani tälle ajatukselle perustuvaan suuntaan. Sekään ei kuitenkaan ole täysin ongelmatonta, sillä sovelluksen pääikkunan sulkemisen assosiointi ohjelman suorituksen päättymiseen on sekin hyvin perusteltu ratkaisu: tarvitsee vain kuvitella sitä painajaista, jonka pääikkunansa sulkemisen myötä — siis kaikkien graafisten ilmentymiensä kadottuakin — käyntiin jäävät ohjelmat aiheuttaisivat.

Pääikkunan sulkemisesta kuvakkeeseen -ratkaisun kannattajat eivät tietenkään aja takaa ikkunan sulkunapin toiminnan rajaamista ikkunan sulkemiseen näin puristisessa merkityksessä. Pääikkunan sulkemiseen assosioitavan toiminnon pysyvyys ei kuitenkaan heidän mielestään ole ratkaisevinta. Ratkaisevinta on ohjelman suorituksen jatkuvuuden assosiointi kaikkiin sovelluksen näytölle tuottamiin graafisiin ilmentymiin. Tästä perspektiivistä tarkasteltuna ohjelman suorituksen päättyminen silloin, kun sen kahdesta jäljelläolevasta ilmentymästä toinen suljetaan, ei ole johdonmukaista.

Ongelma on pohjimmiltaan kaksiosainen. Ensinnäkin tulisi luoda johdonmukainen käytäntö sille miten sovellukset, ikkunat ja ilmoitusaluekuvakkeet käyttäytyvät ja miten ne suhteutuvat toisiinsa. Toisekseen ohjelmien tulisi sen jälkeen sitoutua tähän käytäntöön. Tällä hetkellä käytäntö vaihtelee ohjelmasta toiseen siirryttäessä, sillä riittävästi perusteltua käytäntöä ei ole määrätty missään käyttöliittymien ohjenuorassa.

Olisiko tällaisen käytännön siis perustuttava ohjelmien pysyvyyteen ja kaikkiin graafisiin ilmentymiin tämän pysyvyyden kuvastimena, vai pääikkunan sulkemiseen assosioitavan toiminnon pysyvyyteen? Vielä tänä aamuna olisin vannonut ikkunansulkemistoiminnon assosiaatioiden pysyvyyden nimeen, mutta nyt en enää osaakaan sanoa varmasti. Ainakin näin tuoreeltaan ohjelmien pysyvyys kuulostaa ikkunansulkemistoiminnon pysyvyyttä elegantimmalta peruslähtökohdalta.

Toverini Juha linkkasi minut kuvaan hauskasti mönkään menneestä huijausyrityksestä: Linux-käyttäjä oli saanut Skypen kautta ilmoituksen, jonka mukaan hänen Windowsinsa tietoturva oli vaarantunut, ja missä häntä kehotettiin lataamaan paikkaustiedosto ongelman korjaamiseksi. Kyse on tietysti Windows-haittaohjelman levityksestä valheellisen tietoturvailmoituksen avulla.

Huomioni kiinnittyi blogimerkinnän perässä olleeseen kommenttiin, jonka mukaan yrityksen kohteeksi joutunut käyttäjä voisi aivan hyvin ollakin vaarassa, koska hän käyttää Ubuntua, joka muistuttaa niin paljon Windowsia. Auts!

Olen kyllä miettinyt, että Ubuntun (ja tietysti muidenkin vastaavien distrojen) tapa kysellä järjestelmänhallinnan salasanaa tuon tuostakin on pikkuisen huolestuttava sikäli, että siinä turtuu hyvin pian toimenpiteen ratkaisevuudelle. Olen itsekin asentanut Gutsyyni järjestelmänhallinnan oikeuksia käyttäen pari pakettia tutkimatta niiden alkuperää näin jälkikäteen ajateltuna riittävän hyvin. Kun web-sivuilla jaeltujen ohjelmapakettien asentaminen järjestelmänhallinnassa vaadittavin oikeuksin on näin suoraviivaista, ollaan jo käytännössä samalla viivalla Vistaa varhaisempien Windowsien kanssa siinä, että tietoturvan mahdollisesti vaarantavien ohjelmien asentelusta tulee liian helposti jokapäiväistä kauraa.

Tähän järjestelmänhallinnan helppouteen tottuneena en kuitenkaan kovin mieluusti enää luopuisi siitä. Ja sikäli uskoisin Linux-käyttäjänä vielä olevani vanhojen Windowsien käyttäjiä paremmassa turvassa, että ainakaan niin kauan kuin en ole onnistunut vaarantamaan järjestelmääni, ohjelmat eivät pääse järjestelmääni käsiksi omine nokkinensa, siis minun siitä tietämättä. Vaarantuminen vaatii periaatteessa aina minulta sen virheen, että annan vaaralliselle ohjelmalle ne järjestelmänvalvojan oikeudet. Mutta miten tätä järjestelmänhallinnan oikeuksien jatkuvaan peräämiseen liittyvää tietoturvariskiä voisi vähentää?

En ole perehtynyt SELinuxiin, mutta se voisi ehkä olla avuksi. Sen lisäksi en kyllä keksi äkkiseltään muuta ratkaisua kuin sen, että perusjärjestelmän päälle ei asenneta mitään muuta kuin virtualisointi, ja käyttäjä päästetään sen jälkeen vain virtuaalihiekkalaatikkoon, jossa saa asennella mitä huvittaa. Isäntäjärjestelmä tarjoaa palomuurin ja muita tietoturvaominaisuuksia, jotka valvovat tätä hiekkalaatikkoa, ja jos isäntä havaitsee hiekkalaatikossa epäilyttävää toimintaa kuten vaikkapa viruksen aiheuttamaksi epäiltyä liikennettä, se puuttuu peliin. Käyttäjää varoitetaan, ja vasta uhan torjumisen tai tietoturvan vaarantumisen paikkaamisen yhteydessä kysytään tarvittaessa oikeita järjestelmänvalvojan oikeuksia, eli oikeuksia isäntäjärjestelmän hallintaan.

Siinä tapauksessa sitten kylläkään käyttäjää ei hiekkalaatikkonsa tyhjäksitekemisen takia välttämättä enää paljoa lohduta se, ettei isäntäjärjestelmä ole vaarantunut. Isäntäjärjestelmä voisi kuitenkin pelkän valvonnan ohella tehdä hiekkalaatikosta myös varmuuskopioita tai järjestelmäkuvatiedostoja (snapshot) säännöllisesti, jolloin kokonaan puhtaalta pöydältä aloittamisen sijasta käyttäjä voisikin valita aiempaan, vielä vaarantumattomaan hiekkalaatikkoon palaamisen eikä siten menettäisi ihan kaikkea.

Lopuksi täytyy vielä todeta, että tähän ehdotukseeni voi olla sisältyä ammottavia aukkoja, sillä en ole tietoturva-asiantuntija, en virtualisointiasiantuntija enkä pidä itseäni edes Linux-asiantuntijana, vaikka siitä kokemukseni näistä kolmesta aiheesta lieneekin kaikkein laajin.