But what brings GNOME 3.2? A lot of people are unhappy and some of these points are valid and need to be fixed. Others can be discussed if they are true. One thing that changed in 3.2 is how GNOME interacts with your address book and your instant messaging accounts. Connections to instant messaging networks are automatically being started when you log in. This also reflects in the search screen when you type in a friends name and you direct see his connection status.

GNOME Online Accounts is another example of making things simpler for the user. Currently it only works for Google, but I really hope current proposals with querying the right SRV-records in DNS are also going to be part of GNOME in a future release. For now GNOME Online Accounts setups up multiple Google services up like Mail, Calendar, Chat, Documents and Contacts with a single authentication token. Different services don’t have to maintain and store the credentials in GNOME Keyring or in still in there own way. Hopefully there will come a solution for Liferea which still stores te users password plain-text in the configuration file.

Other third-party applications like Simple Scan, Shotwell and Deja-Dup are slowly making there way into becoming part of GNOME. I can’t wait to see what is going to happen with the GNOME 3.4 release as both Epiphany and Evolution are going to have some major work done to them. A switch to Webkit 2 and ending the usage of GtkHTML in Evolution. Hopefully after this Epiphany can replace Firefox completely on my desktop.

It is good to see the progress GNOME is making into becoming an interface for cloud services by simplifying the configuration for users, but also separating data from applications more and more. I can’t wait to see how GNOME Document is going to evolve, but two other things still open is a good solution for RSS-feeds and chat-logs as Empathy is still storing them on disk and isn’t able to use logs stored by Google for example.

In the end I’m happy with GNOME 3.2 in Debian Testing right now and Debian on my workstation is back to it’s weekly testing upgrade schedule as most parts are working. I even think that I will continue to do this during the 3.4 release as most of the GNOME dust has settled. Maybe I make an exception for both AbiWord and Gnumeric when they switch to GTK3 and hopefully also better OpenDocument support.

$ ls -l /etc/.pwd.lock
-rw-------. 1 root root 0 feb 27  2009 /etc/.pwd.lock
$ ls -l --time=atime /etc/.pwd.lock
-rw-------. 1 root root 0 apr 10  2010 /etc/.pwd.lock
$ ls -l --time=ctime /etc/.pwd.lock
-rw-------. 1 root root 0 aug 14  2010 /etc/.pwd.lock

As time match at least the installation date of the machine and exists on other machines it appears to be a valid file, but with what purpose? After reading the Linux Programmer’s Manual two functions called lckpwdf and ulckpwdf where candidates for using this file. Checking the source code at Sourceware confirmed that both lckpwdf and ulckpwdf are using the file. And reading the manpage about these functions also confirms it’s purpose, a lock file the commands like passwd.

The lckpwdf() function is intended to protect against multiple simulta‐
neous accesses of the shadow password database. It tries to acquire a
lock, and returns 0 on success, or -1 on failure (lock not obtained
within 15 seconds). The ulckpwdf() function releases the lock again.
Note that there is no protection against direct access of the shadow
password file. Only programs that use lckpwdf() will notice the lock.
 
These were the functions that formed the original shadow API. They are
widely available.

This is another example why open source matters. You can get the evidence when you want and/or need instead of trusting some manual to explain things. Verification will become more important as systems get more complex. It was/is also a big advantage when OpenSolaris was created with it’s web accessible source repository.

Na het upgraden van alle sysvinit-packages en een paar kleine aanpassingen aan /etc/default/rcS zag df er als volgend eruit.

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg00-root  19G  9.3G  8.2G  54% /
tmpfs                 5.0M     0  5.0M   0% /lib/init/rw
tmpfs                 788M  744K  788M   1% /run
tmpfs                 5.0M     0  5.0M   0% /run/lock
tmpfs                 1.6G  152K  1.6G   1% /tmp
udev                   10M  4.0K   10M   1% /dev
tmpfs                 1.6G  516K  1.6G   1% /run/shm
/dev/sda1             236M   47M  178M  21% /boot
/dev/mapper/vg00-home 854G  707G  104G  88% /home
/dev/sr0              6.6G  6.6G     0 100% /media/cdrom0

Nu worden /var/run en /var/lock ook met een symlink omgeleid naar /run en hiermee komt ook een einde eigenlijk dat packages directories kunnen aanmaken in /var/run bijvoorbeeld of een directory bestaat.

