Intellektuaaltarbija kaitse ja õiglane ootus muutmata sisule

Ma ütlen päris tihti igasugustes olukordades, et "mina olen usklik inimene - ma usun, mida mulle räägitakse". Karta on, et mõni on mind hakanud tõesti ka usu mõttes usklikuks pidama (mis ei puutu asjasse), aga ometi eeldame ju, et iga loetud raamat on algupärane selles mõttes, et autorikaitse huvides ei ole teksti-fotosid-kaarte või muid andmeid rikutud.

Olin just hädas, et mida siis õieti arvata autorikaitsest ja intellektuaalomandist, kui mulle anti viide Amazon.com-i sisurikkumise patendile. Või kuidas sa nimetad sellist tegevust, mille tulemusena on teoses sõnu muudetud:

By replacing one or more selected words in an excerpt with synonyms for the words, illicit copies of the excerpt may be recognized by comparing a copy of the excerpt to the original.


Kusjuures, kujutage ette muusika töötlemist sarnasel meetodil. Ilmselt tuleks tekitada päris korraliku mahuga tarkvaraprojekt, mille raames loodud tarkvara suudaks muusikateostes muuta noote nii, et säiliks soovitud harmoonia/disharmoonia, rütm, atmosfäär ja kõik muu, mis üht muusikapala koos hoiab. Tekstidega on lihtne, need on selles mõttes ühemõõtmelised. Muusika puhul satuksime keerulisse tehisintellektivaldkonda.

Siinkohal peangi tunnistama, et kuna autorikaitsega on mindud suhteliselt ebameeldivate meetmeteni, siis tuleks appi võtta n-ö intellektuaaltarbija kaitse. Umbes nagu tavaline tarbijakaitse. Kahe aasta jooksul on pretensioonide esitamise võimalus. Kui saapal tuleb aas küljest ära, saan minna poodi ja müüjafirma on kohustatud mu saapa korda tegema või ta välja vahetama.
Kui ma nüüd avastan mingit Amazoni-stiilis autorikaitse all olevat teost lugedes, et sisu on muudetud, saaksin samuti minna kaebama, et miks mulle tahetakse panna süüks soovi teost kopeerida. Selline asi ei puutu ju üldse minusse kui heausksesse lugejasse.

Ja veel:

For example, mapmakers may insert deliberately inaccurate or fictitious roads or place names in maps. Enterprises that provide phone directories may insert fictitious listings into the directories. The intent of this falsified content is to be perceivable but not easily recognizable as "false content" to the casual viewer, including those who might want to illicitly copy the material.

Mõtiskleme edasi. Oletame, et meil on mingi keeruline ja kallis kommertstarkvara, mis juhuslikult on võimeline inimesi teise ilma saatma või neid invaliidistama. Siin on kaks aspekti: esiteks - tarkvara käitumise võltsimine tavakasutajale arusaamatul viisil ja teiseks, tarkvara koodi võltsimine heausksele arendajale arusaamatul viisil. Jällegi päris ulmelise keerukusega projekt, kui arvestada, et tarkvara tootjal-võltsijal on risk autorikaitse eesmärgil tehtud muudatustega tõesti inimesi tappa. Ja kui nüüd see muutmine toimuks lähtekoodi tasemel, siis pandaks vaene arendaja väga täbarasse olukorda. Proged, testid, veendud, et nagu toimib ja et ei tohiks midagi hullu juhtuda - ja siis tuleb mängu autorikaitse, kes natuke su koodi muudab... Tegelikult peaks ilmselt sellisel puhul tekkima täitsa uus tarkvaraarenduse metoodika, kus arendataks mitut paralleelset korrektset versiooni, kusjuures fantaseerida võiks ka automaatsete koodimuudatuste üle, mis säilitaksid tarkvara korrektse käitumise.

Peaks siinkohal lõpetama, et jääda mõistlikkuse piiridesse.

Mina ei ole seda usku

Lugesin soomlaste parlamendiraportit infoühiskonnast ja selle võimalikust loovusepõhisest arengustsenaariumist. Soomes ma pole elanud ja soomlaste hingeelu iseärasusi ei tunne, aga pigem arvan, et tegelikult ei ole mu tähelepanekud eesti ühiskonna kohta ka soome kontekstis valed.

