Coding in an absurd reality

From the article about Daniel Dennett:

In October 2006, Dennett was hospitalized due to an aortic dissection. After a nine-hour surgery, he was given a new aorta. In an essay posted on the Edge website, Dennett gives his firsthand account of his health problems, his consequent feelings of gratitude towards the scientists and doctors whose hard work made his recovery possible, and his complete lack of a "deathbed conversion". By his account, upon having been told by friends and relatives that they had prayed for him, he resisted the urge to ask them, "Did you also sacrifice a goat?"

This made me laugh out loud, even though I am completely alone in my home at the moment. I hope someone will sacrifice a goat if I'm ever hospitalized.

Altijd fijn als instantie vlot van zich laten horen na een vraag. Eergisteren halveerde de waterdruk in mijn appartement opeens en sindsdien varieert de druk tussen die helft en de normale druk. Dat is goed te overleven, hoewel het vervelend is als die variaties net voorkomen als je onder de douche staat, aangezien de temperatuur daar ook behoorlijk van gaat schommelen. Aangezien de druk van het koude water ook varieerde, vermoedde ik dat de oorzaak weleens buiten mijn appartement kon liggen. De buren bleken het inderdaad ook gemerkt te hebben, dus belde ik vanmorgen Dunea met de vraag: "Is er iets mis?". Ze wisten het niet, maar zouden het uitzoeken. Nog geen twee uur later kreeg ik telefoon van Dunea: ze zijn in de buurt aan het werk en daardoor kan de druk inderdaad weleens varieren. De werkzaamheden zullen tot ongeveer maandag duren. Bravo.

Telecombedrijven... ze hebben het tot kunst verheven om hun klanten te bedriegen en ze op die manier op torenhoge kosten te jagen. We kennen allemaal de verhalen van mensen die per ongeluk een dienst aan hadden staan op vakantie en honderden euro's moesten betalen, terwijl ze de dienst niet eens gebruikt hadden. Heel klantvriendelijk allemaal.

Sinds de nummerinformatie dienst in april 2007 is vrijgegeven werden we overspoeld met commercials voor weet-ik-veel hoeveel verschillende nummers. Dat moet natuurlijk ergens van betaald worden en vandaag vertelt de OPTA ons hoe: een aantal diensten heeft zo goed mogelijk verborgen geprobeerd te houden dat ze ook na het doorverbinden hun tarief van pakweg 70 cpm blijven rekenen. In het nieuwsbericht worden specifiek 1850 en 1888 genoemd. De eerste is een onafhankelijk bedrijf (lees: een lepe afzetter die vindt dat hij op deze manier flink mag cashen), maar de tweede is KPN. De van oudsher betrouwbaar geachte oervader van de telecom in Nederland... weer een reputatie door de plee.

Ratten zijn het, allemaal.

• Act 1. Someone makes an outrageous claim about a programming language.^[1]
• Act 2. Someone points that claim out to others.^[2]
• Act 3. Someone compares a snippet of code in the original article to his version in his preferred language and asserts that language is superior.
• Act 4. Someone, in this case me, points out that the exact same solution is possible in the original language. ^[3][4]

A flamewar ensues, where people try to show that their solution in their favorite language is better. Well, that didn't really happen, but it makes for a more dramatic ending.

^[1] I don't claim he's serious. In fact, I think he just ends his post on a tongue-in-cheek, semi-hopeful note.
^[2] Singling out the least interesting part of the blog post as the title of his submission, IMHO
^[3] Which explains the title of this post: if you don't have at least that much understanding of a language that you know whether a certain solution is possible or not, than you probably shouldn't be commenting on it.
^[4] Act 4 has many variations, but usually people produce a different solution in the original language that approaches the solution in the alternative language.

For anyone else trying to install DB2 Express C, the free community edition of IBM's DB2, on his linux system and running into problems:

• You need to source sqllib/db2profile in every shell where you are going to run commands from sqllib/bin:
  code:
  

  1	confusion@ulm:~$ . sqllib/db2profile

• Running the db2val validation program multiple times in a row can yield different results. For instance, on the first attempt, it told me it couldn't find the sqllib/logs directory. However, that one was already present (perhaps created by db2val?) and when I ran the validation program again, it noticed that.
• If db2val fails to start your instance with

  SQL1220N The database manager shared memory set cannot be allocated.

  then you probably need to increase the maximum amount of shared memory the kernel may allocate:
  code:
  

  1	sysctl -w kernel.shmmax=268435456

  
  The default is 32M and this increases it to 256M, which turned out to be enough. For 64-bit systems, they advise pushing it to 1GB.
  
  Edit: As moto-moi points out in the comments, this is a temporary change that will disappear with a reboot. To make it permanent, follow his instructions.
• If running
  code:
  

  1	confusion@ulm:~$ sqllib/adm/db2start

  returns

  SQL10007N Message "-1390" could not be retrieved. Reason code: "3".

  then you probably forgot the first step I described here.
• If you try to make a connection from your favorite programming language and you receive

  ROOT CAPABILITY REQUIRED

  then you probably did a non-root install. Unfortunately, DB2 doesn't have any DB-level users: all user management, including authentication, is delegated to the OS. On a *nix system, the routine checking the password usually requires root privileges. The problem is that the file sqllib/security/db2ckpw needs to be owned by root and needs to have its setuid bit set:
  
  code:
  

  1 2	chown root db2ckpw chmod u+s db2ckpw

  
  I first found the file sqllib/security32/db2ckpw, but that doesn't seem to be used on linux. Might be the Windows version? Afterwards, perform a
  
  code:
  

  1 2 3

  db2 force applications all db2stop db2start

  
  The first command breaks all connections, otherwise the db2stop probably won't work.
• Keep an eye on sqllib/db2dump/db2diag.log: that's where interesting logging about DB2's functioning ends up. The db2diag command can be used to extract information from that file and can be used to tail it, if you haven't done so already.
• A warning I encountered in the db2diag log was

  The user per process file descriptor limit of 1024 is less than the maxfilop setting of 30720

  This can be solved by issuing
  
  code:
  

  1	ulimit -n 32768

  
  However, that usually won't work, as the default limits prevent you from going above 1024. To overcome that limit, add the following line to /etc/security/limits.conf
  
  code:
  

  1	your_db2_user hard nofile 32768

  
  After that, you need to open a new shell (for that user) (if you are running an X environment: restart X) and the new shell will have it maximum number of file descriptors set to 32768 after you issue the ulimit command. Now all you need to do is restart DB2.