Cruz' Hoekje

My god.

Digital Entertainment Content Ecosystem (DECE), is supposedly the future for DRM. You'd think that they learnt their lesson over the last few years where DRM was forcefed to consumers until the point that people got 'fed up' and spat it back out again.

But no, more DRM is on the way. DECE is going to be smarter and lets you watch your movies anywhere you want, as it uses a central database where all your movie purchases are stored. So you don't actually buy a physical item like a DVD but you buy the right to watch a certain movie anywhere on 'any' device.

So far, so good; a license based model is very userfriendly and you finally don't have to worry about scratches on discs, lost CD's, etc anymore.

But there's invariably a bad side to all of this. And I'm not even going to start about privacy issues As the content owners want to maximize income and thus minimize piracy, they will demand that encryption is used to protect the content from being copied.

The result

See what they're doing here? Let's call it 'Screwing over Open Source'. Because no way that there'll be an Open Source application that can decode and display such a movie. The nature of OS is that people can see how things work, and that means that the application can be 'tweaked' to make perfect movie rips.

What this means is that, in the future, you buy a license to a movie such as Avatar. From that point on you can watch Avatar wherever you are, in your home on your TV, at a friend on his TV (after you somehow authenticated yourself), in the train on your iPhone 5GS. Just not via any Open Source application such as MediaPortal, VLC, MythTV, etc. With any luck, proprietary players will come out for Linux and Android... but as usual this will lag behind on non-OS products. Silverlight and iTunes are fine examples of how DRM does not go together with Open Source solutions.

Alternative?

The reason companies want DRM is because they're afraid that they'll lose income. To those companies I'd like to say:
Welcome to the real world people

Just accept that consumers can and will pirate music, videos and the rest! Don't waste shitloads of money on frantically trying to restrict what consumers can and can't do with their product.

Whatever DRM solution you can come up with, there's always someone who can find a way around it. And lets assume that it's completely bulletproof, with today's technology someone just sets up a HD-camera, aims it at his HD television set, he records the (7.1?) sound through a set of microphones and voila; a perfectly good watchable rip. It's impossible to win with DRM. You frustrate the people who actually bought the legitimate product (think of the unskippable anti-piracy trailers on every movie DVD out there ) and encourage the use of 'copies'.

IMO, the alternative is this.
Let go of DRM. Completely. Stop trying to prevent access to your product but stimulate it. All video streams/downloads unencrypted, perfectly possible to rip it but someone would've ripped it anyways.

Use the money to lure consumers away from 'illegal' (better: 'unprofitable') sources. You tend to complain that it's impossible to compete with free supply but that's utter nonsense, there are many ways in which consumers can be enticed to buy products that they're now getting for free. I suggest you start by focussing on these areas:

• Fast download speeds
• High quality movie/music
• High quality information (MP3 tags, movie info)
• Trusted source, no worries about virusses or renamed pornos
• One stop shop so the consumer doesn't have to search for long
• Attractive pricing (no physical media = lower price!)

That way consumers win, producers win, and Open Source doesn't get screwed over.

Helemaal afgelopen is het natuurlijk nog niet, maar alvast een update van het huidige resultaat. Om een goed beeld te geven van mijn gezichtsvermogen heb ik de Snellen-chart gepakt, afgedrukt en opgehangen aan de muur. Hieronder staat per dag een indicatie van hoe ik de kaart zag.

Pre-op

Voor de laser-operatie, zonder bril:

Voor de laser-operatie, met bril:

Op (Donderdag)

De operatie verliep zonder problemen, het was wat vreemd en soms een tikje oncomfortabel maar niet pijnlijk of zo. Doordat ik wat youtube-filmpjes over LASEK behandelingen had bekeken wist ik precies wat er ging gebeuren, en dan valt het reuze mee. Ik dacht alleen verbrand vlees te gaan ruiken (BBQ) maar het was meer verbrand haar (Krultang? ). Het is uiteindelijk (zoals verwacht) toch een PRK geworden (zie vorige blogpost).

De avond was vervelend, niet zozeer vanwege pijn maar wel last van de ogen; niet open kunnen houden, constant tranen etc. Veel op de bank gelegen, vroeg naar bed gegaan.

