Met de introductie van DeviceKit werden dingen zoals notificatie van defecten aan harddisks ineens mogelijk geworden. Hardware werd toegankelijk voor userland zonder smerige hacks of setuid executables. Voorzieningen om deze notificaties weer te geven werden onderdeel van GNOME bij release 2.28.
Alleen wanneer zie je die notificaties? Achter deze vraag ben ik recentelijk gekomen, want hoewel de RAID weer in orde was besloot een disk om toch een paar extra herallocaties van sectoren. MD besloot om de disk weer uit de RAID-set te gooien en DeviceKit zag dat de threshold van de leverancier voor deze disk werd overschreden. Zolang de disk zichtbaar is blijft de waarschuwing zichtbaar voor de gebruiker tenzij hij of zij deze notificatie uitzet.
Gebruikers krijgen tegenwoordig tijdig een waarschuwing als er structurele fouten optreden en geeft ze een kans om preventief aan de slag te gaan. Zeker met veel disken die je gewoon kan laten omruilen als ze binnen de garantieperiode zitten. Sommige mensen kiezen daar blijkbaar niet voor, maar daar heb ik aan het einde van de dag ook geen medelijden meer mee.
Hoewel de data op de disk was geencrypt met LUKS loopt er nu toch een wipe sessie om de disk een aantal keer te overschrijven met random data. Hierna kan deze terug naar de leverancier en is het wachten op een nieuwe. Dit heeft me ook aan het denken gezet of er plugins voor Nagios zijn of dat ze nog geschreven moeten worden.
Met de GNOME 2.28 release besloten de developers ook om een paar bugs op te lossen door iconen weg te halen van menu’s en knoppen. Helaas ben ik van de categorie “human” en ben ik redelijk visueel ingesteld. Gelukkig is dit door twee commondo’s op de commandline terug te draaien.
$ gconftool-2 --type bool --set /desktop/gnome/interface/buttons_have_icons true
$ gconftool-2 --type bool --set /desktop/gnome/interface/menus_have_icons true
Mijn kudos voor Andrew Cowie voor het posten, want ik had nog geen tijd gehad om dit uit te zoeken.
Sinds Metacity 2.14 kan deze window manager ook als compositing window manager acteren. Hoewel veel van de functionaliteit beperkt is ten opzichte van Compiz Fusion zijn de basisfuncties zoals transparantie en schadows aanwezig samen. Maar of dit ook daadwerkelijk een beperking is de vraag, want de developers lijken zich te beperken tot bruikbare functionaliteit voor de gebruiker.
Een van de manieren om compositing in Metacity aan te zitten is om op de commandline het volgende commando te geven.
# gconftool-2 -s /apps/metacity/general/compositing_manager -t boolean true
Met elke release komen er meer features in de GNOME desktopomgeving, maar tegen welke prijs. En hoewel veel aanpassingen positief zullen uitpakken voor veel gebruikers zijn er helaas ook veel nadelen, want steeds meer onderdelen worden in bijvoorbeeld Python geschreven en zijn voor veel gebruikers niet zichtbaar. Dit geldt ook voor de impact van deze afhankelijkheid.
Om te kijken hoe groot de impact van Python op Rhythmbox is als voorbeeld werd het tijd om Rhythmbox zelf te gaan compileren zonder ondersteuning voor Python. En het resultaat baarde eigenlijk zorgen aangezien we circa 13MB bespaarde op resident memory na enige tijd operationeel te zijn. Het is dan ook zeker een iets om verder naar te doen aangezien ook de opstarttijd aanzienlijk verbeterde.
Dit roept wel vragen op hoe bepaalde mogelijkheden kunnen uitpakken en of het wel de moeite waard is. Ik trap hiermee hoogstwaarschijnlijk op veel tenen, maar hoogstwaarschijnlijk niet op die van Jane Doe als eindgebruiker. Zeker niet als zij de rekening voor de computer moet betalen voor zowel de aanschaf en gebruik. En gezien welke kant de wereld opgaat is dit wel iets om over na te gaan denken.
Dit doet me denken aan de tijd dat GNOME nog genoeg had aan 192MB, maar tegenwoordig is 1024MB wel het minimum aan het worden voor een standaard desktop om goed te laten werken. Maar hoe gaan we technieken zoals Python, Mono en Java uit de basis van een desktopomgeving krijgen en houden. Het is in iedergeval wel iets om over na te denken en te kijken welke features daadwerkelijk belangrijk zijn en of ze kunnen worden gedaan in een efficiente C-implementatie.
Werd vandaag door iemand gewezen op Google voice- en videochat dat het niet werkte op zijn Mac Mini van amper 2,5 jaar. De stoute schoenen aan en kijken of er wel ondersteuning was onder Linux en het resultaat mag er zijn. Want bij een eerste poging kreeg kwam er een Windows-executable binnen en bij de tweede poging werd duidelijk dat Linux ook niet op de lijst stond van ondersteunde besturingssystemen.
Ben ik teleurgesteld? Nee om eerlijk te zijn, want dit soort diensten horen te werken via een algemeen geaccepteerde manier met bijbehorende codecs voor zowel video en audio. Een punt waar alle grote partijen, lees oa Microsoft, Nokia en Apple, dwarsliggen en hun eigen formaten willen doordrukken. Iets wat HTML5 ook heeft verminkt voor de toekomst.
Het geeft nogmaals aan hoe belangrijk open en vrij standaarden zijn. Zeker nu Mozilla ondersteuning voor oa Theora gaat inbouwen in Firefox en Opera mogelijk snel zal volgen. En er is veel kritiek op Theora en mogelijk terecht, maar veel mensen nemen genoegen met nog slechtere kwaliteit als je bijvoorbeeld filmpjes op Youtube bekijken. Veel van de bezwaren zullen mogelijk op de langere termijn op te lossen zijn of voorlopig als geaccepteerd kunnen worden beschouwd.
Maar dit alles doet met denken aan een presentatie bij GAUDEC 2008 waar mbv het Telepathy- en GStreamer-framework streaming video werd getoond zonder problemen. Ik gok dat het daadwerkelijk bruikbaar worden van de nieuwe dienst van Google langer op zich laat wachten dan dat het duurt om een goed alternatief te maken. Zeker nu Telepathy en Empathy zijn opgenomen als onderdeel van GNOME en developers aan de slag gaan.
Recente reacties