Joukko viisaita miehiä ajattelumyssyineen Khronos Groupista teljettiin vuonna 2006 pimeään suunnittelumajaan. Kun tämä 61 hengen joukko päästettiin parisen vuotta sitten ulos, olivat he luoneet ajatuksen tutun ja turvallisen grafiikkaohjelmoinnin perinpohjaisesta rikkomisesta, eli OpenGL 3:n.

Valitettavasti^{[citation needed]} rikkominen jäi puolitiehen, kun vanhojen ominaisuuksien poistamisen sijasta käytännössä koko OpenGL 2 vaan deprekoitiin, ja lopulta OpenGL 3.2:een lisättiin kaksi eri profiilia, compatibility vanhojen juttujen muistelua varten, sekä uudenkankea core-profiili oikeaa tekemistä varten. Vanha rajapinta siis vähän tilanteesta riippuen toimii edelleen Compatibility-profiilissa, mutta käsittelen tässä kirjoituksessa nyt lähinnä Core-profiilista.

Punaisen pallon tarina

Deprekoituneita tai poistettuja ominaisuuksia on valtavasti. Otan niistä esille tähän joitain mielestäni tutuimpia.

Oleellisin muutos on koko fixed-pipeline:n poistuminen, eli ei enää matriisipinoa, verteksi kerrallaan piirrettäviä objekteja tai oletusshadereita. Piirtääkseen ruudulle punaisen pehmeästi varjostetun pallon, täytyy aluksi itse laskeskella kaikki kameran matriisit – jos siis haluaa ylipäätään toteuttaa objektien ja kameran transformaatioita matriiseilla – ja syöttää lopulta nämä tiedot ja pallon verteksit, normaalit yms. taulukkona omatekoisten shadereiden attribuutteihin. Lopulta täytyy toteuttaa esim. Phong-varjostus, jotta ruudulle piirtyy jotain. Toki pallo onkin varmaan helpompaa vain generoida uudella geometria-shaderilla.

Väittäisin, että vanhalla kunnon gluPerspective + gluLookAt + glColor + glVertex + glNormal + glShadeModel(GL_SMOOTH) -yhdistelmällä pallon saa ruudulle paria aikayksikköä vähemmällä työllä.

Mitä siis poistui?

Funktiot glBegin, glEnd, glColor, glNormal, glVertex ja glTexCoord ja kaikki näihin liittyvät tilat ovat poistettu. Jos haluat piirtää ruudulle vaikka kolmion, täytyy siitä rakentaa verteksitaulukko ja koko roska siirtää kerralla näytönohjaimelle.

Em. verteksitaulukkoa ei voi rakentaa käyttäen ClientState -palikkaa, jota ei enää ole olemassa. Vanhat funktiot glColorPointer, glIndexPointer, glNormalPointer, glVertexPointer ja kumppanit ovat siis poistuneet. Verteksit kuuluu laittaa Vertex Buffer Objectiin (VBO), joita voidaan sitten bindailla GLSL-shadereiden in-attribuutteihin. Näitä käytetään shadereissa sitten samaan tapaan kuin vanhoja gl_Vertex, gl_Normal ja muita gl_-sisäänrakennettuja muuttujia.

Matriisipinoa ei enää ole OpenGL:n puolesta. Ei glFrustum, glOrtho, glLoadIdentify, glLoadMatrix, glMatrixMode, glMultMatrix tai edes glPush/popMatrix tai glRotate/Scale/Translate -funktioita tai mitään muuta vanhaan sisäänrakennetun matriisipinon toimintaan liittyvää.

Kaikki valoihin ja materiaaleihin liittyvät asiat ovat lähteneet, koska ei ole enää mitään oletusrenderöintitapaa, ainoastaan itse rakennettuja shadereita. Toisin sanoen glMaterial/glLight ja vastaavat toiminnallisuudet täytyy toteuttaa itse jollain uniform-muuttujilla tai miten tahtookaan.