Post-op (Vrijdag)

Zicht is OK-ish, komt vooral door de bandage-lenzen die voor een mooi glad oppervlak zorgen. Ben met het openbaar vervoer naar de kliniek geweest, was best goed te doen alleen 's avonds wel gevoelige ogen gehad. Bij de controle waren geen problemen geconstateerd dus gewoon afwachten tot het beter wordt. Hele middag/avond eigenlijk met de ogen dicht op de bank gelegen, wat muziek geluisterd (o.a. Krezip), audiobook geluisterd (Bourne Deception), en Ricky Gervais' Out of England show geluisterd. Af en toe een uur geslapen op de bank. Weer om 22:30 naar bed gegaan.

Post-op (Zaterdag)

Zicht is een stuk minder. 'Slecht' geslapen omdat ik nu toch wel zo'n beetje alle slaap die ik mistte heb ingehaald. Maar of je nou op de bank met de ogen dicht ligt te wachten, of op bed.. dat maakt ook weinig uit. Dus rond 4 uur wakker geworden en toen niet meer geslapen. Wel weer veel op de bank gelegen, wat Michael Jackson geluisterd. De hele dag nog steeds tranende en lichtgevoelige ogen gehad. Ik kan in ieder geval zeggen dat ik van mijn leven nooit zoveel heb moeten huilen als toen Michael Jackson doodging

Post-op (Zondag)

Zondag ging het een stuk beter! Ik kan mijn ogen zonder veel problemen open houden, eindelijk de laatste aflevering van Kyle XY kunnen zien, zelfs een film hier en daar \o/

Post-op (Maandag)

En weer een stukje beter! Als het zo blijft kan ik morgen met de auto naar de kliniek ter controle en om de bandagelenzen te laten verwijderen. Weer wat TV gekeken, zelfs wat kunnen computeren (zicht dichtbij blijft wazig). Ben benieuwd hoe het morgen zal gaan, als de lenzen eruit zijn schijnt het zicht nog beter te worden.

Post-op (Dinsdag)

Hmm. Met de auto naar Hoofddorp gegaan, dat ging prima. Alleen het gedeelte waarbij het zicht beter werd na het verwijderen van de lenzen blijkt niet helemaal te kloppen. Teruggereden met wat minder zicht dan ik graag gehad zou hebben Maar de lenzen zijn in ieder geval eruit, alles verliep ook prima volgens de beeldige oogartsassistente en ik mag over 3 weken terugkomen voor controle. 's Avonds vroeg naar bed gegaan ivm een pijnlijk linkeroog.

Post-op (Woensdag)

Goed geslapen, zicht is niet veel veranderd sinds gisteren. Linkeroog is in ieder geval niet pijnlijk meer. Net na het druppelen is het zicht prima, maar even later wordt het weer wazig en moet ik moeite doen om dingen scherp te zien. Maar ik heb in ieder geval geen pijn, de lenzen zijn eruit dus die irriteren niet meer... kwestie van afwachten tot het hoornvlies weer dik en egaal is! Gelukkig ben ik erg geduldig

So far mijn PRK ervaringen!

Laser + ogen = geen bril meer nodig of Laser + ogen = drama?

Ik ga erachter komen... voor volgende week donderdag een afspraak gemaakt voor een "LASEK (PRK) met CustomVue Wavefront" oogoperatie.

Vanaf mijn 13e een bril, toen nog -1 maar inmiddels opgelopen tot -3.50 / -2.75. Vanaf mijn 16e ook lenzen gebruikt, altijd zachte maar eerst maandlenzen en tegenwoordig daglenzen. Daglenzen zijn toch wel veel fijner, dat je niet bang hoeft te zijn dat je dure lenzen kwijtraken is sowieso een aardige geruststelling!

