Het is prima mogelijk om zelf software te compilen zonder een package manager in de war te maken. Geweldig nieuws voor mensen die Debian stable willen draaien, maar wel een Vim of Tmux uit deze eeuw willen gebruiken. Hulde!

Dat was een nieuwtje van Opera, vandaag:

On the same day as announcing that Opera has 300 million users, we’re also announcing that for all new products Opera will use WebKit as its rendering engine and V8 as its JavaScript engine.

Wow.

In de TL;DR meldt men nog leutig:

This will require no changes to your web development practices:

Nee, Opera was als target nooit zo enorm interessant; enerzijds omdat het de standaarden altijd wel “redelijk OK” tot “enorm goed” gevolgd heeft (dus als je dat als developer ook doet is het meestal wel in orde, en natuurlijk volg je als developer de standaarden, toch?), anderzijds omdat er op een gemiddelde dag ongeveer anderhalve bezoeker met Opera langs kwam, op sites met redelijk wat verkeer. Ha ha.

Maar toch, een hele engine eraf. Nu blijven er dus WebKit (met Nitro in geval van Safari, of V8 in zo’n beetje alle andere gevallen), Gecko (met Ion- of andere Monkey), en dat apparaat van Microsoft (Trident? Chakra?) over. Nogmaals, er valt niet een enorm aandeel in gebruikers weg, maar het voelt toch alsof er een stukje geschiedenis ten einde komt. Het blijft een dappere (en waarschijnlijk nodige) keuze van Opera; ze zijn te klein om echt impact te hebben, maar bevlogen genoeg om een goeie engine neer te willen zetten; die energie gaan ze nu dus in Chromium steken, en in het blijven maken van een onderscheidende browser om die engine heen.

Wow.

Ik moest weer eens een development server opzetten, en die mag ik dan graag met een monitor eraan logs laten tailen. Dat gaat een beetje poep als de console het op 80×25 karakters houdt, en een vorige keer had ik het ook voor elkaar gekregen om tekst in de native resolutie van de monitor te laten verschijnen.

Omdat ik er nu even naar moest zoeken en ik dat een volgende keer — wegens lui — niet meer wil hoeven doen een klein geheugensteuntje.

Grappig bericht van Zeldman op A List Apart (ALA): in On Alt Text beschrijft hij hoe men tijdens de omkat van ALA bewust gekozen heeft voor een lege alt-tekst voor bepaalde afbeeldingen. Ik snap waarom men ervoor gekozen heeft en het is ook geldige HTML5, maar ik vind het ergens wel een beetje… nou ja, krom. Je moet en zal een alt-attribuut in zo’n element proppen, maar als je er niets in te melden hebt dan mag het wel weer leeg zijn. Maak het dan, denk ik in al mijn simpelheid, een optioneel attribuut.

Ik zal ongetwijfeld een zeur zijn.

Leuk detail: een spatie als inhoud voor het attribuut voorkomt blijkbaar dat sommige screen readers uit nood dan maar de volledige URL van het plaatje zélf gaan oplezen. Lijkt me dat je dat inderdaad ook niet moet willen, nee.

…al is er in het afgelopen jaar niet bar veel content geweest. In het hele jaar is er, eigenlijk niet bar veel nieuwe tekst bijgekomen. Als ik nu eens heel eerlijk moet zijn, dan is het al een jaar of twee pet.

Qua nieuw toegevoegde woorden, dan.

Ik ben er nog steeds niet helemaal over uit wat ik daarmee wil, of hoe, maar dat komt vast nog wel eens… =]

Keep watching this space.

Ik was een beetje aan het rommelen om DNZM toch eens daadwerkelijk te verhuizen naar mijn thuis-servert — nee, dat is nog steeds niet gebeurd — alleen… Het ding liep iedere keer schijfruimtetechnisch vol. Gisteravond nog wat spul eraf gegooid, 5 of 6 GB vrij, en vanmorgen was het weer vol. Raar. Eigenlijk was die 5 à 6 GB al aan de vrij lage kant; er zit “maar” een 40 GB schijf in, maar voor een simpel servertje zou je daar meer dan genoeg aan moeten hebben.