Lugedes meenus mulle muuhulgas ühe mu keskkooliõpetaja mure n-ö arengumaade pärast, et ikka tuleks ilmtingimata neile haridust viia. Euroopalikku haridust Aafrikasse? Ma ei usu, et meie arusaamad elust on ainuõiged või kõige paremad.

Lisaks kangastus, et majanduslangusega seoses soovitatakse meil siin, et kui töötuks jääd, hakka ettevõtjaks. Ilmselt on seal mingi põhjus, miks soomlaste raportit lugedes just sellised asjad pähe lõid. Mulle tundub, et autor ei ole just väga hea inimestetundja.

Olgu, juttu oli Maslow väärtuste püramiidist. Joonised muide ei ole selle raporti tugevam külg. Aga kuna ma olen nimetatud püramiidist varem lugenud, siis sain enam-vähem aru. Kuidas aga tagada, et kui suurem osa inimestest ei ole tegelikult loovad ega ettevõtlikud, suudetaks luua just loovusel põhinev majandusareng, mis kõigi ühiskonnaliikmete põhivajadusi rahuldaks? Ausalt, kui käin Laitse poes süüa ostmas, siis 10 inimesest 9 on alkoholivines, tahab edasi juua ning ilmselt väga tööl ei tahaks käia.
Kui suurem osa inimesi ikka ei soovi luua ega areneda, ei soovi tunda ühtsust muu kui viinapudeliga, siis on veider loota, et saab eksisteerida mingi loovusepõhine heaoluühiskond ja loovusel põhinev majanduskasv. Innovatsioonist rääkimisega seoses unustatakse minuarust enamasti ära, et tõeliselt vingeid asju suudavad luua väga vähesed. Ja selle koha pealt rääkis soomlaste raport küll ju õieti, et kui teatud vajadused pole rahuldatud, tekib üleüldine kadedus ja pead tõstab vägivald.

Kurb tõsiasi on, et pole ilmselt olemas ühiskonnakorraldust, kus kõik teeksid igapäevatööna seda, mis neile kõige rohkem meeldib, ja saaksid tarbida kõike, mida ihaldavad, nii et sealjuures loodusväärtused säiliks ja kõik elaksid vanaduseni ilma suuremate haigusteta. Miks siis kirjutatakse kokku dokumente, mille põhiteema on just selline ideaalne ühiskond? Praktikas on olemas palju vajalikke töid, kus loovusega pole kohe mitte midagi peale hakata - töö prügimäel sorteerijana kasvõi.

Tõepoolest on kaasaegse Lääne ühiskonna üheks probleemiks see, et inimene on sunnitud jooksma hammasrattas, mida lükkab tagant üha kiirem areng. Ja probleemiks on muidugi, et üksikisikule on selle arengu motiivid jäämas üha kaugemaks. Lahenduseks loovuse ja ühtekuuluvuse hammasratas?

Minule tundub, et mingite ühiskondlike arenguprogrammidega ega ka riikliku võimlemiskavaga ei ole võimalik tegelikku igapäevast elu väga mõjutada.

Soomlaste raport näitas kahjuks, et ilmselt on mingi osa seltskonnast niivõrd elukauge, et ei märkagi enda kõrval inimest.

Täna ma kirjutan wikist

Uue meedia võimalustega seoses tuleb mainida, et ma suhtun kõikvõimalikesse vaba sisu esinemisvormidesse väga hästi, aga ise ei ole viitsinud väga ajaga kaasas käia. Kui välja arvata tööalased vajadused. Seepärast räägiks wikist seoses tööga ja võrdleks wikit traditsioonilisemate suhtlus- ja dokumenteerimisvahenditega, mida tarkvaraarenduses on kasutatud.








(allikas: 3nexus.com)



Tarkvaraarenduses käib töö lihtsustatult nii :