Display listejä ei ole enää olemassa, eikä Quadeja tai mitään muitakaan polygoneja kuin vain kolmioita.

Tekstuuritkin saivat oman osuutensa raivosta, mipmappeja ei generoida automaattisesti (tosin ne voi edelleen luoda helposti), formaatteja vähennettin ja CLAMP -wraptyyli sekä tekstuurien reunat poistettiin.

Lisäksi loppuun lajitelma satunnaisista tutuista asioista, joita ei enää voi käyttää. glFog, glAlpha/glAlphaTest ja glCopyPixels lähtivät. Accumulation bufferit, evaluaattorit ja glRasterPos ovat historiaa, kuten myös glCopyPixels, glClipPlane, sekä attribuuttipinot (glPushAttrib jne).

Pienenä yksityiskohtana mainittakoon, että viivojen paksuutta ei voi enää määritellä yhtä pikseliä paksummaksi!

OpenGL 4

Poistamisen sijasta OpenGL 4:ssa tuli sitten kaikkea kivaa uutta, eikä enempää vanhaa tavaraa poistettu. Onkin vaikeaa nähdä enää mitään yhteistä vanhojen OpenGL 2.0/1.x -rajapintojen kanssa.

Ja kuka opetti herroille versionumeroiden käyttöä, Patrick Volkerding ehkä? Tässäpä lista OpenGL-versioiden ja vastaavien GLSL-versioiden yhteydestä.

OpenGL	GLSL
2.0	1.10
2.1	1.20
3.0	1.30
3.1	1.40
3.2	1.50
3.3	3.30
4.0	4.00

Onneksi hypättiin GLSL 2 kokonaan yli, silti (GLSL) 4.00 < (Shader Model) 5.0 ja (OpenGL) 4.0 < (DirectX) 11, vielä pitää hyppiä lisää!

Uudet Windows-maailmasta tulevat Linux-käyttäjät usein ihmettelevät:

“Missä tässä on palomuuri?”

Vastauksena annamme aina, että

“iptables on n^x kertaa parempi kuin mikään Windowsin lelupalomuureista, ja iptablesilla voi vaikka integroida ankkoja!”

Yllättäen tämä perustelu ei kovin usein toimi, joten jatkovastaukseksi sitten toteamme, että “iptablesia voi hallita monilla eri graafisilla härpättimillä, mutta toisaalta Linux on niin turvallinen, ettei mitään palomuuria edes tarvi”.

Ajan kanssa ihmiset sitten aivopeseytyvät jonkinlaiseen harhaluuloon, että iptables/NetFilter jollain tapaa soveltuisi työpöytäkäyttöön, tai unohtavat palomuurin kokonaan.

iptablesissa ei ole mitään henkilökohtaista

Windowsin kanssa käytettävät henkilökohtaiset palomuurit ovat totaalisen eri asia kuin Linuxin palomuuri! Eritelläänpäs vähän asiaan liittyviä käyttötapauksia:

• Käyttäjä käynnistää satunnaisen softan X, joka ottaa yhteyttä tekijän palvelimelle, tarkistaa onko tullut päivityksiä, ja siinä ohessa siirtää kaiken käyttäjän arkaluonteisen materiaalin kotihakemistosta ohjelman X tekijälle (tokihan vain palvelun kehitystarkoituksessa!)

Windows-palomuurin reagointi: “Haluatko päästää ohjelman X nettiin?”
Linux-palomuuri reagointi: Nada.

• Käyttäjällä on vahingossa NFS/Samba-jako auki myös nettiin päin. Kuka tahansa pääsee kiinni käyttäjän tiedostoihin, tai ainakin saa mahdollisuuden murtaa salasanan.

Windows-palomuurin reagoi: “Haluatko, että ohjelma X kuuntelee yhteyksiä”
Linux-palomuuri reagoi: Jos palomuuri on konfiguroitu, niin ei hätää.

