cazfi

Samaa sarjaa

Kolme riviä,
kaksi riittää sanomaan.
hummummummuumum

Isi hävisi.
Leuhkimisen aihetta.
Oma lapsi voitti.

Kovin pitkään kevään 2010 Isin mitta kirjoituskokeilua ei harrastettu. Kuluneella viikolla se muistui mieleeni pohtiessani mistä saisin yhtään mitään sanottavaa.
Tekeleitäni ei löytynytkään niin helpolla kuin olin kuvitellut. Kunnollista varmuuskopiotakaan ei viimeisimmästä versiosta löytynyt. Päivän ajan harmittelin kaiken joutuneen hukkaan. Sitten keksin tarkistaa vielä yhden varmuuskopion, johon aikanaan olisi voinut tulla mukaan asiaan liittyviä merkintöjäni. Löytyihän sieltä runoista muutamia.

Huutokilpailun
häviäjiä: veli
sekä naapurit

Jumalten tuho (Juri Nummelin)

Kun kirjan genreksi mainostetaan pulp-scifi-trilleriä ennakko-odotukseni eivät olleet alunperin kovin korkealla. Kirjailija Nummelinin antamat ennakkomaistiaiset olivat odotuksia kohottaneet sen verran että aivan täyttä skeidaa en enää kirjaan tarttuessani pelännyt kohtaavani.
Joskus tuntuu että pulp on jo määritelmänsä mukaan lukukelvotonta. "Pulpin täytyy olla huonoa ollakseen hyvää." Tämä kirja osoittaa että myös pulp voi olla hyvin tehtyä. Sujuvaa tekstiä on helppo ja nopea lukea.
Omassa lajissaan kirja on loistava. Sen näkemiseksi lukijan täytyy nähdä vain hitusen vaivaa asennoituakseen kirjaan oikein, oman tyyppinsä edustajana. Mitään muuta vaivaa lukijalle ei sitten jääkään - sanat virtaavat, ja viittaukset muuhun kirjallisuuteen ovat niin ilmeisiä että hullukin ne huomaisi. Tai ainakaan syvällisemmällä pohdinnalla kirjasta ei saisi sen enempää irti. Sen siitä ymmärtää mihin omat tiedot riittävät, ja tietämättömyyttä ei mikään pohdiskelun määrä pystyisi korvaamaan.
Genreä huonosti tuntevalle monet ideat tuntuivat suorastaan raikkailta, joskin välillä minäkin näin että tiettyjä vaikutteita on varsin sumeilemattomasti käytetty. Kertaalleen jopa puuskahdin kerettiläisen ajatuksen: "Onkohan Juri keksinyt tähän mitään itse."
Sujuva teksti ja nopeatempoisuus, eli tapahtumien määrä, kantavat lähes koko kirjan läpi, vaikka sitten kerralla luettavaksi. Suuri lopputaistelu ikävä kyllä pyörähtää samankaltaisten tapahtumien määrässä ylitse, ja kääntyy sitä myöten melkeinpä antikliimaksiksi. Siinä tapahtuu liian paljon, liian pitkään, ja liian yksipuoliseen tyyliin. Ammutaan, suolet lentää, ammutaan, aivot lentää, ammutaan, saadaan uusi superase, ammutaan, käsi repeää. Tämän osuuden läpi lukeminen onnistui kuvittelemalla samalla siitä tehtävään elokuvaan elävöittävää ohjausta. Sopivilla kuvakulman vaihdoilla, hidastuksilla, ja muilla elokuvateknisillä keinoilla homman saa vetämään.
En edelleenkään koe kuuluvani kirjan kohdeyleisön ytimeen. Loppupuolen muutamaa sivua lukuunottamatta kirjasta saamani nautinto on vain osoitus Nummelinin vahvuudesta kirjoittaa niin hyvin että se jo yksistään vetää lukijan mukaansa.

Article about resales of IPv4 addresses.

It's less than two week to World IPv6 day I already mentioned in January 19th entry.