$ ls -ld /var/run /var/lock /tmp
drwxrwxrwt. 11 root root 280 mei 25 01:15 /tmp
lrwxrwxrwx.  1 root root   9 mei 23 22:51 /var/lock -> /run/lock
lrwxrwxrwx.  1 root root   4 mei 23 22:51 /var/run -> /run

Hiermee is eigenlijk de weg vrijgemaakt om de transitie van SysV init-style naar systemd v25 te beginnen, maar eerst is het wachten totdat alle packages Debian Testing bereiken zodat er enige vastigheid is. Met systemd v25 alleen nog in experimental kan dat nog wel even duren, maar aan de andere kant de freeze periode voor Wheezy is voorlopig nog niet gestart.

Nu terug op mix van GNOME 2.30 en 2.32 wordt wel langzaam duidelijk dat ik GNOME 3.0 toch een beetje mis. Er zijn nog voldoende dingen die niet af zijn of verbetering behoeven, maar het idee van interactie met je systeem, je data en je communicatie spreekt me wel aan. Hopelijk komt die transitie snel, maar of deze soepel zal verlopen? Zeker gezien problemen met GCC 4.6, Glibc 2.13 en de transitie naar /run. Ik kan al wel vast zeggen dat de testen met systemd als vervanger voor de traditionale init en SysV-scripts zeer goed zijn bevallen.

En ik zal maar gelijk beginnen met het oordeel. Is het wat of niet? Ja en nee, maar dat hangt van je doel af. Voor veel gebruikers is GNOME 2.32 voorlopig een betere optie en dat zal hoogstwaarschijnlijk zo blijven tot GNOME 3.2 en misschien wel tot 3.4. Releases die voor 6 en 12 maanden gepland staan. Voor ontwikkelaars van software en distributies is 3.0 beter geschikt. Ik zou GNOME 3.0 dan ook willen bestempelen als een developer preview.

Maar waarom is dat zo? De huidige transitie voor Debian is in volle gang, maar wordt wel eerst gedaan in Debian Experimental. Er zijn voldoende punten die moeten worden opgelost om de rest van de FOSS-wereld niet in de problemen te brengen. Zoals ook al te zien is zijn er sommige packages ook al in Debian Unstable geland, maar of de Debian Testing gaan halen binnen afzienbare tijd is de vraag. GTK+3.0 is in iedergeval al geland.

De installatie van GNOME 3.0 vanuit de experimental-sectie is wat problematisch, maar niet ondoenlijk en sinds gnome-session is geland kom je ook automatisch in de GNOME 3 desktopomgeving. En het ziet er allemaal netjes uit moet ik zeggen, maar dan besef je dat dit pas het begin van een grote veranderingsronde gaat zijn. Waar vroeger het draaide om applicaties zie je nu een verschuiving naar data en communicatie. Een verschuiving waarbij simpel een belangrijk kernwoord is.

Een verschuiving die ik alleen maar kan omarmen, maar ook voor voldoende beroering gaat zorgen in de FOSS-wereld gok ik. Het wordt nu langzaam duidelijk wat de rol van Empathy en Telepathy is en waarom Pidgin langzaam buiten de boot zal vallen. Dit geeft ook te denken wat de rol gaat worden van oa LibreOffice, maar ook Firefox en Thunderbird. Ook zie je nu langzaam de rol van Tracker duidelijk worden en wie de demos van Zeitgeist ziet zal zien dat monitoren van gebruikers ook zijn voordelen heeft.

Ik kan niet anders zeggen dat ik uit kijk naar GNOME 3.0 in Debian Testing en zeer zeker naar toekomstige releases. Voorlopig moeten verschillende dependency problemen en cruciale regelmatige crashes in verschillende onderdelen worden opgelost. De vraag die overblijft is alleen hoe GNOME 3 op een Intel Atom gaat presteren bijvoorbeeld, maar dat zal de toekomst ons moeten leren. De komende tijd is er dus weer voldoende om naar uit te kijken en bloggen gok ik.

En nogmaals als waarschuwing, gebruik GNOME 3 alleen als deze netjes in Debian Testing is geland. Een weg terug is er bijna niet en het is gewoon nog niet in een vorm voor dagelijks gebruik.

