Category Archives: Open Source Software

Houdbaarheid van digitale gegevens

In Noorwegen heb ik rotstekeningen gezien waarvan vermoed wordt dat deze ongeveer 9000 jaar oud zijn. Een van de tekeningen laat een rendier of hert zien dat zijn kop omdraait en achter zich kijkt. Niets bijzonders zou je denken. Maar iemand heeft dat beeld 9000 jaar geleden gezien, op de rots getekend en nu weten wij het. Dat is toch onvoorstelbaar. Hoe zit dat eigenlijk met onze moderne digitale gegevens, hoe lang kunnen wij die bewaren? Dit zette me aan het denken en als zo vaak leidt dat tot een stukje tekst.

Uiteindelijk vergaat alles

Om te beginnen, natuurkundig bekeken zal alles tenslotte vergaan. Zo hiermee is het meest voor de handliggende eerste gedachte van tafel.

Hoe lang kunnen we als mensheid eigenlijk analoge gegevens bewaren? Welke voorbeelden zijn er van overleveringen (analoog evenwel) en hoe oud zijn die eigenlijk? Kort onderzoek op internet levert het volgende overzicht op:

  • Noorse rotstekeningen geschat 9000 jaar oud
  • Kahun Gynaecological Papyrus geschat op 4000 jaar oud
  • Gutenberg bijbel wordt geschat op 2000 jaar oud
  • Gedichtenbundel van Den Schoolmeester in de boekenkast, geschat net iets minder dan 100 jaar oud
  • Oudste foto in huis, mijn vader als kleine jongen, iets ouder dan 75 jaar

hertje

Mijn eerste observatie is dat ik vergeleken met de andere voorbeelden geen erg oude zaken in huis heb.  Mijn tweede observatie is dat mits zorgvuldig bewaard papier aardig kan concurreren met rotstekeningen. We zouden dit als baseline kunnen beschouwen en eens kijken welke digitale media ik nog heb.

Digitaal archief

De eerste digitale media die ik zelf in huis haalde waren CD’s. Voor zover ik weet is de inhoud daarvan nog steeds goed leesbaar. In overzicht:

  • Oudste CD (Kate Busch, Hounds of love) 30 jaar oud (het jaartal op het boekje)
  • Floppy disc 19 jaar oud (er stond een datum op het label, de leesbaarheid kan niet geverifieerd worden, ik heb geen diskdrive meer)
  • Oudste digitale foto 12 oud (ik wist nog waar en wanneer dat was, foto geverifieerd goed leesbaar)

Vergeleken met de rotstekeningen en de eerste boeken is dit nog geen indrukwekkend resultaat. Hoelang gaan digitale media eigenlijk mee? Kort onderzoek op internet levert het volgende overzicht op.

tabel levensduur media

Hoewel ik dit een wel erg voorzichtige inschatting vind, is het geen erg bemoedigend resultaat.

Digitaal versus analoog

Er is blijkbaar een belangrijk verschil tussen het opslaan van gegevens in analoge vorm en in digitale vorm. In het geval van analoge gegevens kan je stellen dat de levensduur van de gegevens gelijk is aan die van het materiaal (de media) waarop ze zijn opgeslagen. Voor digitale gegevens gaat dit niet op. Een tape of floppy kan zijn gegevens verloren zijn zonder dat je dat kan zien. Daarnaast moet het het medium nog kunnen lezen (heb je dan nog een werkende floppy drive of CD speler en interface?).

Er wordt wel gesteld dat media na twee generaties systemen niet meer leesbaar zijn.

Daarnaast moet het format van de bestanden ook nog leesbaar zijn. Deze zaken worden wel aangeduid met fysical media obsolescences. Naast deze digital obselescence speelt er nog een andere complicerende factor, namelijk datagroei. De groei van data is niet lineair, maar eerder exponentieel.

Welke factoren beïnvloeden digitale opslag media? Te denken valt aan magnetische invloeden, temperatuur (zowel hitte als kou), brand, radiostraling, vocht, uitdroging, chemicaliën en fysieke invloeden (aardbevingen, instortingen van gebouwen e.d.)

Aanvalsplan

Bedrijven en organisaties zien zich natuurlijk eveneens geconfronteerd met deze problematiek, daar zijn we bij ons in huis met onze muziek, foto’s en home video’s geen uitzondering op. Welke tactiek(en) passen deze bedrijven toe?

Het fysiek handelen van mensen doet de media sterk doet achteruitgaan en heeft daarom grote risico’s. Om dit tegen te gaan worden bijvoorbeeld robot’s gebruikt om tapes te hanteren.

Het labelen van CD's en DVD's verminderd de houdbaarheid van sterk.

Ook wordt data wel herschreven (ververst). Hiermee wordt datarot (ook wel bitrot genoemd) tegengegaan. Ook wordt ervoor gekozen data naar nieuwe media te migreren.

 