• Kliendil (välisel või firma mingil üksusel) on mingi soov. Ta oskab seda kuidagi kirjeldada, aga suht lünklikult ja muidugi üldse mitte tehniliselt.
• Firmas on analüütik või siis keegi projektijuhi-analüütiku sulam, kes kliendi ära kuulab ja kirja paneb, mida uuelt tarkvaralt või mingitelt täiendustelt-muudatustelt oodatakse.
• Tarkvaral, olgu ta juba olemas või mitte, on üldiselt nõuded, arhitektuur, komponentide disain ja kood. Ja ilmselt ka testid, kui tegu on hea firmaga. Mingi osa loetletust on kuskil kirjas. Kas kood on ühtlasi ka dokumentatsioon, selle üle vaieldakse. Aga kindlasti ei ole kood ainus kirjasolev asi ja seega lähevad ootused ja tegelikkus kindlasti kuskil sünkroonist välja.
• Tarkvara on vigane (olevikus või tulevikus) ja vead on kuskil kirjas. Paremates firmades on selleks veahoidlad, viletsamates firmades on vead kuskil e-mailides vms. Hea on, kui vead, veaparandused, dokumentatsioon ja tegelikkus kõik kooskõlas on. Kood on elab igas enesest lugupidavas projektis muidugi versioonikontrolli all, aga see ei taga kuskilt otsast koodi ja kõige muu kooskõlasolemist.
• Arendaja on tihti olukorra ees, kus ta hakkab millegi põhjal koodi kirjutama, aga nõuded muutuvad koguaeg ja tulemus peab muidugi olema kooskõlas viimaste nõuetega. Või siis läheb nii, et implementatsioonis on veel kuidagi kolmandatmoodi, sest nõuetele vastavalt ei olnud probleemi võimalik tehniliselt lahendada.
  

Mõelge, kui palju kommunikatsiooni tarkvaraarendus endas hõlmab ja kui palju on sünkroonist väljaminemise võimalusi. Võib isegi öelda, et tarkvara saab loodud muutuvate sisendandmete kiuste.

Wiki kujutab endast igavesti mõnusat vahendit tarkvaraarenduses liikuva info hoidmiseks, muutmiseks ja haldamiseks, kusjuures ärksamaid wikisid annab siduda veahoidlate, versioonikontrolli, RSSi ja muu sarnasega, tänu millele tekib wiki ümber elav protsess.
Jama on ainult siis, kui kasutatakse formaate, mis ei allu teksti diffimisele (kes ei tea, siis diffimine on kahe tekstifaili võrdlemine ja võrdlustulemuse väljastamine tekstikujul, kokkulepitud tähistustega). Näiteks ei allu diffimisele .doc-formaadis nõuded jne.
Kirjeldan nüüd eeltoodud tarkvaraarenduse protsessi osi ja osalejaid wikipõhise lähenemise kontekstis ja mainin iga punkti juures, kuidas varem tehti ja mis on piirangud.

• Head wikid oskavad majandada kasutajaõigustega. Kui meil on toimiv wiki, siis saab klient õiguse teatud wiki lehti külastada ja ka kommenteerida, mida vaja. Lisaks saab wiki kaudu ligi tarkvara väljalasetele (pakkidele, binaaridele vms). Ilma wikita oleks klient arendusfirmast või -osakonnast isoleeritud ja tarkvara versioonid jõuaks temani plaadil, mälupulgal või näiteks mingi FTP saidi kaudu, kus ei oleks jällegi võimalik näiteks viidata uues versioonis parandatud vigadele. Selle punktiga seoses mingeid väga suuri probleeme tekkida ei tohiks.
  
• Analüütik paneb muidugi kõik vajaliku wikisse kirja. Dokumente genereerib vajadusel ka wiki põhjal. Ilma wikita oleks kuskil kataloogid nõuete failidega, ilmselt eri versioonid lihtsalt eri failides, või siis kasutaks firma mõnd dokumendihaldussüsteemi. Siin on muidugi wiki sobiv ainult teatud firmadesse, teatud olukordadesse, sest wiki võib väga lihtsalt käest ära minna. Selleks, et wiki oleks hea analüüsidokude asukoht, peab keegi isiklikult selle eest hea seisma ja firmas peaks valitsema ka õhkkond, mis soosib tekstiformaati ja sellest vajadusel eri väljundite genereerimist.
• Tarkvara dokumentatsiooni hoidmine wikis on umbes samalaadi ülesanne nagu analüüsipoole hoidmine. Vaja on süsteemi, huvilisi ja arusaamist, et wiki on allikas ja kõik muu genereeritakse. Probleeme tekitavad kindlasti väliste vahenditega tekitatud joonised, see probleem on tegelikult ka analüüsidokude juures. Ja vanamoodne lähenemine oleks jällegi sama: failid kuskil kettal, näiteks .doc formaadis, samuti erinevate CASE-vahendite väljundvormaatides failid.
  