Na wat rondgepord te hebben met du kwam ik erachter dat de bulk van alle verbruik in /tmp zat. Eén ls later zat ik, hardop facepalmend, te wachten tot het probleem opgelost was. Zoals wel vaker vond ook dit probleem zijn oorsprong tussen de stoel en het toetsenbord…

Xdebug

Een paar maanden geleden ontdekte ik Xdebug, een extensie voor PHP die het debuggen makkelijker maakt. Eén van de mogelijkheden van Xdebug is het genereren van een profiel van een draaiend PHP-script, door een bestand op te slaan met wat informatie over welke functies werden uitgevoerd, en hoe vaak, en hoe lang dat duurde. Vrij handig als je een app aan het ontwikkelen bent en je wilt weten waar eventuele bottlenecks zitten.

Het nadeel ervan is dat het, op een server die de hele dag door allerlei PHP-script staat uit te voeren, de hele dag bestanden genereert, soms nog vrij grote bestanden ook. U ziet vast al waar dit heen gaat?

Ik heb blijkbaar die automatische traces een keer aangezet en er nooit meer bij stilgestaan.

Honderdmiljoenmiljard bestanden weggooien later was er volgens df weer zo’n 6 GB vrij. Mooi, zou je zeggen, ware het niet dat du vertelde dat er op de hele schijf (van 40 GB, dus) maar iets van 4.5 GB in gebruik was. 40 – 4.5 is, volgens mijn beperkte hoofdrekenkunsten, iets meer dan 6. Er was dus nog iets aan de hand.

Over du en df en in gebruik zijnde bestanden

Uit een klein stukje googlen werd duidelijk dat df en du verschillend kunnen denken over de hoeveelheid verbruikte ruimte, als er nog bestanden open staan. Dat bleek het geval; er draait op het systeem een PHP-script als daemon (in tegenstelling tot een vanaf de webserver opgeroepen script bleef het dus full-time doordraaien) en, uiteraard, dat script werd door Xdebug geprofileerd, en dat script had dus een — episch grote — file openstaan.

Script gestopt, en even later waren du en dh het eens over hoe het met de vrije ruimte was gesteld: 30GB vrij.

Lessen geleerd

• Op een (semi-)productiemachine moet je voorzichtig zijn met profiling, en zeker met automatische profiling
• Als je home directory niet de grootste verbruiker is, wordt het tijd om naar /var en /tmp te kijken
• Als je na uitgebreide wis-acties een verschil tussen du en df ziet, wordt het tijd om met lsof | grep 'deleted' te kijken of er nog ergens (grote) bestanden open staan die al verwijderd zijn.

Ik ga de boel verhuizen naar een andere server, dus DNZM zal ergens dit weekend even offline of anderszins minder geweldig bereikbaar zijn.

Niet dat ik nou van die enorme hoeveelheden traffic trek, dus de overlast zal minimaal zijn, maar toch. Ik meld het maar even.

Dat gedoe met Markdown en de stukkende feed? Fixed.

Markdown

Het probleem met Markdown was het gebruik van deprecated functies van PHP, de even simpele als geniale oplossing is WordPress vertellen dat foutmeldingen niet zo nodig naar de gebruiker hoeven te worden gestuurd, dankuwel. In de dichtstbijzijnde wp-config.php deze regel toevoegen:

define('WP_DEBUG', false');

Opslaan, reload, rejoice. Blijkbaar zit die switch er al tijden in, maar is die ergens van “standaard uit” naar “standaard aan” gegaan. Bij mij in ieder geval wel.

Te leren uit deze faal: Verander niet zomaar de standaard-instelling als die in in een verleden geïnstalleerde versies nog niet bestond, en als je dat al doet, controleer dan expliciet of de define waartegen je checkt, ook daadwerkelijk defined is. Zo niet, ga dan uit van false, of in ieder geval wat er in de oude situatie zou gebeuren.

Simpeler gezegd: breek niet de installs van je gebruikers.

Feed

De feed was een typisch geval van “let dan toch ook op, gij onnozele”. Ik heb ooit eens FeedWordPress geïnstalleerd gehad, en in een vlaag van verstandsverbijstering (die ik soms aanzie voor “geniale ingeving”) had ik het allemaal zo geregeld, dat in mijn feed de door FWP binnengelutste dingen een link kregen die direct naar het origineel ging. Of zoiets, ik weet het eigenlijk niet meer, en dat dondert verder ook niet.

Wat wel dondert, is dat ik die plugin er ooit heb uitgegooid, en dat sindsdien mijn feeds stuk waren.

Te leren uit deze faal: Als je in je code een functie aanroept die door een plugin o.i.d. wordt gedefiniëerd, zet dan altijd je code in een if (function_exists(... (documentatie). Als ik dat had gedaan, was er nooit een probleem geweest.

TL;DR

Assumptions are bad, mkay?

Ik was de afgelopen dagen hier en daar al wat tegengekomen over CarrierIQ (CIQ), een stukje software op smartphones waarmee carriers (de T-Mobiles, KPNs en Vodafones enzo) de toestellen kunnen laten bijhouden wat er zoal mee gebeurt. In theorie kan zo’n tool handig zijn om problemen te troubleshooten en als zodanig de hooggeëerde klant beter van dienst te zijn, maar waar de gezamelijke onderbroeken nogal van in de knoop raakten, was het feit dat het ding nogal veel bijhield. Te veel.

Bot gezegd, het is spyware die een carrier op je toestel kan hebben geïnstalleerd, en waarmee veel te veel info kan worden verzameld.

Na het nodige leeswerk hier en daar lijkt het erop dat dat hele CIQ vooral kado is gedaan in the good old US of A. Mijn Samsung is in ieder geval, volgens het hier genoemde tooltje, schoon. Dat scheelt dan alweer.

Verder denk ik dat er meer paniek heerst dan strikt noodzakelijk. Het verschijnsel CIQ is al maanden bekend, maar nu er dan wat aandacht aan gegeven wordt, wordt het ook meteen voor een paar maand goedgemaakt.

Niet dat ik het slecht vind dat er aandacht voor is, verre van. Wat ik in de diverse artikelen op diverse nieuwssites en blogs liever had gezien, naast elkaar klakkeloos napraten, is iets meer feitencheck, en vooral informatie over hoe je zelf controleert of je tot de slachtoffers behoort, en hoe je daar eventueel iets aan kunt doen. Op Tweakblogs gaat dat gelukkig iets genuanceerder, en daar zie ik in een korte scan van de reacties vooral “schoon” langskomen, en niet alleen bij de custom ROMs.

Los daarvan: schokkend is het eigenlijk allemaal niet. Het verzamelen van zoveel mogelijk informatie over (mogelijke) klanten lijkt steeds meer de core business van steeds meer grote bedrijven te worden. Dit is gewoon het zoveelste hoofdstuk in het boek over privacy, en over hoe dat al lang niet meer van toepassing is.

Ik kwam er laatst achter dat zo’n beetje alle content hier weg leek te zijn. Iets met de Markdown-plugin die een foutmelding gaf en dus geen gMarkdownificeerde tekst.

Lastig.

Voor nu heb ik even Markdown uitgeknikkerd, zodat er in ieder geval weer tekst staat. Dat is dan wel meestal wat kale tekst, maar het is even niet anders. Markdown is er juist op gebouwd om ook zonder rendering leesbaar te zijn, dus tja.

Zodra ik de boel weer goed werkend heb merkt u dat vanzelf…