Datarot, het vervagen onleesbaar worden van digitale gegevens op een drager of in memory.

In alle gevallen wordt geaccepteerd dat een deel van de gegevens verloren gaat. Dat is dus niet anders dan ik de fysieke (analoge) wereld.

Misschien een vreemd idee, maar digitale gegevens op papier printen kan een oplossing zijn voor de eeuwigheid. We weten immers dat dit duizenden jaren kan overleven. Bovendien is er daarmee ook geen afhankelijkheid van gebruikte interfaces. Het is echter minder handig als het gaat om de opslag van veel gegevens. Daarmee vallen foto’s, muziek en film praktisch af.

De keuze voor rotstekeningen was dus nog zo slecht niet. Alle respect voor de kunstenaar van 9000 jaar geleden.

 

 

Open Source Software, zuiver eigenbelang

Gratis software, developers die software weggeven en die software voor mij onderhouden? Een economie van het delen, altruïsme? Ik geloof er niets van. Alles kost geld, ook software. Developers moeten toch ook kunnen leven?  Overal moet voor betaald worden, alleen de zon gaat voor niets op.

Al jaren staat de software industrie gelijk aan het snelle verdienen, het grote geld. Waarom zou iemand software weggeven en er niets voor terug vragen? Waarom zou ik dergelijke software willen gebruiken? Waarom werken grote bedrijven als HP, IBM, Intel en Red Hat daaraan mee? Vast niet om er slechter van te worden. Deze bedrijven willen immers geld verdienen. Er is vast een catch.

De catch

foksuk_rrs_scriptKlopt, er is een catch. De motivatie om aan open source software te werken is zuiver eigenbelang. Bedrijven doen dat om geld te verdienen. Developers hebben de software zelf nodig of willen bekendheid te verkrijgen. Aha.. zult u denken, dus dat is de catch. Ja dat klopt, dat is de catch. De motivatie voor developers en bedrijven is om er beter van de worden. Iedereen met bedenkingen over open source software heeft toch gelijk. Maar er is nog een catch, eigen belang als motivatie is eigenlijk best prima.

De motivatie

Natuurlijk is het allemaal niet zo slecht als het klinkt. Bedrijven en developers werken aan open source software om er beter van te worden, maar ze zijn niet egoistisch, anderen mogen er ook van profiteren. En ja en ook dat gebeurt met de gedachte dat ze er later zelf beter van worden. Maar is dat eigenlijk wel erg?  Waarom zou je er zelf niet beter van mogen worden als anderen er ook wat aan hebben, dat is toch prima?

Zeg nu zelf, als je wil dat mensen iets doen en dat blijven doen, wat is de beste garantie die je kan krijgen? Dat ze ervoor betaald worden, of dat het (ook) in hun eigenbelang is? Het is eigenlijk het verschil tussen intern gemotiveerd zijn, of extern gemotiveerd worden. Interne motivatie is natuurlijk veel beter. Immers, geen betaling, geen software. Het verklaart eveneens waarom open source software developers zo gebrand zijn kwalitatief goede en veilige software te maken. Ze hebben zich persoonlijk verbonden aan de software. Deze persoonlijke verbondenheid is veel lastiger als je daarvoor betaald wordt.

Scratch your own itch

In het begin van het computer tijdperk werkte het immers ook al zo.  Als een computer iets moest doen, dan schreef je daar zelf de software voor, je kon het immers (nog) niet kopen. Maar als iemand anders software bezat die je nodig had, dan was het sneller om dat te mogen gebruiken, dan om het zelf te schrijven. Het delen van software lag daarmee erg voor de hand. Toch was de motivatie om te delen eigen belang, je werd er zelf ook indirect beter van.

Eigenbelang is prima

het-kan-wel-loesjeZo bekeken is de motivatie om mee te werken aan open source software inderdaad eigenbelang. Niet egoistisch zodat we niet delen, maar de inspanning die we leveren, leveren we in eerste instantie voor onszelf. Dit is precies de reden waarom open source software een goede keuze is voor bedrijven en organisaties. Het principe erachter, de motivatie om software te schrijven en te onderhouden komt voort uit eigenbelang. Juist dit feit maakt dat het proces stabiel is. Deze stabiliteit is bij uitstek in het belang voor bedrijven. Lage kosten (ja het gebruik van software is nooit kosteloos) en een stabiel proces om de software te ontwikkelen en te onderhouden is juist in hun belang – en uiteindelijk in ieders belang.

Duurzaam

Heb je zelf behoefte om aan open source software mee te werken, doe het dan vooral voor jezelf, maar deel het resultaat met anderen. Dit gaat ook voor bedrijven op. Bijdragen aan software projecten, of het financieren van ontwikkeling, doe het vooral vanuit eigenbelang en deel het daarna met de wereld. Dit is de beste manier om het gebruik en het ontwikkelen van open source software duurzaam te maken en nuttig te laten zijn voor iedereen.

 

