You may have heard about the pos­si­bil­i­ty that the Large Hadron Col­lid­er is be­ing sab­o­taged from the fu­ture.

That may sound pre­pos­ter­ous, but it re­al­ly is quite rea­son­able, once you think about it a lit­tle.

Let's start with the ob­vi­ous:

Sup­pose you trav­el back in time and kill your grand­fa­ther. Then you would­n't ex­ist. And you could­n't trav­el back in time. And that's a para­dox.

Then there is the an­ti-­para­dox:

Sup­pose you can't trav­el back in time. Be­cause you did­n't save him, your grand­fa­ther died. Er­go you don't ex­ist.

That's not a para­dox, but sup­pose time trav­el is pos­si­ble: that means you can go back in time, save your grand­fa­ther, and thus make your own ex­is­tence pos­si­ble, er­go al­low­ing you to save him.

As soon as you al­low for time trav­el­ing to be pos­si­ble, the so­lu­tion for para­dox­es is ob­vi­ous: you can´t change change the past be­cause the fu­ture won't let you. The fu­ture "fac­tion" that tries to pre­serve the past will al­ways win, be­cause the past is fixed.

So, if you trav­el back in time and try to kill your grand­fa­ther by shoot­ing him in the head, an­oth­er per­son from the fu­ture will ap­pear be­hind you and dis­arm you. Or ap­pear be­hind you and kill you as soon as you had the idea to trav­el in time in the first place.

Or your kid will drop a coke bot­tle on your time ma­chine just be­fore you used it to kill his great-­gramp­s.

The ex­act mech­a­nism used to pre­vent you from be­com­ing a para­dox is un­known to you be­cause you need to go fur­ther "for­ward" to know it.

Now, back to the LHC: if in the fu­ture there is knowl­edge about time trav­el, and there is knowl­edge about how the LHC may de­stroy the world[1]_ then maybe some time tourist de­cid­ed to see how hu­man­i­ty dressed in the pre-ice-age er­a, comes to 2009 and while eat­ing a sand­wich, some­how spooks a bird which then drops a piece of bread in the ma­chin­ery.

Which of course, brings me to the best time-­trav­el show on TV: "Mick­ey Mouse Club­house­".

If you don't have an un­der­-4 kid, grand­son or nephew, you prob­a­bly don't know it, but let me give you a sum­ma­ry of each darn episode.

1. Some­thing "bad" hap­pens (Goofy has a cold)

2. A so­lu­­tion is pro­­posed (Give Goofy some Min­nie­strone soup)

3. A fly­­ing ideogram of a mouse called Too­­dles shows a col­lec­­tion of tool­s:

   • Gi­ant can­dy cane

   • Roller skates

   • Pic­nic bas­ket

   • See­­­saw

4. Some­thing else "bad" hap­pens (Pete wants the soup)

5. The tools are ex­ac­t­­ly what's need­ed to solve the prob­lems pre­sen­t­ed to ac­­com­­plish the pro­­posed so­lu­­tion (Y­ou can use the see­­saw to move gi­ant rocks block­­ing your path).

This is ob­vi­ous­ly a case of the fu­ture pre­vent­ing some­thing from hap­pen­ing. How else would Too­dles know what tools to choose be­fore they are need­ed? There was no way to guess that a gi­ant rock would block the ravine through which Mick­ey and Min­nie would try to es­cape from Pe­te! [2]

So, when­ev­er you need to think about para­dox pre­ven­tion, re­mem­ber Mick­ey and his friends and just call Too­dles.

I have long known that ap­pli­ca­tion de­vel­op­ment is an ar­du­ous process. I have al­so long sus­pect­ed one of the rea­sons it's ar­du­ous is the de­vel­op­er. I should be more speci­fic, I am one of the rea­son­s.

That's be­cause I don't know what I am do­ing, and I don't mean that in the "I am a lame pro­gram­mer" sense (even if that's al­so true some­what), but in the sense that I lit­er­al­ly don't know what the app should look like, or what its fea­ture set should be.

So, I have de­cid­ed to em­bark on a se­ries of ex­per­i­ments I will call 24-hour app­s.

Here are the rules:

• I shall cre­ate a neat ap­­pli­­ca­­tion, sta­ble, use­­ful, us­able and de­­cen­t-look­ing.

• I shall do it in no more than 24 hours. Af­ter that time, it should be at least good enough for a pre­view re­lease, if not a be­­ta.

• Those 24 hours can be split in two or three ses­­sions

• Time spent do­ing icon­s, doc­s, etc, counts.

• All de­vel­op­­ment shall be pub­­lic (I am us­ing github)

• I must have a use for the re­­sult­ing ap­­pli­­ca­­tion, and it should be at least an ad­e­quate so­lu­­tion for that prob­lem.

So, what's the first pro­jec­t? I call it Die Schere (The Scis­sors in ger­man) and it's a video ed­i­tor.

It's not a kden­live re­place­men­t, it's just the video ed­i­tor I wish I had when I need­ed to glue a piece of one video with a piece of an­oth­er.

In the old, pre-dig­i­tal world, that was done us­ing a cut­ter and scotch tape. I want Die Schere to be as use­ful and com­pre­hen­si­ble as that was, but use­ful for clum­sy peo­ple like my­self.

Here is a video af­ter to­day's ses­sion, which last­ed 8 hours:

The ba­sic func­tions are there, even if lots of work is still need­ed.

• You can load clips to work with them

• You can cut clips (like us­ing a cut­ter!)

• You can choose the cut points in­­ter­ac­­tive­­ly or by ed­it­ing a time

• You can ar­range them (like us­ing scotch tape!)

• You can gen­er­ate the out­­put video

As a back­end it's us­ing men­coder, but there's no rea­son it should­n't work with ffm­peg or melt if some­one writes 20 lines of code.

Most peo­ple nowa­days have more than one com­put­er. Of­ten, you are us­ing one, and would like to do some­thing in an­oth­er. In this video, I will ex­plain how triv­ial it is to do that with­out leav­ing your seat in a mod­ern Lin­ux us­ing KDE.

We will use the fol­low­ing:

• Avahi, a ze­ro­­conf im­­ple­­men­­ta­­tion to let you find your com­put­ers in your net­­work with­­out wor­ry­ing about IP ad­­dress­es, DNS, etc.

• kr­f­b, the KDE Re­­mote Frame Buf­fer. This is a pro­­gram to share your desk­­top over the net­­work.

• krd­c, the KDE Re­­mote Desk­­top Clien­t, a VNC, RDP clien­t, which is what you use to see a desk­­top shared via kr­f­b.

I am sure users of oth­er op­er­at­ing sys­tems or desk­top en­vi­ron­ments will say they can do it just as eas­i­ly. In that case, feel free to do your own videos ;-)

Keep in mind that ac­cess­ing re­mote desk­tops over the in­ter­net is a whole dif­fer­ent beast, and this so­lu­tion is not meant for that case.

As usu­al, this video was record­ed us­ing qt-record­my­desk­top. There was mi­nor edit­ing us­ing men­coder.

The com­put­er used is the orig­i­nal Asus eee PC 701 4G, so you can see this is not ex­act­ly a hard­ware-in­ten­sive op­er­a­tion. I find the eee's small screen is great for this kind of ful­l-screen de­mo, be­cause it's not big enough to drown the im­por­tant part­s.