IPv4 exhaustion counter (Regional) has following estimates at the moment. Jan 19, 2012 values in parenthesis:
AfriNIC: Africa: Nov 06, 2014 (Oct 20, 2014)
APNIC: South Asia and Australia : Apr 15, 2011
ARIN: US & Canada: Jun 20, 2013 (Jul 19, 2013)
LACNIC: South America: Jan 29, 2014 (Jan 30, 2014)
RIPE NCC: Europe, Middle-East & Northern Asia: Aug 14, 2012 (Jul 27, 2012)

Often bugs are caused by two software components simply being incompatible. One expects one thing, and the other implements another thing. While earlier versions work well together, change in either side can lead to incompatibility. One often sees people reporting their findings from version control where the bug was introduced. They have figured out what component is incompatible with some other, and then find out when and why it was changed to work the way it currently does.

What they often miss, is that it takes two sides to be incompatible.

It's not the first time when I've seen from the history that
1) A and B are compatible
2) A is changed in a way compatible to B
3) B is changed in a way incompatible to A with change 2
4) Someone sees that A works in a way incompatible with B and finds out that A was changed to its current behavior in change 2, so he blames developer of change 2 of poor quality control.

Levy rikkikki
Toistututututuva
Hakkerin kieli

Continuing my journey to OpenEmbedded development. Some people try to adjust themselves to suit tools given. I start any bigger SW contribution by adjusting tools to best fit my style of working for maximum performance.

- OE build shell - check - now I can easily test, back and forth, builds of individual components instead of having just one huge build hard to modify for any debug testing. Also means that simple tests take just minutes instead of hours full build takes.
- OE builds with Fullmoon - check - not set up for nightly builds yet, but big builds are easy to run through fullmoon and if I want the nightly builds it's just matter of enabling them

My development computer runs hot as it tries to build all the projects I'm playing with. Round of build tests with FullMoon resulted not only modifications of FullMoon itself, but crude (as in: for testing only, I don't expect it to get accepted) FreeOrion patch. Also deb-packaging I maintain of one of FreeOrion's dependencies, Bullet, got updated to new upstream version. I finally got Spring RTS Engine to build with FullMoon. That work resulted in one patch submitted to SpringRTS.
As I'd like to build OpenEmbedded images that use deb-packages, I have been fixing that side, and submitted my first couple of OpenEmbedded patches. Those update dpkg and apt versions used in OpenEmbedded, and while working on them I found minor issues in apt that lead me to submit couple of patches to apt upstream (Debian) too.

Add some crosser and Freeciv development to that, and last two nights have been quite productive.

Perigee full moon in a couple of days, but there's nothing important committed to FullMoon to justify release. In fact it's possible that there will never be another FullMoon release.
When I started developing FullMoon I had the idea that each release would have name in addition to version number. I finally decided that those names should come from Kalevala, national epic of Finland. Initial versions were called Alkumuna, and current versions are called Ilmarinen after the blacksmith and inventor that can create anything (including software builds, apparently). Now, name Ilmarinen suits current FullMoon much better than FullMoon. Were I naming the project now, I would definitely select Ilmarinen over FullMoon. And even with all the hassle involved, I'm probably going to rename the project. So, it's possible that there is no more FullMoon releases, or only a couple of FullMoon releases, but there will be Ilmarinen releases in the future.

Crosser on the other hand is likely to really get seriously cut. Recent OpenEmbedded development has made it suit almost perfectly the use-cases I originally had for cross-compiler side of the crosser, and much more. I'm not 100% certain yet (there's some minor issues to solve) but it seems that much better results could be achieved by using, and contributing to, OpenEmbedded than by wasting time to crosser development.
Windows dllstack side of crosser project will remain alive in any case. Just two months ago I moved their hosting from resource-poor cazfi.net to sourceforge: Crosser sourceforge-page.

Being sick I decided to finally set up freeciv autogame testing environment for S2_4 branch, and let my computer spend time running those tests when I'm not using it in any development work. While those tests have many times proven to be valuable in finding hidden bugs, I usually have not much capacity to spend on them. Instead I'm running just basic tests for patches I'm currently developing, and building stuff like crosser environments take their part of computer time as well.
It occurred to me that running these tests requires little more than availability of computer to run them on. Running them requires no deep programming skills, artistic ability, or fluency in language. So maybe someone would take some of the workload of my freeciv development machine to their own computer, freeing my computer to do more work on actual development side, and maybe actually doing more testing than what I can currently afford on my own hardware, improving freeciv quality.