Maar lenzen en computeren gaat voor mij niet goed samen, ik knipper blijkbaar te weinig met mijn ogen waardoor ze droog worden en de lenzen gaan irriteren. En ik heb geen zonnebril op sterkte dus als het mooi weer is en ik wil de zonnebril opzetten moet ik eerst lenzen indoen, ook niet handig dus. Ik had ooit wel een zonnebril op sterkte, maar die zijn toch minder cool want niet in een hippe stijl zoals mijn huidige RayBan maar eigenlijk een gewone bril met donkere glazen. (Ik zeg 'had' want een of andere klojo heeft een jaar of 2 terug ingebroken in mijn auto en naast de autoradio ook mijn zonnebrillen meegenomen...)

Dus ik zit al een tijdje tegen een laseroperatie aan te hikken. Het is gewoon relaxt om goede ogen te hebben en van die bril en lenzen af te zijn. Het geld is ook niet zo'n issue, die 3k€ spendeer je ook wel aan brillen en lenzen over zo'n 20 jaar. Maar de mogeiljke complicaties zijn wel een minpuntje.

Omdat ik graag een weloverwogen keuze wil maken heb ik alle verschillende technieken nagepluist via het almachtige WereldWijdeWeb, en PRK is gewoon het veiligste: geen flapje wat teruggeplaatst wordt en waar van alles mis mee kan gaan, volledig herstel van je oog, minimale diepte van de oogoperatie. Maar ja, het grootste nadeel is dat het ook de pijnlijkste operatie is met de langste tijd voordat alles geheeld is.

Maar als ik moet kiezen tussen 'pijn en wachten' of 'een grotere kans op complicaties en zwakke plekken in de ogen' kies ik toch wel voor het eerste.

Daarna op Internet gekeken welke bedrijven de beste feedback krijgen en hoewel ik in Den Haag woon en er genoeg mogelijkheden in de buurt zijn, ga ik naar een bedrijf in Hoofddorp. Afgelopen woensdag op controle geweest, aardig personeel, vriendelijk en behulpzaam allemaal. Jammer dat de CustomVue scanner defect was dus dat moet donderdag voor de operatie nog even gedaan worden, maar voor de rest zijn mijn ogen in prima staat en kan ik gewoon behandeld worden.

Hoewel de operatie wordt 'verkocht' als LASEK is dat eigenlijk gewoon fake; het is PRK. Waarschijnlijk zegt het je allebei niks maar bij allebei weken ze met alcohol het bovenste laagje van je hoornvlies af; bij PRK gooien ze het vervolgens in de bio-bak en bij LASEK leggen ze het weer netjes terug zodat het sneller heelt en minder pijn doet (dat zou zo moeten zijn..). Maar waar ik tegenaan liep is dat bijna iedereen zegt LASEK te doen, en dan nog steeds dat afgeweekte hoornvlies gewoon weggooit... Beetje vaag allemaal, waarschijnlijk omdat PRK de oudste methode is en dat dat mensen afschrikt, dat mensen liever de nieuwste technologie hebben... ik weet het niet. Maar het heet dus LASEK maar het zal wel op PRK uitlopen

Dat CustomVue had ik nog niet uitgelegd, maar als je zoals ik grote pupillen hebt kan het zijn dat je in het donker (want dan zijn de pupillen groot) een soort van "halo's" ziet om lichten. Het is lastig uit te leggen maar onderstaand plaatje geeft het weer:


(Links is normaal, Rechts met halo-effect)

Dat komt omdat de randen van je hoornvlies dikker zijn en daardoor het licht verstrooien. Met de customvue scan worden de ogen met een hoge resolutie geanalyseerd en met de verschillen per gebiedje op je oog wordt dan rekening gehouden tijdens het laseren. Daardoor worden die randen dus ook verholpen en zou het halo-effect weg moeten gaan/zijn. Kost 500 euro extra per oog maar ik heb zoiets van 'als ik dan toch die operatie doe wil ik er wel als een soort van terminator uitkomen'.

Een beetje eng blijft het natuurlijk wel, vooral als je de horror stories leest op het forum van het ooglaser trefpunt. Maar ik heb de risico's gezien, een weloverwogen keuze gemaakt dus als het misgaat heb ik mezelf niks te verwijten.

Maar het kan natuurlijk nooit kwaad als jullie me geluk wensen