Jarenlang heeft Canonical getracht om Ubuntu op een CD te persen en out of te box alles aan de praat te hebben voor de gebruiker. Dit lukte al jaren redelijk goed door oa opties te beperken, maar nu is de installatiemethode nog verder te zijn versimpelt. De vraag blijft alleen waarom Ubuntu niet standaard voor /home een apart volume aanmaakt en machines standaard niet laat synchroniseren via NTP.

Verder zie lijkt Canonical met Ubuntu goed te hebben gekeken naar Google en Apple, want Ubuntu lijkt langzaam het appliancemodel te volgen waarbij data wordt opgeslagen bij bv Ubuntu One. Muziek is daar een voorbeeld van, maar ook contactgegevens uit oa Evolution. Dit is wel een punt wat mij doet twijfelen of dat wel een goed idee is. Zeker met de speeches over de freedom-box nog in het achterhoofd.

Het andere punt is dat Ubuntu prettige verschijning moet worden. Het nieuwe Ubuntu font is tegenwoordig standaard actief en hoewel er toch iets mis mee lijkt te zijn geeft het wel een prettig beeld om naar te kijken. Maar dit geldt ook voor het standaard thema welke bij de vorige release de standaard is geworden. Veel punten zijn aangepakt waardoor het geen donkere brei meer lijkt te zijn en meer contrast heeft. Helaas is er nog veel te verbeteren op zowel het gebied van de interface als de interactie met gebruiker, maar hier in een latere posting meer over.

De technische verbeteringen bij deze release zijn een update naar GNOME 2.32 en Linux 2.6.35. Ook wordt bij deze release een applicatie ingeruild voor een andere applicatie en dat is deze keer F-Spot die wordt vervangen door Shotwell. Het is te hopen dat bij de volgende release van Ubuntu Tomboy wordt ingeruild voor Gnote zodat er ruimte vrij komt op de installatie CD doordat dan de noodzaak voor Mono op de installatie CD ontbreekt. Hopelijk worden de plannen voor 11.04 in de komende maanden definitief en kunnen we zien wat de toekomst gaat brengen.

Toch ben ik wel te spreken over deze Ubuntu release en doet me mogelijk Debian Testing toch inruilen voor Ubuntu op de desktop. Het is een redelijke balans tussen recente software, weinig wijzigingen, maar ook goed bruikbaar voor iedereen op vele hardware combinaties. Dit is misschien ook het sterke punt van Ubuntu, elke zes maanden een release met duidelijke plannen vooraf waar de gemeenschap aan kan meewerken. We zullen zien hoe de release volgende week zondag verloopt.

De vraag alleen is wat heb je aan RFC 5006? Het ligt eigenlijk in de provisioning van de nameservers die kunnen worden gebruikt als resolver. Met de komst van IPv6 is een DHCP-server eigenlijk niet meer nodig en blijft de vraag over hoe je sommige configuratie-items gaat zetten. En hoewel RFC 5006 een smerige hack lijkt is het eigenlijk wel netjes, want er zijn voorzieningen om bepaalde uitgiften te laten ondertekenen in IPv6. Hiermee gebruikt de client alleen gegevens met het juiste signature en is het eigenlijk veiliger dan vele DHCP-oplossingen die nu binnen bedrijven staan, maar een daadwerkelijke bruikbare oplossing laat nog op zich wachten.

Het aan de praat krijgen op bv Debian of Ubuntu is vrij simpel met de volgende opdracht.

$ sudo apt-get install rdnssd resolvconf

Als je nu reboot en kijkt in /etc/resolv.conf krijg je bv het volgende te zien:

$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver fd00::21f:3fff:fe30:4ff0
nameserver 192.168.178.1
search fritz.box

Wat nu nog overblijft is NTP wat met behulp van NTP-broadcasting gedaan zou kunnen worden, maar hier kleven wel nadelen aan. Want hoe kan je de broadcaster vertrouwen dat hij de juiste tijd geeft? Hoor ik hier een oplossing in DNSSEC?

Een brand, een zware verstoring en een update van OpenOffice.org heeft ervoor gezorgd dat model van security.debian.org anders moest. Het moest van een enkele server naar een schaalbare oplossing gaan zonder daar de gebruikers mee op te zadelen. Dit is gelukt aangezien security.debian.org nu mbv GeoDNS en HTTP-polling voor iedereen bereikbaar is gemaakt door een bereikbare mirrorserver in de buurt van het gebruiker aan te bieden.