• Käyttäjä haluaa hostata verkkopeliä jossain satunnaisessa portissa, ja kutsuu kaverinsa mukaan pelaamaan, kertoen samalla portin.

Windows-palomuurin reagointi: Sama kuin aiemmin, kysytään käyttäjältä.
Linux-palomuurin reagointi: Jos palomuuri on konfiguroitu normaalisti, niin peli ei toimi. Jos palomuuria ei ole, niin tämän kanssa ei ole ongelmaa. Jos portti olisi vakio, se on voitu konfiguroida oikein.

Miksi palomuuri käsittelee edelleen yksittäisiä paketteja?

Minä haluan minun palomuurini olevan dynaaminen ja kysyvän minulta lupaa erilaisten asioiden tekemiseen, jos en ole jo aiemmin antanut sääntöä tilanteeseen. Kaikkia seuraavia asioita yksinkertaisesti ei pysty tekemään iptablesilla (joitain pystyy purkahtavalla skriptaamisella tai ikäväkäyttöisillä ACL-palikoilla):

• Ohjelma kysyy lupaa verkkoyhteyksiin ja yhteyksien kuunteluun. Asiaa kysytään oikealta käyttäjältä, ja verkkoyhteys ei onnistu ennen kuin vastaus on saatu, tai tilanne sopii aiemmin määriteltyyn sääntöön.
• Ohjelmalle voidaan antaa lupa verkkoyhteyksiin (tietyin ehdoin) tietyksi ajaksi, tai vain tälle tietylle instanssille. Eli kun ohjelma sammuu, se ei enää pääse verkkoon kysymättä uudelleen lupaa. Toisaalta kahdesta samasta käynnissä olevasta ohjelmasta vain toiselle annetaan lupa.
• Tietylle binäärille (esim /usr/bin/firefox) annetaan lupa päästä verkkoon, mutta vain tietyille käyttäjille. Vieras-käyttäjä saa ottaa ainoastaan TCP-yhteyksiä, ja niitäkin vain portteihin 80 tai 8080.
• Yksittäiseen TCP-yhteyteen annetaan erikseen lupa, esim yksi wget-haku. Prosessi ei saa ottaa muita yhteyksiä, ja uusi lataaminen aiheuttaa uuden kysymyksen.

Ratkaisuntapainen

Kirjoitin jokunen aika sitten kaikki aiemmat ongelmat ratkaisevan palomuuriohjelman Linuxiin. Siinä oli kolme eri komponenttia:

1. Linux Security Modules -rajapintaa käyttävä ajonaikaisesti lisättävä kernel-moduuli, joka toimi siihen aikaan muiden LSM-moduulien kanssa kiltisti, ja on todella kevyt, esim paljon NetFilteriä (se palikka, joka toteuttaa iptables-säännöt) nopeampi niissä yksinkertaisissa säännöissä, mitä moduuli itse osaa toteuttaa.
2. C++:llä toteutettu user space daemon, joka käsittelee ja ylläpitää monimutkaisempia sääntöjä verkkoyhteyksille. Tämä ohjelma on suoraan yhteydessä koneen kernel-moduuliin.
3. Pythonilla koodattu client-ohjelma, joka integroituu gnome-työpöytäympäristöön ja keskustelee käyttäjän kanssa. Jokaisella X:ään loggautuneella käyttäjällä on oma client-prosessi käynnissä. Tämä osaa olla useaan eri daemoniin yhteydessä, eli omalta koneelta voit hallita myös ssh-tunnelin yli ajettavien ohjelmien yhteyksiä.
   Client ilmoitti aina kun uusi ohjelma ottaa yhteyttä, ja antaa mahdollisuuden sallia/kieltää tämä kyseinen yhteys, tai laatia sääntö ongelmaan.

Kernelin muutos