• Tark wiki viitab koodi- ja veahoidlale. Vanamoodsate vahenditega võib olla päris raske järge pidada, kus mingi nõue implemenditud või viga parandatud on. Eriti ilus on, kui wiki oskab kuvada mingit alamhulka veahoidlas püstiolevatest probleemidest ning väljavõtet versioonihalduse viimastest commit-idest. Raskused võivad ilmselt tekkida vigade-versioonide ja wikivaheliste ristviitamistega, e. kuidas ma viitan koodist mingile wikis kirjasolevale nõudele jms. Jällegi: vaja on huvilisi, süsteemi ja õiget wikit.
• Muutuvatest nõuetest võiks arendaja saada infot RSSi abil. Eriti on see hea, kui töötajad ei asu füüsiliselt samas hoones. Kui nõuet wikis muudetakse, võiks arendaja saada teada, millega seoses muudatus tehti ja lingi, kus see kirjeldatud. Vanamoodsam alternatiiv oleks, et projektijuht tuleb tuppa ja teatab, et tegelikult tahetakse hoopis naa, mitte nii. Kuna nõuete muutumine on tüütu nii või teisiti, siis wiki peale ülesehitatud protsessis ei satu projektijuht tuppa vähemalt kõige viletsamal hetkel - näiteks kui arendaja on just suutnud keskenduda koodile.
  

Hästi disainitud tooted müüvad end ise

Nii olla ükskord öelnud Digital Equipment Corporationi (DEC) juht Ken Olsen. Veel on ta ajalukku läinud väitega (tõsi küll veidi kontekstist väljarebituga), et pole vähimatki põhjust, miks keegi peaks omale koju arvutit tahtma. Ken oli inseneri taustaga ja tema firma oli oma rikkuse kokku ajanud miniarvutite (PDP, VAX) loomisega, seega turundus ja tollal veel olematu PC turu perspektiivikus ei sobitunud ilmselt kuigi hästi ta maailmapilti. DECil oli mitmeid tooteid, mille kvaliteeti siiani heldimusega meenutatakse (näiteks OpenVMS opsüsteem). Kahjuks viisid juhtimisvead selle suure firma hauda - firma, mis omal ajal oli IBMi järel maailma suuruselt teine infotehnoloogia ettevõte (tippajal 130000 töötajat).

Lähemalt räägin DECi protsessoriperest nimega Alpha. See oli 64-bitine RISC-tüüpi protsessoriarhitektuur, mida tutvustati esmakordselt 1992. aastal. Alpha oli oma aja kohta tehnoloogiliselt väga paljulubav ja sünnist kuni 90ndate lõpuni oli ta oma arengus i386-tüüpi protsessoritest aastaid ees.
Paraku polnud sellest kõigest kasu ja tänapäeval jookseb enaikus desktop- ja serverimasinates ikkagi i386 ja nii Alpha kui ka DEC ise on tänaseks unustusehõlma vajunud.

Lugesin Alpha ebaõnnestumise põhjuste kohta üht pikka ülevaadet ja selgub, et temaga seotud turundusvõtted ja muud otsused saab ainult ühtmoodi kokku võtta: "Nii ei tehta!"

* Suhtumine, et head toodet polegi vaja reklaamida. Maailmas on paraku küllaga näiteid, kus tehniliselt hea ja halva kuid hästi turundatu konkurentsis on peale jäänud viimane.

* Ei haaratud võimaluse avanedes kinni Apple'i koostööpakkumisest ja kaotati seega potentsiaalne tee PC turule. Apple valis oma protsessoriarhitektuuriks seejärel hoopis PowerPC.

