Tot die tijd is het kijken wat voor mijn mist in Squeeze, want voorlopig zijn lijkt Squeeze al redelijk te voldoen als backend. Helaas is er nog voldoende te doen aan de frontend. De frontend als in webapplicaties zoals WordPress, Mediawiki en Drupal. Dus de komende maanden maar eens kijken wat er nog mist in dat gebied en patches insturen.

Looking at the logfiles of one Web 2.0 application based on MediaWiki gives enough to think about. The MediaWiki installation is protected by some extensions to prevent spam and this is the reason I didn’t notice some issues. Those extensions don’t stop abusers from trying to post (between 17 and 21 KB per post) their content to the Main_Page. And with about 10000 postings by 3600 machines for every day of the week it gives an indication how big the issue has become.

For now they are unable to post, but the network appears to be big and growing. And some day they will find a way to work around the current antispam extensions. So the time has come to start collecting data about those abuse attempts and match them with spam on weblogs and spammy e-mails. Hopefully there is a relation, but I fear the moment that Web 2.0 is realy to open for the world to handle.

For now 2.8 is on hold for me to see how I can modify it so it becomes usable again in a shared hosting environment. And the following line in the release announcement worries me.

The core and plugin updaters in previous versions of WordPress have been such a success we decided to bring the same to themes. You can now browse the entire theme directory and install a theme with one click from the comfort of your WordPress dashboard.

It is going to be interesting when I load it on a test container next week. Maybe I will update MediaWiki 1.14 to 1.15 first to get in a good mood.

But who implements this standard? MySQL, Oracle, Sybase, PostgreSQL, MS-SQL? The question may be more like “who implements what?” and “how?”. Bug 18078 may give a hint in how well vendors are implementing SQL and may give an inside on how big the vendor lock-in really is. But is also gives an inside on how developers are wasting time writing and discussing abstraction layers to let there application like MediaWiki for example run on multiple databases.

Is this the new barrier where the FOSS-community needs to spend time to give proprietary vendors a run for there money? Just like Mozilla pushed Microsoft to accept open standard for the web, or like OASIS did with OpenDocument, or like the XMPP Standards Foundation is doing with instant messaging? Yes, AOL is running to get there AIM/ICQ-network migrated to XMPP so they can compete and communicate with Google Talk. Hopefully time will teach us how we can free us from proprietary only solutions and level the field again. Until then it’s something to work on and check for when using new applications.

Helaas is PostgreSQL wat kieskeuriger en klaagt over het feit dat er een “SELECT … LIMIT 0,5″ wordt aangeboden. Gelukkig is er ook een optie om met een SQL-statement beide database te bevragen. De vraag is dan ook waarom niet direct voor “SELECT … LIMIT 5 OFFSET 0″ is gekozen aangezien zowel MySQL 5 als PostgreSQL 8 dit ondersteunen.

De developer heeft een bugreport en patch gekregen om dit structureel op te lossen. Helaas gaat deze functionaliteit niet zonder flinke aanpassingen werken op Oracle aangezien ondersteuning voor oa LIMIT en OFFSET daarin niet aanwezig is. De komende periode maar eens kijken naar welke extensies ook problemen hebben met PostgreSQL als database achter MediaWiki, want ik ga niet meer terug naar MySQL.

Het werd tijd om in een testomgeving MediaWiki 1.14 op te bouwen met PostgreSQL als achterliggende database-engine. Het overstappen van database-prefixes naar schema’s maakt de DBA in mij ook weer blij nu het wat overzichtelijker is geworden. Zeker omdat PostgreSQL dumps op schema-niveau ondersteunt en met veel verschillende wiki’s is dat wel een fijne feature, want bij MySQL is dit helaas niet mogelijk.

Helaas zijn er ook nadelen met de overstap naar PostgreSQL zoals dat voor MediaWiki 1.15 een nieuwe versie van PostgreSQL vereist is. Ik gebruik nu 8.1 en dan zal 8.3 nodig zijn volgens de specificaties. Een tweede punt en dat hangt samen met deze aanpassing is het laden van tsearch2-ondersteuning, maar deze ondersteuning zou bij PostgreSQL 8.3 standaard is de database moeten zitten. Voorlopig voldoet Mediawiki 1.14 en kan de upgrade nog even wachten tot het moment dat de databaseserver overgaat van Debian 4.0 naar Debian 5.0 deze zomer.