Zoals in eerdere posts beschreven sleutel ik aan een web-based applicatie. Nu valt er altijd wel wat aan de performance te verbeteren, door minder databasequeries toe te passen etc, maar ik las in een JSMin+ blogpost van crisp dat er een plugin voor een plugin van firefox is (YSlow voor Firebug) die de performance beoordeeld.

Dit gebeurt door middel van een handige scorekaart, dit is een voorbeeld resultaat (en tevens mijn eindresultaat):

(Klikbaar voor groter plaatje)

Hierbij is een Content Delivery Network niet relevant voor een lokale webapplicatie, en met Expires-headers heb je eigenlijk geen ETags nodig. Cookie-free domains wil zeggen dat je plaatjes e.d. op een ander domein zet zodat bij GET requests vanuit de browser niet elke keer de inhoud van het cookie wordt meegestuurd: ook dit is niet relevant voor een lokale webapp.

Wat in eerste instantie een slechte score kreeg, zijn de volgende items:

• Add Expires headers
• Compress components with gzip

En deze zijn dus eenvoudig op te lossen door de apache configuratie te tweaken!

Om voor het nageslacht vast te leggen wat ik gedaan heb beschrijf ik dit in deze blogpost. Hierbij moet ik wel een belangrijke disclaimer plaatsen: Ubuntu 8.04. Als je zelf een andere distro gebruikt kan het zijn dat je andere commando's moet gebruiken.

Add Expires headers

Zonder expires-headers weet een browser niet hoe lang hij een object (webpagina, plaatje etc) moet cachen. Standaard laadt een browser aan het begin van een sessie alles, vervolgens worden plaatjes/js/css etc tijdens de duur van de sessie gecached. Dat betekent dat er over een sessie heen niets wordt gecached... Beetje zonde! En daarom gaan we de mod_expires installeren
Het grote voordeel: Snellere laadtijden
Het grote nadeel: Soms verouderde informatie

Installatie gaat makkelijk via het a2enmod commando:

code:

1	sudo a2enmod expires

Tot zo de installatie, nu nog het belangrijkste - de configuratie:
Bestand: /etc/apache2/apache2.conf
Locatie: In hoofd-scope

code:

1 2 3 4 5 6 7 8 9 10 11

ExpiresActive On ExpiresDefault "now" expiresbytype image/gif "access plus 7 days" expiresbytype image/jpg "access plus 7 days" expiresbytype image/png "access plus 7 days" expiresbytype text/html "access plus 6 hours" expiresbytype text/txt "access plus 6 hours" expiresbytype text/js "access plus 7 days" expiresbytype text/css "access plus 7 days" expiresbytype text/javascript "access plus 7 days" expiresbytype application/x-javascript "access plus 7 days"

Bovenstaande zorgt ervoor dat standaard bestanden niet worden gecached. Voor de belangrijkste bestandstypes zijn vervolgens uitzonderingen gemaakt, HTML en tekst mag elke 6 uur opnieuw worden opgevraagd door de browser, CSS, JS en plaatjes veranderen maar zelden dus die mogen na 7 dagen uit de cache worden gegooid.

Compress components with gzip

Gzip is een compressie-algoritme. Als je deze aan apache toevoegt wil dat zeggen dat apache niet de originele data maar de gecomprimeerde data naar de browser van een bezoeker stuurt. Deze browser pakt het dan automatisch uit en geeft het weer.
Het grote voordeel: Minder bandbreedte nodig
Het grote nadeel: Extra CPU belasting van server (en client)

Vroeger heette deze apache mod 'mod_gzip' maar sinds apache 2 heet het 'mod_deflate'. Het is te installeren met de volgende opdracht:


code:

1	sudo a2enmod deflate

Nu zit de module in apache, maar het is nog niet geconfigureerd. Omdat het geen zin heeft om plaatjes te gzippen (die zijn al gecomprimeerd) kiezen we voor de volgende configuratie:
Bestand: /etc/apache2/mods-enabled/deflate.conf
Locatie: In <ifmodule> scope

code:

1 2 3 4 5 6 7 8 9 10

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript # Voor logging (kan weg als je weet dat alles goed werkt: # Begin logging stuk DeflateFilterNote Input input_info DeflateFilterNote Output output_info DeflateFilterNote Ratio ratio_info LogFormat '"%r" %{output_info}n/%{input_info}n (%{ratio_info}n%%)' deflate CustomLog /var/log/apache2/deflate_log deflate # Eind logging stuk

Nu is er standaard 1 probleem.... Apache weet niet welke bestanden als text/css of text/javascript of application/x-javascript worden verzonden. Daarvoor moeten we een kleine aanpassing doen:
Bestand: /etc/apache2/mods-enabled/mime.conf
Locatie: In hoofd-scope

code:

1 2	AddType text/css .css Addtype application/x-javascript .js

Nu snapt apache dat alle .css bestanden van het mime-type text/css zijn, etc.

Dan rest nog 1 taak: Apache herstarten zodat de wijzigingen van kracht worden:

code:

1	sudo apache2ctl restart

Zo! Performance getweakt = mission complete!

Na het plaatsen van de eerste blogpost ontdekte ik al meteen een bugje die ervoor zorgde dat de lettergrootte van reacties niet in te stellen is via CSS beheer. Crisp heeft het inmiddels gefixt dus \o/ het ziet er weer wat beter uit nu. Blijkbaar ben ik de eerste die de reactie lettergrootte heb gewijzigd

Maar genoeg over de vorige post, nu is het tijd voor... Usenet voor dummies!

Introductie

Usenet is een internetdienst waarmee gebruikers elkaar berichten kunnen sturen, een soort kruising tussen email en een forum. Dat was in ieder geval de oorspronkelijke opzet

Om het overzichtelijk te houden is er een onderverdeling gemaakt. Zoals je bij tweakers.net een forum hebt voor hardware zaken en een forum voor software zaken heb je bij usenet zogenaamde 'nieuwsgroepen'. Een aantal voorbeelden hiervan:

• misc.sci.chem
• comp.lang.c
• alt.binaries.pictures.wallpaper

Hiervoor geldt dat alle nieuwsgroepen die met 'alt.' beginnen, over het algemeen niet worden gemodereerd door iemand die bepaalt wat wel en niet gepost mag worden.

Omdat het een supercomputer en een enorme internetverbinding vereist als alle eindgebruikers op 1 systeem hun berichten plaatsen, maakt het usenet gebruik van een heleboel servers. Deze worden nieuwsservers genoemd.
Om te illustreren hoe dat werkt heb ik een tekeningetje gemaakt:



Hierbij zijn er 4 nieuwsservers (1,2,3,4) en de rode blokjes zijn eindgebruikers die via een usenet client berichten plaatsen in bijvoorbeeld comp.lang.c.

• Een gebruiker die op server 3 is aangesloten stuurt een bericht naar comp.lang.c
• Server 3 stuurt dit bericht door naar servers 1 en 4, die het allebei doorsturen naar server 2
• Een gebruiker die op server 4 is aangesloten vraagt de nieuwe berichten van comp.lang.c op
• Server 4 stuurt het zojuist geplaatste bericht naar de eindgebruiker

De berichten (voor usenet wordt de benaming "artikelen" gebruikt) worden zo dus voor iedereen beschikbaar gemaakt. Feitelijk is het een variant op email waarbij je het niet naar een eindgebruiker stuurt maar naar een centrale database waar iedereen toegang toe heeft. Als gebruiker heb je een usenet-client en daarin abonneer je jezelf op een aantal nieuwsgroepen die je interessant vindt. Vervolgens haalt jouw client de artikelen op van de nieuwsserver waar je toegang tot hebt.

In eerste instantie vraagt de client alleen de headers van de berichten op, dus de naam van de persoon die het heeft gepost, het onderwerp etc. De inhoud van de berichten wordt pas gedownload als je dat handmatig bevestigd, dit om verspilling van bandbreedte te voorkomen.

Retentie

Omdat een usenet-server maar een beperkte capaciteit heeft, worden oude artikelen na verloop van tijd weggegooid. De tijd waarover artikelen beschikbaar zijn voor eindgebruikers wordt de retentietijd genoemd. Met een langere retentietijd, of ook wel gezegd met een grotere retentie, is er meer informatie beschikbaar.