Idiootit menivät sitten rikkomaan LSM:n (myönnettäköön, että oikeastaan he lähinnä korjasivat sen, mutta ärsyttää se silti), ja poistivat siitä tuen LSM-moduulien pinoamiseen ja ajonaikaiseen lisäykseen. Nyt siis nykyisillä kerneleillä palomuuriohjelmaa ei voi ottaa ajonaikaisesti käyttöön, vaan se vaatii Kernelin puukotuksen, uudelleenkäännön ja bootin. Lisäksi esim SELinux ei enää toimi yhtä aikaa tämän palikan kanssa.

Tein moduulista myös uuden version, joka ei enää käyttänyt LSM-rajapintaa, mutta joka tapauksessa vaatii oman kernelin.

Mutta missä koodi?

Pahoittelen screenshot-kuvien laatua, ne ovat vanhoja kuvia, client-ohjelmakin oli siinä vaiheessa vain “gui-test”, eikä se lopullinen client. Siitä en löytänyt screenshotia tähän hätään, eikä ohjelma ole tällä hetkellä erityisen käyttökelpoinen.

Yritän joku päivä löytää vähän aikaa ja saada softan (työnimi mielikuvituksellisesti “Linux Personal Firewall”) toimimaan vaikkapa uusimman Ubuntun kanssa nätisti ja samalla julkaista koodin. Tosin haaveilen edelleen siitä, että systeemin saisi toimimaan jotenkin ilman kernelin puukotusta.

Päivitys 2.11.2009: Korjailtu juttuja

En haluaisi olla tuomitseva, mutta todettakoon WebOodin olevan jotain täysin käsittämätöntä kuraa! Kuitenkin järjestelmää lienee pakko käyttää jos haluaa opiskella, vaikkakaan mitään tutkimustietoa ei ole systeemin mahdollisesti aiheuttamista pysyvistä aivovaurioista.

Tervehenkinen ratkaisu oli siis tehdä skripti, joka loggautuu WebOodiin, hakee tiedot kursseista ja pulauttaa harjoitukset, tentit ja luennot yleisesti tuettuun iCal(endar)-muotoon.

Tämän saa sitten lähestulkoon minne vain, eri kalenteriohjelmat ja puhelimien synkkaussoftat osannee iCal:a ihan näppärästi. Google Calendar on yksi suosittu vaihtoehto.

Huom, tässä vaiheessa itsesuojeluvaiston kuuluukin varoittaa räjähdysherkästä yhdistelmästä “Satunnainen skripti jostain satunnaisesta blogista” + “Kehyspohjaisen ja todella epämääräisen sivuston html-parsiminen” + “Yliopiston tunnukset”.

Tokikaan ei voi myöskään unohtaa sitä, että muutokset WebOodissa saattavat rikkoa skriptin.

Skripti ei toistaiseksi osaa näyttää kuin sellaisen kurssien tiedot, joihin on ilmoittauduttu, eikä viritelmä toimi luultavasti muutenkaan muualla kuin TKK:n WebOodissa. Helsingin Yliopiston systeemiin kirjautuminen toimi, mutta siellä on aikatiedot esitetty eri tavalla, enkä jaksanut sitä implementoida, ainakaan vielä.

Niin sanotusti myöhemmin voisi jopa tehdä mahdolliseksi ilmoittautua kursseille skriptin kautta puoliautomaattisesti.

Lisää tietoa löytyy --help -vivulla. Lähdekoodit löytyvät GitHub-projektista.

Käyttöönotto

$ git clone git://github.com/tonttu/WebOodi-tool.git
$ cd WebOodi-tool/
$ sudo setup.rb

Jos et halua/voi sudottaa, voi myös komentaa suoraan bin/weboodi.

Kalenterin luonti

$ weboodi ical > kalenteri.ics
... http-lokia yms roskaa
Username: <käyttäjä>
Password: <salakala, hutin tapauksessa service password>
... lisää http-lokia
Done.