* Alpha serverid maksid umbes 2 korda sama palju kui konkurentide samaväärse arvutusvõimsusega riistvara (mis ei olnud ka kaugeltki odav).

* Klientidel soovitati opsüsteemina kasutada Windows NT-d, Digital Unixit või OpenVMSi (just selles järjekorras). Windows NT, mis oli seega antud riistvara soovituslikeim OS, oli paraku 32-bitine ja eeskätt i386 turule mõeldud. Seega oli Windows NT Alphal aeglasem, kui riistvara võimaldanuks, ja enamus rakendusi ei toiminud. Oli küll olemas emulaator, mis suutis i386 binaare NT all jooksutada, kuid seda umbes 40% jõudluskao hinnaga. Olematu oli ka draiverite tugi, kuna ükski riistvaratootja ei olnud huvitatud NT jaoks Alpha draiverite kirjutamisest. Seda veidram on, et kõige vähem soovitas DEC kasutada omaenda OpenVMS-i, mis oli NT-le arhitektuuriliseks eeskujuks ja on siiani misioonikriitilistes süsteemides kasutusel. OpenVMS oli juba 20 aastat tagasi hajusa failisüsteemiga klaster-operatsioonisüsteem, mille klastrite "uptime'id" ulatuvad üle 10 aasta, kusjuures kogu raua võib jupphaaval välja vahetada ilma, et klaster sellest restarti peaks minema.

* OpenVMS ja Digital UNIX olid kallid ja niigi luksusauto hinnaklassis Alpha-põhiste masinatega ei tahetud kumbagi neist paraku tasuta kaasa anda.

* Kuigi NetBSD ja hiljem ka teised BSD perekonna liikmed ja Linux porditi 90ndate keskel ja lõpus Alphale, ei tahtnud DEC neist midagi kuulda. Ükski neist opsüsteemidest poleks olnud jõudluse või raua toe osas NT-st või DECi enda OS-idest halvem ja neist mõne toetamine oleks seega võimaldanud eelmise puntki mõju oluliselt vähendada.

Idealismist üksi ei piisa

"Sellise lutsu ostsidki?!" - küsis kolleeg ja perekonnatuttav mu mehelt, kui talle meie uuest "koduloomast" e. Openmoko projekti loodud Neo Freerunneri nimelisest telefonist rääkisin ja ta selle jutu ajel mehele helistas. Kõnekvaliteet oli olematu ning läbi müra ja ragina kostus mu mehe kauge, katkendlik ja robotlik hääl. Tore oli, et telefon kõnele üldse reageeris ja sleep-olekust välja otsustas tulla.
Tegelikult pidi Freerunnerist saama revolutsiooniline seade, millel suur puutetundlik ekraan, GPS ja multimeedia võimalused ning mis oli täiesti avatud - nii tarkvara lähtekoodi kui riistvara spekkide poolel. Avatud ta tõepoolest oli. Ja ilmselt ei oleks programmeerimisega mitteseotud inimene temaga üldse midagi peale osanud hakata.

Freerunnerist ja kõigist tema omadustest hakati rääkima aasta enne, kui Steve Jobs esimese iPhone-i versiooni tulekust teatas. Kätte saime telefoni aasta pärast iPhone'i turuletulekut.
Miks nii juhtus ja miks see telefon niivõrd ebaõnnestus?

Openmoko projektil oli küll üllas idee kasutada ainult avatud spekkidega riistvara, kuid nad ei osanud ilmselt uneski näha, kui keeruline võib olla riistvaratootjatelt selliseid komponente saada. Binaardraivereid aga polnud projekt nõus kasutama. Ja nii olid neil väga piiratud võimalused riistvarapoole loomisel.
Ja nagu sellest veel vähe oleks - Euroopas ei sobinud Freerunneri riistvara siin kasutuses oleva mobiilside sagedusvahemikuga, mistõttu ilmutas end riistvaradisaini viga ja kõnekvaliteet osutus olematuks. USAs jällegi ei saanud Freerunner hakkama osa sealsete SIM-kaartidega.
Avatud tarkvara aga tähendas seda, et peale telefoni kättesaamist oli vaja parandada hunnik vigu, et kasutajaliides talutavalt töötaks - näiteks et avaneks kontaktiraamat ja et telefon suudaks kõne vastuvõtmiseks üles ärgata.
Kõige toredam viga on siiski riistvaraline: selleks, et telefoni saaks laadida, on vaja kernel buutida, et too saaks kuhugi registrisse paar väärtust kirjutada. Niisiis ei tohi telefoni akut päris tühjaks lasta. Aga kui nii siiski juhtub, on lahendus olemas. Tuleb telefon ikkagi laadima panna ja mõned tunnid oodata. Kuigi aku ei lae, toimub kerge voolulekkimine ja kui hästi läheb, on Freerunner võimeline end nimetatud paari tunni möödudes siiski buutima. Et võimaldada laadimist.

