Feed-læser
Poul-Henning Kamp: Datalogisk Sorteringsmesterskab ?
Jeg har hørt om folkvalg hele dagen og et af de faktisk problemer er tilsyneladende at sortere stemmeseddlerne.
Hvis jeg havde troet de ville forstå joken, havde jeg strakt hånden om bag mig og med mandig stemme sagt "Hurtigt Robin, giv mig Bat-Datalogen!"
Men helt seriøst taler vi altså om et ...
Peter Toft: Raspberry Pi - den booter ... oftest :-)
Så skete det - jeg har fået en Raspberry Pi (faktisk har jeg fået to - som er solgt til en god ven).
Jeg har som en start installeret en Debian Linux på et 2GB SD-kort. Det fungerer fint, men det var et noget nedskrællet Debian image jeg startede med.
Selv "vi" var ikke installeret - ej heller...
Poul-Henning Kamp: eValg: Næste offentlige IT-skandale
Jeg skal til "workshop om elektroniske fremmødevalg" i morgen og jeg har allerede nu en grim smag i munden om det projekt.
Ikke alene for dets muligheder for at lave lort i vores mest fundamentale og på mange måder eneste demokratiske magtmiddel, men også fordi tilgangen til projektet på alle må...
Anton Berezin: Why does not it meow?
Today I've spent quite some time chasing a bug in a legacy code at work. In retrospect, the problem is trivially simple.
It can be illustrated by the following snippet.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <body> <script src="irrelevant.js" type="text/javascript"/> <script type="text/javascript"> function meow() { alert("meow"); } </script> <a href="http://dailyotter.org/" onclick="meow(); return false;"> click for meow</a> </body>So, why does it show you otters instead of meowing, and how long did it take you to spot the bug?
Jesper Louis Andersen: More on Erlang and State
One important key aspect of Erlang programs is to identify where your Stable state is in the program. Stable state is what you can trust. What you can trust is what you can build on. Joe Armstrong defines one of the key aspects of an Erlang system as Stable Storage. A place where we can push data and be sure it won't change. If we verify data before pushing, we can trust those data a great deal.
This is important. If our system partially crashes, as is the norm for Erlang programs, it may be necessary to reconstruct state. Stable storage provides the basis from which we can re-read data into memory. Even if recreating data is expensive, you may still want a cache to be able to reconstruct your state faster from disk. Persistent store on a disk is among the best way to make sure data is there.
In a BitTorrent client like eTorrent for instance, we only worry about the file. If we download a piece of a file and that pieces pass the BitTorrent SHA1 integrity check, we can now regard that part as "safe" write to stable storage, and never touch it again. I don't have to care about the internal state of peers I am communicating with. I don't have to worry about any internal structure in memory. The on-disk partial download provides all the needed information to reconstruct the system from scratch should I need it.
Second, there may be state we don't really want to lose - but we can afford it. We can't recreate a user input, so we need that on stable storage like above. But we don't want to redo expensive work if we can. To fix this in Erlang, we create a process to keep the important data, and we let that process protect the data simply by validating and verifying any change of the data. The process becomes a castle with the princess in it. And with a nasty dragon at the drawbridge. (Naturally, the princess and dragon have exquisite meals each night together and they like to dance tango. The nastiness and damsel-in-distress is only kept up for fun to lure unsuspecting knights to the party).
Third, we can exploit that sequential Erlang is a functional programming language. If we are state S1 and we apply a function to obtain state S2, we have an interesting property: either we obtain S2, or we get an error. But since the data store is persistent, we still have access to S1 if we keep a reference to it. This in effect creates an atomic way of processing: Either we get to the new state safely, or we can't move to the new state due to an error. This means that each state becomes a safe-haven in our processing. Since we can't mutate data, there is no way the processing to obtain S2 can corrupt the state of S1. It allows us to build programs that are highly stable as it ultimately works like a CPU: We have a state and atomically we process a clock cycle to obtain a new state. There is no "in between".
(Note: I must strain that modern CPUs are more advanced than this, but they try to uphold the illusion above)
Fourth, we can exploit the isolation between processes. To get state, I must ask another process for it. To ask another process for it, I must send it a message. It might never answer. So I must build my system around the idea that systems will fail occasionally. If it answers however, the data is now mine to do with as I please. It may be invalid since it is too old, but as long as I have it, I can do with it what I please. At that point, I don't care too much about the fate of the other process, since I have a safe copy. This in turn can used to build a system where we know where the stable state is all the time.
Fifth, we can exploit distributed Erlang. Have a couple of nodes. Store important data on multiple nodes. Now, should one node crash, the other nodes still have the data. And memory + network communication is often way faster than disk. Not to mention that you can get better parallel execution and faster recovery since data is already there in memory, ready to be served on the 10 gigabit link. The princess just phoned her girlfriends in Britain, France, Italy and Russia with the recipes for the next 100 meals (...and her work on homotopic type theory - princesses do have spare time to do research after all).
See, the point is: when the system begins failing - how do we want it to crash? When you get the chainsaw and slay the proverbial dragon (the tree in your garden which slighty but not really looks like a dragon at all) you don't want it to fall down into your nice house. You want it to crash differently, down on the lawn. The same with Erlang programs. We want them to crash so it has little impact on users, but also such that our important data is still safe. And if it goes really wrong, we want data persisted somewhere else. Either on another node in the cluster, or on disk. We want it to crash in ways which avoids the stable state.
The key is that we begin thinking about crashing a priori, before it happens. We think of where we have stable state and what parts we don't worry about crashing. The secret behind BitTorrent clients are that they are easy: you can throw away everything, sans the pieces of the file that have been checked for integrity. Everything else can just go crashing as it sees fit, we don't care. But when you take your own application and do the same kind of thinking, chances are that you will reach the same conclusion: there is a little bit of the system which needs protection, but you don't care about the rest.
That is a hint on how to structure your Erlang program.
PS. I should probably also write about how the loose coupling of Erlang processes foster good architecture, but that is another post for another time :)
(Edited a couple of times to fix wording - thanks DeadZen)
This is important. If our system partially crashes, as is the norm for Erlang programs, it may be necessary to reconstruct state. Stable storage provides the basis from which we can re-read data into memory. Even if recreating data is expensive, you may still want a cache to be able to reconstruct your state faster from disk. Persistent store on a disk is among the best way to make sure data is there.
In a BitTorrent client like eTorrent for instance, we only worry about the file. If we download a piece of a file and that pieces pass the BitTorrent SHA1 integrity check, we can now regard that part as "safe" write to stable storage, and never touch it again. I don't have to care about the internal state of peers I am communicating with. I don't have to worry about any internal structure in memory. The on-disk partial download provides all the needed information to reconstruct the system from scratch should I need it.
Second, there may be state we don't really want to lose - but we can afford it. We can't recreate a user input, so we need that on stable storage like above. But we don't want to redo expensive work if we can. To fix this in Erlang, we create a process to keep the important data, and we let that process protect the data simply by validating and verifying any change of the data. The process becomes a castle with the princess in it. And with a nasty dragon at the drawbridge. (Naturally, the princess and dragon have exquisite meals each night together and they like to dance tango. The nastiness and damsel-in-distress is only kept up for fun to lure unsuspecting knights to the party).
Third, we can exploit that sequential Erlang is a functional programming language. If we are state S1 and we apply a function to obtain state S2, we have an interesting property: either we obtain S2, or we get an error. But since the data store is persistent, we still have access to S1 if we keep a reference to it. This in effect creates an atomic way of processing: Either we get to the new state safely, or we can't move to the new state due to an error. This means that each state becomes a safe-haven in our processing. Since we can't mutate data, there is no way the processing to obtain S2 can corrupt the state of S1. It allows us to build programs that are highly stable as it ultimately works like a CPU: We have a state and atomically we process a clock cycle to obtain a new state. There is no "in between".
(Note: I must strain that modern CPUs are more advanced than this, but they try to uphold the illusion above)
Fourth, we can exploit the isolation between processes. To get state, I must ask another process for it. To ask another process for it, I must send it a message. It might never answer. So I must build my system around the idea that systems will fail occasionally. If it answers however, the data is now mine to do with as I please. It may be invalid since it is too old, but as long as I have it, I can do with it what I please. At that point, I don't care too much about the fate of the other process, since I have a safe copy. This in turn can used to build a system where we know where the stable state is all the time.
Fifth, we can exploit distributed Erlang. Have a couple of nodes. Store important data on multiple nodes. Now, should one node crash, the other nodes still have the data. And memory + network communication is often way faster than disk. Not to mention that you can get better parallel execution and faster recovery since data is already there in memory, ready to be served on the 10 gigabit link. The princess just phoned her girlfriends in Britain, France, Italy and Russia with the recipes for the next 100 meals (...and her work on homotopic type theory - princesses do have spare time to do research after all).
See, the point is: when the system begins failing - how do we want it to crash? When you get the chainsaw and slay the proverbial dragon (the tree in your garden which slighty but not really looks like a dragon at all) you don't want it to fall down into your nice house. You want it to crash differently, down on the lawn. The same with Erlang programs. We want them to crash so it has little impact on users, but also such that our important data is still safe. And if it goes really wrong, we want data persisted somewhere else. Either on another node in the cluster, or on disk. We want it to crash in ways which avoids the stable state.
The key is that we begin thinking about crashing a priori, before it happens. We think of where we have stable state and what parts we don't worry about crashing. The secret behind BitTorrent clients are that they are easy: you can throw away everything, sans the pieces of the file that have been checked for integrity. Everything else can just go crashing as it sees fit, we don't care. But when you take your own application and do the same kind of thinking, chances are that you will reach the same conclusion: there is a little bit of the system which needs protection, but you don't care about the rest.
That is a hint on how to structure your Erlang program.
PS. I should probably also write about how the loose coupling of Erlang processes foster good architecture, but that is another post for another time :)
(Edited a couple of times to fix wording - thanks DeadZen)
Poul-Henning Kamp: Win8/ARM - M$ på rette spor ?
Microsofts beslutning om ikke at lave plads til andre browsere på Win8/ARM får en del exposure lige nu. men jeg synes der mangler en dimension i debatten.
Microsoft står for første gang siden NT/Alpha overfor en CPU der virkelig adskiller sig fra X86.
Det er ikke sjovt, det er overhovedet ikke ...
Lars Sommer: Ved du hvad din firewall laver, når du ikke kigger?
Der har i mange år været fokus på malware til både PC'er, servere og smartphones. Men hvad med alt det andet udstyr vi har stående i serverrummet?
I 2010 og 2011 var der lidt fokus på SCADA-systemer, da Stuxnet-virussen blev kendt. Men der er intet fokus på netværksudstyr.
Har du nogensinde over...
Poul-Henning Kamp: Brugervenlig IT
Vi tvinges som borgere til at være data i en masse IT systemer, men vi får næsten aldrig lov til at udnytte de fordele som intelligent anvendelse af data giver mulighed for.
Forestil jer at parti kød viser sig at indeholde et eller andet farligt og skal tilbagekaldes.
Idag bringer man det i rad...
Peter Rude: Dropbox på OpenSuSE 11.4
Sidder og fedter med at få Dropbox installeret på min OpenSuSE 11.4. Der ligger en Fedora rpm på dropbox.com som fejler med uløste “dependencies” på pygtk2, som ikke lige er til at finde ud af.
Efter at have brugt alt for meget tid men at google, fandt jeg ud af, at dropbox ligger i softwarekilden ‘Hovedsoftwarekilde (Contrib)’.
For at spare andre for at spilde tid, klares installationen sådan:
sudo zypper addrepo http://download.opensuse.org/repositories/openSUSE:/11.4:/Contrib/standard/ “Hovedsoftwarekilde (Contrib)”
sudo zypper install dropbox dropbox-servicemenu nautilus-dropbox
Peter Toft: Raspberry Pi - om tre dage?!
I kan sikkert huske at jeg har bestilt en Raspberri Pi fra Farnell - og jeg er på venteliste hos RS..
Fra Farnell har jeg intet hørt siden jeg fik en faktura hvilket skete på bestillingsdagen. RS har siden den gang skrevet emails ud hver uge "nu er ...næsten.... nu" men ikke meget konkret info.
...
Poul-Henning Kamp: Steganografi er slet ikke nemt.
Blandt hovmodige "cybernørder" er steganografi altid et hit, primært på grund af "alle strissere er for dumme" antagelsen.
Lige nu er en historie i nyhederne om terrorplaner fundet på en USB stick fyldt med pornofilm, et klassisk eksempel på steganografi.
Det er svært at lave steganografi godt,...
Sune Vuorela: Boat to akademy?
I’m planning on taking the Tallink Silja boat from Stockholm to Tallin to get to (and from) Akademy. It is a all-night boat with restaurants, bars and almost whatever you would like. The boat leaves shortly before dinner and arrives shortly after breakfast and it is full of great fun.
Last time (Akademy 2010 in Tampere), Inge, Ryan, Chani, Martin and me were on such a boat and it was a nice experience.
Anyone up for such a experience this year ?
You hopefully know how to reach me
Poul-Henning Kamp: DDHFwiki er åben...
Det har taget noget knofedt, alle 350 sider er blevet læst igennem, men nu er Datamuseum.dk's Wiki åben for offentligheden:
http://datamuseum.dk/wiki/
Vi har ikke lige en kvart, halv eller hel milliard til at bygge et museum for, så indtil videre må vi nøjes med vores depot i Ballerup og vores ...
Peter Toft: Google Drive (del 2) - Google ringede til mig :-)
Efter jeg skrev mit forrige blogindlæg http://v2.dk/45054 så blev jeg ringet op af en PR-Manager for Google Enterprise i dag. Han skrev at Google har udsendt følgende præcisering i dag angående Google Drive:
As we state in our terms of service, we don't claim ownership or control over your cont...
Peter Toft: Google Drive - endelig kom det (og fejlede)
Hen over de sidste mange år har Google Drive været på rygtebasis. Netdrevet hos Google, som skulle slå f.eks. Dropbox af banen. I går kom det endelig på https://drive.google.com/ med fin Windows- og Android-integration.
Det spiller glimrende og direkte sammen med Google Docs, men ingen Linux unde...
Poul-Henning Kamp: eValg: Vis hvad I dur til ...
Der er folk der roder med "digitale fremmødevalg" i kommunalvalgs-kontext og de vil åbenbart have mig med i en workshop.
Fair nok, men jeg er en stor tilhænger af udliciteringer, så gider I ikke lige lave mit hjemmearbejde for mig ? :-)
"Digitalt fremmødevalg" handler om at få talt stemmerne h...
Søren Bredlund Caspersen: Nemoland Sommerkoncerter 2012
Nemoland har igen i år en række sommerkoncerter på programmet, hvor man bl.a. kan møde Sussi & Leo og Fallulah.
Programmet er tilgængeligt på Nemolands hjemmeside, men ikke i et specielt smartphone-venligt format.
Som en service fra mig til hele internettet er her således en Google-kalender med alle koncerterne indskrevet. Selvfølgelig med forbehold for fejl…
Rettelser er selvfølgelig velkomne!
Direkte links til html, ics og xml.
Foto af: Michael Falgreen.
Poul-Henning Kamp: Åh nej, ikke nu igen...
Har i hørt om IT-systemet "DUBU" ?
Det står for "Digitalisering Udsatte Børn og Unge" og har en formålsparagraf der hedder noget i stil med:
DUBU, en fællesoffentlig it-løsning, der vil fremme effektivitet og kvalitet på området Udsatte børn og unge, gik i drift ultimo 2011.Brug af løsningen re...
Peter Toft: Open Source på arbejde: Mød Søren Schrøder - arkitekt hos Telenor
Dette blog-indlæg er en del af en serie for unge om Open Source på arbejde - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-....
Søren har været med til at lave netværk og mange andre ting til Linuxforum/Open Source Days.
Jeg har med vilje gemt dette interview ...
Peter Toft: Open Source på arbejde: Mød Peter Müller - webprogrammør hos One.com
Dette blog-indlæg er en del af en serie for unge om Open Source på arbejde - læs mere http://www.version2.dk/blog/open-source-paa-arbejde-en-video-serie-unge-....
Peter Müller er ansat hos One.com - nok landets største web-hosting firma, med masser af Linux-maskiner. Peter laver webprogrammering...