Jos laitat kalenterin Apacheen näkyville, varmista että tarjoilet oikeanlaisen merkistön. Esim. Google Calendarille ei kelpaa oletuksena UTF-8, vaan se täytyy erikseen ilmaista.

.htaccess:

AddCharset UTF-8 .ics

Nykyinen nössöilysukupolvi on tottunut nettisivuihin, jotka ovat täynnä kaikkea turhaa ylimääräistä sälää, kuten kuvia ja muuta huuhaata. Tästä johtuen en voinut kuin antaa periksi ja piirrellä itsekin vähän grafiikka. Ylös lähti tuollainen meluhärveli sloganin tueksi, ja alareunaan tipahti tuikkiva tähti.

Nörttihän ei grafiikkaohjelmistaan maksa mitään, vaan inttää kuinka hyviä oikeiden ohjelmien open source -kopiot ovat, kun niitä vain ensin vähän opettelee, ja vähän ehkä pätsäilee sieltä sun täältä. Tämä on tarina siitä, miten aurinko ja torvi syntyivät.

Apophysis

Piirtäminen on heikoille, todellinen mies generoi tekstuurinsa fraktaaleilla käyttäen monivivahteikasta jostain kumman syystä Delphillä koodattua ihmeellistä ohjelmaa nimeltä Apophysis. Softa toimi ihan normaalisti winen päällä, ja oli ainoa ohjelma tällä sivulla esitellyistä, joka ei kaatunut kertaakaan prosessissa!

Käyttöohje:

1. Klikkaile erilaisia nappeja
2. Jos ei vieläkään näytä hyvältä, palaa vaiheeseen yksi
3. Valmis!

Toisin sanoen käyttäjän kuuluu harjoittaa geneettistä algoritmia ohjelman eri vivuilla. Populaation saa aluksi maagisella näppäinyhdistelmällä ctrl+b.

Lisäksi, miten Apophysis voisi edes teoriassa olla huono, kun jaettavan binäärin nimessäkin esiintyy merkkijono “3D hack”?

Gimp

Seuraavaksi tarvitsinkin Gimpiä, tätä järisyttävän vajaaälyistä, hidasta ja vaikeakäyttöistä Photarinkorviketta.

Ohje:

1. Avaa edellisen vaiheen generoituja tekstuureja
2. Osta kaupasta vähän lisää muistia (neljä gigaa ei oikein meinannut riittää), ja avaa sitten vähän lisää tekstuureja.
3. Lättää kuvat satunnaisesti päällekäin ja painele taas mahdollisimman erilaisia nappeja layer-asetuksista, kunnes näyttää sopivalta. Älä unohda arpoa kerroksille jotain läpinäkyvyysarvoa!

Ekstrana pulautin tulevaisuudesta hetken päästä Blenderillä tekemäni aurinkopallon yläosan “unwrapatun” UV-mapin jotta tiesin mihin kohtaan en laita kovin omituisia kuvioita.

Blender

Edellisestä vaiheesta kun pääsi eroon, loin wannabe-3D-tuotanto-ohjelma Blenderissä pallon, tai ainakin sen yläosan painamalla välilyöntiä ja tekemällä satunnaisia akrobatialiikkeitä. Blenderin näppäinyhdistelmiä on mahdotonta muistaa ulkoa, eikä keskikokoisen tulostimen paperikapasiteettikaan välttämättä riitä näppäinkarttojen printtaamiseen. Paras tapa sen sijaan on jatkaa alkuperäisellä linjalla ja painella nappeja satunnaisesti.

Huom, jos Blenderissä painaa väärää nappia, saattaa peruuttamattomasti poistaa maailmankaikkeuden. Tosin, se saattaa silti löytyä jostain toisesta undopinosta, kunhan ei vain vahingossa tee mitään muutoksia mihinkään toisiin objekteihin.