Binaire data

Usenet was dus bedoeld om tekstberichten uit te wisselen. Maar het zou natuurlijk ook handig zijn als je soms een (binair) bestand kan versturen, bijvoorbeeld een C-programma in plaats van alleen broncode. Usenet ondersteunt echter alleen 7-bit US ASCII karakters (dus alleen normale leestekens). Om dit toch mogelijk te maken hebben mensen wat trucs bedacht. Door de binaire data om te zetten in leesbare tekst, en er een soort label voor te zetten, kan toch binaire data geplaatst worden. Hiervoor zijn verschillende functies geschikt, zoals UUencoding, Base64 encoding en yENC, waarvan de laatste het meest efficient is.

Een ander probleem is dat een deel van de usenet servers een limiet aan de grootte van een artikel hanteren: naast het omzetten van binaire data naar tekst moet die tekst ook worden opgesplitst in meerdere artikelen. Dit is weergegeven in onderstaand plaatje.

Je begint met binaire data, dat wordt omgezet in leesbare tekst, en opgesplitst in stukken die in 1 artikel passen.



De ontvanger van die artikelen volgt het omgekeerde proces om tot de oorspronkelijke data te komen.

Robuustheid

Helaas komt het wel eens voor dat bepaalde artikelen verdwijnen bij het synchroniseren tussen verschillende usenet-servers. Als het niet al te veel moeite is kan de originele poster een zogenaamde 'repost' doen waarbij hij hetzelfde bestand nogmaals plaatst. Maar voor grote bestanden is dat natuurlijk niet praktisch. Daarom wordt er gebruik gemaakt van Par2 (Par1 werd oorspronkelijk gebruikt maar is vervangen door het veel beter werkende Par2).

Dit is een algoritme dat informatie over de te versturen data in een aantal par2-bestanden plaatst. Als nu enkele artikelen zijn weggevallen kunnen de par2-bestanden worden gebruikt om de verloren informatie terug te halen.

Bestanden downloaden

Stel, iemand heeft 1G aan data geplaatst in een nieuwsgroep. Die data bestaat uit 100 bestanden, 90 rar-bestanden van 10MB plus 10 Par2 bestanden van 10MB. Deze staan verspreid over zo'n 4000 artikelen, maar gelukkig brengen de meeste usenet-clients dit weer terug tot 100 berichten. Elk bericht heeft een onderwerp dat bestaat uit de bestandsnaam van de artikelen die erin zijn samengevat.

Handmatig downloaden van die 100 berichten is een kwestie van selecteren en op downloaden klikken. Maar stel dat je een bestand wil hebben waarvan je weet dat het in een nieuwsgroep staat waar je niet op geabonneerd bent, en die zo groot is dat alleen het downloaden van de headers al een halve dag gaat duren. Dan zou het handig zijn als je precies wist welke artikelen je van de nieuwsserver op moet vragen.

Om dat probleem te tackelen is het .nzb bestandsformaat opgezet. In een NZB bestand staat een verzameling van artikel-identifiers die vervolgens direct vanaf de nieuwsserver gedownload kunnen worden.

Het is dan niet nodig om je te abonneren op een nieuwsgroep, en alle headers op te halen maar gewoon 'klik' en 'download'. Deze NZB bestanden zijn daarom erg populair. Je kan het vergelijken met een .torrent bestand: er staan verwijzingen in waar informatie te verkrijgen is.

Usenet-clients

Er zijn een boel verschillende usenet-clients, de belangrijkste verschillen zijn:

• Het besturingssysteem waarvoor ze geschikt zijn
• Ondersteuning voor tekstberichten
• Ondersteuning voor binaire bestanden
• Automatisch uitpakken/repareren van binaire bestanden
• Command-line, Grafische client en/of via een webinterface

URD, waaraan ik dus knutsel, is voor linux, werkt via een webinterface en kan alles met binaire bestanden

PS: Mocht er iets niet kloppen, lemme know en ik fix het!