Nu deze migratie van MySQL naar PostgreSQL gedaan is gaat wordt het tijd om de volgende migratie te gaan voorbereiden. Dit zullen hoogstwaarschijnlijk Dovecot en Postfix gaan worden, maar eerst even kijken of er nog issues uit de migratie van MediaWiki komen.

Gedrukte boeken

Bij vele Mediawiki-projecten zoals Wikibooks en Wikipedia is het voor gebruikers die zijn ingelogd al een tijdje mogelijk om PDF-documenten te maken van je favoriete artikelen. Hierbij is een van de mogelijkheden om een daadwerkelijk boek te maken en te laten afdrukken in boekvorm. PediaPress, zoals het bedrijf heet, is hiermee dus de schakel tussen de oude en nieuwe wereld.

Projecten zoals vrije leermiddelen van Stichting Vrijschrift hebben ineens de mogelijkheid om scholen toegang te geven tot vrije leermiddelen in boekvorm. Hiermee zijn werken in het publieke domein ook ineens weer beschikbaar in PDF- en papiervorm tegen een betaalbare prijs. Want 15 euro voor een boek van circa 300 pagina’s is zeer redelijk te noemen en het roept de vraag op wanneer er vrije content op een compact disc kan worden verkregen.

Hier vallen vele klassiekers zoals Das Kapital en Max Havelaar onder, maar gelukkig zijn er ook boeken direct onder vrije licenties uitgegeven zoals Free as in Freedom. Iedereen heeft dus direct toegang tot het verleden zonder soms nog belachelijke prijzen te betalen voor boeken waar alleen een uitgever aan verdient. En dit is als hij het wenst uit te geven, maar zoals bij sommige leerboeken al is gebleken gebeurt dat niet meer helaas.

Wij als het volk hebben al misschien meer te danken aan oa het project Gutenberg welke al sinds 1971 werken aan het verzamelen is welke vervallen zijn in het public domain. En het is misschien niet hetzelfde als een echt boek of een bezoek aan de bibliotheek, maar je kan nu tijdens je treinreis wel op bijvoorbeeld je N810 verder lezen in oude klassiekers. Misschien dat het toch tijd wordt voor een klein netbookje voor in de leesstoel.

Deze revolutie heeft ook oa Web 2.0 voortgebracht waarbij gebruikers actieve kunnen deelnemen aan websites. Een van de bekenste websites is mogelijk wel Wikipedia welke de wereld in voornamelijk twee kampen verdeelt over de betrouwbaarheid van de content van Wikipedia. Maar dit is niet de enigste website uit de stal van de Wikimedia Foundation, want een ander is Wikibooks. En de impact van Wikibooks kan mogelijk nog wel groter zijn op de wereld dan die van Wikipedia zelf.

Ging Wikipedia alleen nog maar over losse artikelen en hetzelfde geldt voor Wikispecies waarbij het leven op deze wereld in kaart wordt gebracht. Bij Wikibooks wordt een stap verder gegaan en tracht men hele boeken te schrijven over de meest uiteenlopende onderwerpen. En hoewel er nog voldoende werk te doen is en op sommige punten het iniatief knullig lijkt zijn de plannen er niet minder om. Zeker niet omdat men voor sommige vaken daadwerkelijk wenst te voldoen aan de richtlijnen voor leerboeken.

Het zal dan ook voornamelijk een kwestie van tijd zijn voordat Wikibooks het niveau van Wikipedia gaat evenaren. De impact op hoe ons leersysteem zal functioneren zal dan ook niet gering zijn. Zeker niet als je beseft dat de kosten voor leerboeken enorm hoog is en vrij snel naar het oud papier worden verwezen. Is het nodig om elke twee a drie jaar een nieuw wiskundeboek uit te geven zodat de uitgever opnieuw geld kan innen? Of is het misschien verstandig om in een tijd waarin we bewust worden van ons papierverbruik en toenemende kosten voor onderwijs een beslissing nemen waarin we radicaal de koers omgooien.

Maar het was al even mogelijk om PostgreSQL als database voor MediaWiki te gebruiken, maar er waren nog voldoende onvolkomenheden. Gelukkig komt daar met versie 1.10.1 verandering is en worden zoekfuncties betrouwbaar naast de al goede performance van MediaWiki op PostgreSQL die zeker te vergelijken is met de MySQL implementatie.

Hopelijk maken meer projecten zich sterk om PostgreSQL als database backend te gaan gebruiken, want concurrentie cq competitie is goed in de open source wereld om een gezonde omgeving voor iedereen te maken en te houden.