Oho, hieno kyberfontti!

Empatiakyvyttömyys voi olla puolustusmekanismi silloin, kun toisen vaikeudet tuntuvat liian pahoilta tai on joku muu tarpeeksi hyvä (kyvyttömyyden tapauksessa tiedostamaton) syy olla ottamatta niihin osaa.

Joidenkin (empatiantarpeessa olevien) kohdalla se voi olla ihan tietoista haluttomuuttakin. Ainakin minulla se on kytköksissä siihen mitä tunnen kutakin ihmistä kohtaan noin muutoin, eli miten paljon piittaan kunkin kärsimyksistä. Aiemmin ajattelin, että sellaisiakin kärsiviä, joista ei pidä, pitäisi sääliä. Nykyisin en haaskaa energiaani sellaiseen, osaan olla vahingoniloinen ilman turhaa syyllisyyttä.

My translation is now up. You might get a pingback from WP too. Thanks!

Hi Andy. I was wondering if you have set a license for your blog. I’m thinking of republishing this post in Finnish (after translating it myself), but I wouldn’t want to break any terms you may have set. You have good points I’d like to raise with local decision makers if I get the chance.

Shouldn’t this disambiguation also list offering as in commerce? I’m asking instead of adding it directly because I only just now came across the corresponding term in my native language, but it seems pretty elementary in commerce.

According to the article, ”PCL-R officially lists four factors (1.a, 1.b, 2.a, and 2.b)”. Yet ”The two factors” only lists Factors 1 and 2 without dividing them into 1.a, 1.b and 2.a, 2.b. Is this a deliberate omission or a slip?

Minulla hädin tuskin kynä enää pysyisi kädessä, mutta lopputuloksen surkeus ei koskaan ollut läheskään yhtä iso este harrastukselle kuin se, etten keksi mielekästä piirrettävää. Jonkin olemassaolevan jäljentäminen tuntuisi ihan turhalta (kamerat ovat sitä varten), eikä mielikuvitukseni ole koskaan tuottanut mitään visuaalisesti omaperäistä.

Ihanat värit!

After dozens and dozens of boots with the 3.2.0-14 and 3.2.0-15 kernels, here’s what I know.

1. This *is* tied to wistron_btns as I reported. Without it, boot never fails (the way I initially reported, though I’ll redefine what ”fails” means further below).
2. With non-pae kernels, boot never fails.
3. With 3.2.0-14-pae, the boot always fails.
4. A cold boot with 3.2.0-15-pae never fails.
5. A re-boot with 3.2.0-15-pae after a *non-failing* boot never fails.
6. A re-boot of 3.2.0-15-pae, after a *failing* boot (of 3.2.0-14-pae for instance), is *almost* sure to fail. I’d give it a 10% chance of not failing.

If you put it another way, this appears is pretty interesting:
1. You can ”break” 3.2.0-15-pae by booting 3.2.0-14-pae first.
2. You ”fix” a thus ”broken” 3.2.0-15-pae by booting a non-pae kernel.

I suspect this brokenness is actually hidden in the hardware, in something (the wifi key perhaps?) controlled by wistron_btns. Booting 3.2.0-14-pae puts the controller(?) in a ”broken” state from which 3.2.0-15-pae can’t recover, but a non-pae kernel can. And though 3.2.0-15-pae can’t recover a ”broken” controller, it also cannot put it into that ”broken” state (which is a good turn of development).

So now, about that ”fails” part.

I discovered by accident that although the system appears to freeze in boots I referred to as ”fails”, it has in fact been brought down to *almost* complete halt, but *just* almost. If I’m patient enough to wait, it does actually boot into LDM, from where I can switch to another VT and log in… slooooooowly.

Thus I was able to find out what’s going on that makes it so slow:

jani@amilo:~$ head dmesg.fail
stron_btns: Unknown key code 10
[ 1011.554522] wistron_btns: Unknown key code 10
[ 1011.554722] wistron_btns: Unknown key code 10
[ 1011.554921] wistron_btns: Unknown key code 10
[ 1011.555120] wistron_btns: Unknown key code 10
[ 1011.555320] wistron_btns: Unknown key code 10
[ 1011.555518] wistron_btns: Unknown key code 10
[ 1011.555717] wistron_btns: Unknown key code 10
[ 1011.555916] wistron_btns: Unknown key code 10
[ 1011.556134] wistron_btns: Unknown key code 10
jani@amilo:~$ grep wistron dmesg.fail | wc -l
2520

Note that this is unrelated to pressing any actual physical buttons. It’ wistron_btns misbehaving under the conditions I described above.

According to a Xiph mailing list message from 2003,

ogginfo should check most things, at least the CRC integrity of everything.

I don’t know whether ogginfo is available for Windows though. You’d also have to script the recursion part, as ogginfo doesn’t do that (at least on UNIX).

jani@amilo:~$ LC_ALL=C aptitude show linux-image-3.2.0-14-generic-pae | grep ”more then”
Geared toward 32 bit desktop systems with more then 4GB RAM.

I believe the fix is to ’s/more then/more than/’ in DEBIAN/control.