Ja veel. Avatud lähtekoodiga tarkvara pidi tagama Freerunneri arengu. Nimelt lootsid Openmoko projekti loojad, et telefoni ümber tekib arendajate kogukond ja telefon saab seetõttu heaks ja populaarseks. Aga juhtus nii, et tekkis kümmekond eri distributsiooni, mis kõik üritavad Freerunneri tarkvara paremaks teha, aga keegi ei ole tõusnud esile ega saavutanud läbimurret.

Selline luts siis. Oleme kodus talle siiani kaks rakendust leidnud: robootika ja GPS.
Telefoniks ta ei sobinudki.

Pildil on Neo Freerunner rattalenksu küljes, Aegviidu kandis -7 kraadi juures talve nautimas.

IT ajaloo äpardusi (kolmes osas)

Selles ja kahes järgnevas postituses mõtistklen kolme IT ajaloo nähtuse üle, mis ei kuulu just väga edukate sekka.

Teemaga seoses meenusid mulle kõigepealt sellised seadmed nagu peilerid. Kutsuti ka piipariteks. Vähemalt paaril mu klassikaaslasel oli selline omal ajal vöö küljes, aasta võis olla umbes 1998.
Nüüd hakkasin mõtlema, et mis seade see selline oli ja mida ta võimaldas? Ja kuidas teda omal ajal reklaamiti? Ilmselgelt jäi ta hiljem jalgu mobiilside võimalustele ja kõikvõimalikele mobiili ja arvuti vahepeal olevatele seadmetele (PDA-d), võib-olla ka GPS seadmetele ning seda enam sellistele, mis ühendavad telefoni, meilikliendi, GPSi ja multimeedia.

Peiler on selline seade (pildil mingis moodsamas vormis):












Ta on tehniliselt suht piiratud ja ilmselt need, mida mina mäletan, võimaldasid vaid mingisugust ühesuunalist märguande moodi sidet. Hiljem tuli tekstisõnumite tugi, aga kellel seda enam vaja oli?
Tuleb siiski mainida, et kasutuses on peilerid siiamaani, nimelt päästeteenistustes ja kriisiabis üldisemalt. Väidetavalt peab peilerside katastroofiolukorras paremini koormusele vastu kui mobiilside.

Mobiilside, mobiilse interneti ja igasuguste kaasaskantavate seadmete valguses ei ole peiler kindlasti IT ajaloo edukate seas. Vähemalt ei kuule me temast üldse. Google'ist eestikeelseid vastuseid otsides leidsin mitu vana artiklit (jällegi umbes 1998. aastast), mis räägivad võimalusest saada peilerile teade saabunud e-mailist. Teenustasu oli sealjuures päris krõbe.

Võtame näiteks sellise lõigu (Äripäeva artiklist):
E-posti vastvõtmiseks sobivad igat tüüpi peilerid, kõige enam kasutatava kaubamärgi Motorola mudelid võtavad vastu teateid-elektronposti teavitusi järgnevas mahus: üherealine Motorola Express Ultra kuni kuus teadet, neist lukustatavad kolm teadet, kaherealine LX 2 võtab vastu 20 teadet, kümme neist lukustamise võimalusega, neljarealine LX4 20 teadet, lisaks 20 teate mällu salvestamise võimalus.


Meie arusaamad elementaarsetest kommunikatsioonivõimalustest on praegu ilmselt natuke teised.

test

test