Anteeksiantamatonta on myöskin vahingossa undota vaikka h-napin vahinkopainallus (piilota valittu objekti). Tällöinhän ei tietenkään tämä näkymämuutos peruunnu, vaan jokin satunnainen muu muutos. Ja tätähän ei tajua ajoissa, kun objektia ei saa millään näkyviin (paitsi jos satut tietämään yhdistelmän alt+h).

Gimp #2

Blender pysyi vahingossa tarvittavat monta minuuttia pystyssä, joten sain kuvan renderöityä ja pulautettua takaisin Gimpiin. Toistin saman operaation kuin aiemminkin, eli laitoin asioita layereihin ja painoin satunnaisia nappeja ja valitsin arvalla vaihtoehtoja erilaisista pudotusvalikoista. Tosin tällä kertaa käytin pienempiä kuvia, joten muutoksetkin päivittyivät nopeasti.

Maskilla ja gradientilla sai poistettua alpha-kanavaa sopivasti, että “liekkejä” sai vaimennettua niiden kasvaessa ylöspäin. Toisella layerilla säädin sitten punasävyn muuttumaan taustaväriksi.

Inkscape

Lopuksi käytin jo neljättä open source -tuotosta, vektoripiirtosoftaa Inkscapea. Tämän versiohallinnasta piti harrastaa puolitushakua (tarvitsi onneksi vain muutaman iteraation), jotta löytyi versio jossa

1. oli mukana Spiro-käyrät ja
2. kyseisten käyrien käyttö ei kaatanut koko ohjelmaa.

Lopulta en kyllä toki käyttänytkään ollenkaan mitään Spiro-juttuja, mutta ovathan ne nyt mageita.

Valitettavasti Inkscapea en uskalla juurikaan haukkua, koska se taitaa ihan oikeasti olla käyttökelpoinen otus, ainakin se hakkaa FreeHandin.

Lopuksi voikin vain tuskailla sitä, miten tuollaisen aurinkokuvan voi sitten saada esitettyä mitenkään kevyesti nettisivulla?

Ihmettelin vähän aikaa sitten, voiko HDMI-piuhaa (tai oikeastaan HDMI-DVI-piuhaa) katkaista ja kolvata/mitälie yhdistää takaisin itse niin, että kuvakin näkyisi vielä.

Netissä oli vähän epämääräisiä lähteitä asiasta, mutta koska tietokoneeni ja teeveeni välissä on seinä, ja seinässä vain piuhan kokoinen reikä, katkaisin piuhan sen enempää miettimättä.

Vähemmän yllättäen sisältä paljastui varsinainen sekamelska, mutta hetkellisen juottamisen jälkeen sain ainakin enemmistön johtimista oikein. Kuva näkyy tällä uudelleenkolvatulla piuhalla 1080p60 -laadulla täysin virheettömästi.

Kaapeli oli jokin halvin viiden metrin johto mitä löysin.

Xorg

Laitetaan samalla vielä liitteeksi vähän xorg.conf-muutoksia, millä saa Nvidian näyttiksestä näppärästi kuvan telkkuun. Lisätään esim jotain tällaista (HorizSync/VerRefresh tuskin on tarpeellisia, mutta kaivoin television manuaalista tuollaiset luvut):

Section "ServerLayout"
    Identifier     "TV"
    Screen      0  "TVScreen" 0 0
EndSection

Section "Screen"
    Identifier     "TVScreen"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option "TVStandard"   "HD1080p"
    Option "TripleBuffer" "true"
    Option "HorizSync"    "66.587"
    Option "VertRefresh"  "59.934"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Tämän jälkeen voi käynnistää toisen X:n TV-konfiguraatiolla. Itselläni on siis kaksi näyttöä kiinni koneessa, joten käytännössä vain jompi kumpi konfiguraatioista on kerralla käytössä. Jos käyttäisin vain yhtä näyttöä, kannattaisi systeemi konffata tietenkin ihan eri tavalla.

X:hän käynnistyy esim näin: startx -- :1 -layout TV