Voor de algemene repository is de urgentie wat minder groot, omdat de gebruiker zelf kan kiezen in welk land de mirrorservers moeten worden benaderd. De vraag blijft of deze manier blijft schalen, want er zal altijd wel ergens een server onbereikbaar zijn door werkzaamheden. De Nederlandse mirror is daar geen uitzondering van, maar voor gratis hosting moet je iets over hebben. En waarom zou een andere server dit werk niet “transparant” kunnen overnemen?

Een klein project loopt nu om te testen of te kijken wat de meest ideale manier is om dit ook voor de normale mirrors van de repository te doen. Gelijk komt hier het probleem naar voren dat niet alle mirrors alle architecturen aanbieden, maar iedereen met een i386 of amd64 installatie zou overal zijn packages moeten kunnen krijgen. De aanpassing aan sources.list zoals hieronder is vrij simpel.

deb http://cdn.debian.net/debian/ testing main
deb-src http://cdn.debian.net/debian/ testing main
deb http://security.debian.org/ testing/updates main
deb-src http://security.debian.org/ testing/updates main

Nu al enige tijd staat cdn.debian.net in mijn configuratie voor APT en ik moet zeggen dat ik voorlopig tevreden ben. Hopelijk wordt dit project verder uitgewerkt en opgenomen in zeg Debian 7.0, maar dan moet 6.0 wel eerst uitkomen natuurlijk.

Een van de grootste probleempunten met SpamAssassin was altijd de ruleset en de strijd met de spammers om die rules net te omzeilen. Bayesian-filtering lost een deel van dit probleem op, maar het andere probleem is de ruleset zelf. Voorheen werden rules met SpamAssassin meegeleverd en werden ze pas bijgewerkt als je een nieuwe versie van SpamAssassin installeerde. Het mag duidelijk zijn dat dit een onbegonnen strijd is, maar ook een gevaarlijke strijd. Zeker voor installaties die afhankelijk waren van DNS blacklists cq whitelists en waarbij de beheerder van de lijst besloot om zijn lijst op te heffen bijvoorbeeld.

De SARE-regels zijn een hele tijd populair geweest en zijn dat helaas nog steeds. Dit terwijl ze stelselmatig worden opgenomen in de ruleset van SpamAssassin zelf. Gelukkig heeft oa SARE er wel voor gezorgd dat er een update methode kwam die met de 3.3 release verplicht is geworden. Hiermee volgt SpamAssassin eigenlijk ClamAV in de voetsporen en is het verspreiden van een vaste ruleset overbodig geworden.

De eerste stap is eigenlijk heel simpel met het draaien van het commando sa-update als de gebruiker root op Debian. Als we nu in /var/lib/spamassassin/ kijken dan zien we het volgende:

$ ls -l /var/lib/spamassassin/ /var/lib/spamassassin/*/
/var/lib/spamassassin/:
total 8
drwxr-xr-x 3 root root 4096 2010-01-02 14:46 3.002005

/var/lib/spamassassin/3.002005/:
total 8
drwxr-xr-x 2 root root 4096 2010-01-02 14:46 updates_spamassassin_org
-rw-r--r-- 1 root root 2431 2010-01-02 14:46 updates_spamassassin_org.cf

We zien netjes de betreffende versie van SpamAssassin en in die directory de ruleset zoals die nu voor versie 3.2.5 wordt aanbevolen door SpamAssassin. Deze regels worden automatisch meegenomen als SpamAssassin de volgende keer start. Nu kan je zelf een paar regels in de crontab van de gebruiker root zetten, maar in Debian zijn al voorzieningen getroffen. Door het onderstaande aan te passen in het bestand /etc/dedault/spamassassin zal automatisch de sa-update worden gedaan en wanneer nodig SpamAssassin worden geherstart.

CRON=1

Helaas stopt hier het verhaal niet, want op dit moment worden services zoals Amavisd-new, die ook de SpamAssassin ruleset kan gebruiken, niet herstart. Op moment van schrijven staan bugs 315961 en 567205 hier nog over open. Totdat die zijn opgelost kan de volgende extra code geen kwaad aan het einde van /etc/cron.daily/spamassassin

test -f /var/run/amavis/amavisd.pid && /etc/init.d/amavis force-reload

Dit laatste is natuurlijk op eigen risico, maar het lost de bug voor mij al een redelijke tijd op.