Docker, Dev-Ops bijna opgelost..

Nu grote- en middel grote organisaties de inzet van Linux en Open Source software niet vreemd meer vinden, maken zij zich op voor de volgende stap. De een noemt het “State config”, de ander noemt het “Datacenter automation”. Ongeacht de naam die het krijgt, verandering zit in de lucht.

Virtualisatie

De eerste grote slag vond plaats toen virtualisatie gemeengoed werd. Het maakte mogelijk dat hardware beter benut kon worden en onderhoud op de hardware uitgevoerd kon worden zonder down time van applicaties. Feitelijk werden server-installaties los gekoppeld van de hardware. In  sommige organisaties ontstond er zelfs een nieuwe groep van beheerders, zij die zich exclusief bezig hielden met deze virtualisatie. Nadeel van virtualisatie was wel dat nieuwe (virtuele) servers te makkelijk uitgerold konden worden. Dit leide veelal tot ongecontroleerde groei van servers. Immers, het aanvraag proces van nieuwe servers en de aanschaf van hardware waren ook ontkoppeld.

Puppet

Virtualisatie van servers vraagt om software en tooling waarmee dit beheerd kan worden. De servers zijn niet meer zichtbaar en het worden er wel heel veel. Het walhalla is hierbij natuurlijk dat servers volledig middels templates beschreven zijn en op commando geautomatiseerd gedeployed kunnen worden. Puppet is bij uitstek software die dit mogelijk maakt. Veel organisaties op dit moment zijn nu wakker voor deze ontwikkeling en het verklaart de populariteit van Puppet. Overigens zijn er veel meer initiatieven (software producten) die dit kunnen, te denken valt aan Ansible, Chef, MAAS, JuJu, Landscape e.t.c. Interessant is dat deze ontwikkelingen veelal vanuit de Open Source hoek lijken te komen. Duidelijk wordt dat traditioneel systeembeheer een veel grotere programmeer-component krijgt.

Cloud Computing

Als virtualisatie gecombineerd wordt met datacenter automation, dan komen we in het gebied van Cloud Computing. Hierbij gaat de ontkoppeling van de hardware nog een stap verder. De kosten worden volledig operationeel (opex – Operational Expenditures) en de capaciteit volledig elastisch. Bij de cloud aanbieders zijn het de grote IT bedrijven die de toon zetten. Met name Amazon met haar EC2 cloud mag genoemd worden. De EC2 cloud is voor velen nog steeds het lichtende voorbeeld van hoe een cloud zou moeten functioneren. Bij de aanbieders van cloud software wordt het peloton aangevoerd door Open Stack een project waaraan alle belangrijke software vendors inmiddels aan meewerken. Het is mogelijk een “Kip ei” vraagstuk of Cloud Computing of datacenter automation eerder was. Het zijn in ieder geval technieken die hand in hand gaan. Red Hat heeft dit zien aankomen en heeft Puppet in haar Red Hat Satelite product geïntegreerd en maakt met Cloud Forms mogelijk om orkestratie over verschillende Cloud- en virtualisatie platforms uit te voeren.

Docker

En op het moment dat de IT markt denkt de ontwikkelingen begrepen te hebben, komt er een game changer langs. Docker is een combinatie van container virtualisatie en applicatie virtualisatie. Dit verandert vreemd genoeg veel. De lichtere vorm van virtualisatie maakt dat er minder overhead is en er dus efficiënter gebruik van de hardware kan worden gemaakt. Het is niet strijdig met Cloud Computing, maar, bouwt daar juist op voort. De echte grote verandering is daarom niet technisch van aard, maar organisatorisch. Doordat ontwikkelaars de Docker pakketten maken wordt het traditionele systeembeheer gepasseerd.  Het traditionele IT afdelingen hebben de “Boot gemist”, de business heeft ze nauwelijks meer nodig. Na jarenlang barrières op te hebben geworpen, heeft de business zich nu onafhankelijk gemaakt van de IT afdeling. De aansluiting met de business is hierdoor eenvoudiger – een vraagstuk dat de IT al jaren teistert. Het is wel de vraag wat de IT beheer afdeling nu gaat doen. Resteert het hen de hardware te beheren en te onderhouden?

Nieuwe kansen

Er zijn ook wel weer kansen. De ontwikkelaars zijn nu “In charge” en daarmee ook van security – en daar zijn ze traditioneel niet erg goed in. Het is zaak om het traditioneel IT beheer te herzien en  aan te sluiten bij development afdelingen en te participeren in security vraagstukken – mits je niet alleen kapotte harddisks wil wisselen.