home
on exploration, introspection and creation

Archive for the ‘technology’ Category

Work Interactions of the Future

Monday, October 25th, 2010

We’re so used to the current model of getting work done that we rarely think about what it used to be like. Nowadays, we spend most of our people at our desks, staring at computer screens, where we interact with the entire world. The computer is our window into everything.

We used to talk to people in person more, and we used to have more meetings. We used to write notes with our hands. We used to deal with paperwork more. Office supplies–which feel so obsolete these days–were king.

But what will it be in the future? I think it’ll be a combination of the two. We’ll interact with people more–with computers having automated a lot of the repetitive tasks, we can focus on where we, human beings, add the most value: in being human. But we’ll need to be connected in order to get the leverage we need. We need something that we’ll keep handy that will keep us connected and serve as a tool for seeing, hearing, and taking notes. The iPad is actually a great example of a device that fits in very well with that model. I can absolutely imagine all of us carrying one with us at all times, just like we used to carry our notepads.

The Theories of Time Travel

Friday, October 22nd, 2010

Let’s assume that what we all secretly hope for is true: that backwards time travel is possible (with a fast enough rocket you can travel forward in time already, thanks to Mr. Einstein). It’s unclear what such time travel would look like — there are many different theories and, consequently, interesting implications on the Universe, the existence of paradoxes, and the existence and the nature of time loops. Note that to help myself think through this, I have a human being travel in time; this may lead to inaccuracies and further questions — in most of the cases below, we can probably replace me with a photon, or even a quark, and get more precise results (“memory” becomes “momentum” or “spin”, etc.). But it’s more fun to think about people traveling in time.

  • Let’s first assume that there is only one version of the Universe.
    • If the links between causes and effects are not maintained, we have a consistent (paradox-free) time travel: moving backwards in time rewrites history and the previous version is lost. The I that travels back in time (call it I1) is not the same as the I that I1 meets in the past (I2). Whether I2 enters the time machine or not is irrelevant to I1. If I1 kills I2′s grandfather, I2 will not be born but I1 will not be affected in any way. It’s a very safe theory of time travel.
    • If the links between cause and effect are maintained (but their temporal relationship isn’t, necessarily), the Universe has to decide how to handle duplicates of matter/energy: it may choose to allow them, or not, or have an opinion somewhere in between.
      • If duplicates are allowed, I1 is identical to I2 but they are allowed to co-exist. If I1 prevents I2 from entering the time machine, I1 will cease to exist. What if I1 kill’s I2′s grandfather (who is also I1′s grandfather)?
        • It’s possible that I1 will simply not be able to do this — this is the theory where the Universe maintains its consistency (by making it prohibitively expensive — either by requiring you to put a lot of energy into your action or outright generating laws that locally forbid you to perform it), somewhat akin to what the writers of Lost did in the show. This energy-effect constrained time travel — the Universe not letting me kill my grandfather — is interesting. In order to maintain its consistency, the Universe would need to propagate all actions forward (“play them out”). If there is a sequence of actions that cause an inconsistency, the energy required to continue along this sequence would increase, proportionally to the probability of an inconsistency. It would be like an invisible magnetic field that steers actions in a particular direction. This could be implemented by a biased averaging out of quantum effects: let’s take light for example. We know that according to quantum theory, the movement of photons from A to B is realized through an infinite number of different paths which average out to a straight line. However, if the probabilities of the paths are different (due to the fact that some paths may cause an inconsistency in the future), the paths could actually average to something that’s not a straight line. To us it would seem that light travels in curved paths (without the presence of any “real” field, such a gravitational one)!

          Of course, these probabilities change gradually so no obviously apparent deviations from the norm would occur at first. For example, if I’m intending to kill my grandfather, the Universe will start steering me away from my intention through a small sequence of very likely events. If I persist in my intentions, the events increase in magnitude, but it’s possible (because there are just so many possible events that can influence me) that I will never realize my intention without even seeing anything strange with the Universe.

        • Otherwise, we have a phenomenon known as the Grandfather Paradox. I1 may create an unstable point in the spacetime: I1 (and thus I2, and the grandfather) will both exist and not exist at the same time, in a kind of macro-Shrödinger effect. What’s worse, anything that either was caused by I2 or the grandfather or would have been caused by I1 will also both exist and not exist. It’s unclear what effect this will have on the rest of the Universe — as these effects ripple through time, they expand their scope (the events that the grandfather caused themselves caused other events) but decrease their magnitude (think of it as a sound wave propagating through space, maybe bouncing off objects).
          • It’s possible that over time, as soon as they become small enough to be captured by quantum uncertainty, they stabilize so the ripple has a finite size (I can’t visualize what the ripple would actually look like, maybe a really fast-flashing grandfather).
          • Or the Universe could cease to exist.
      • If duplicates of matter/energy are not allowed, I1 would need to replace I2 (for this to work, the Universe would somehow need to have a unique identifier for everything in it). It’s difficult to think about replacing something complex like a human being because he or she is made of many building blocks, each having a different identifier, so let’s simplify and think of something that consists of a single block (say, a photon). The photon would replace its version from the past. Does this photon have “memory”, that is, its future state?
        • If so, the photon will likely change its course (behave differently than I1 did). This may mean that I2 may never end up traveling in time, but that’s fine because there is only version of it. This is equivalent to the theory of rewritten history.
        • If not, I1 simply merges into I2 — I2 enters a time loop which it will never be able to leave. It’s not aware of that, however, so to I1, the time travel ends its consciousness.

        If somehow we can maintain this option at a macro scale, it’s possible that an individual may travel back in time and maintain his or her memory, provided that the interval of time travel is small (for example, if I1 travels back to before I2 was born, I1–an individual–would have to replace a bunch of particles which aren’t even part of a human being. That will very likely result either in the destruction of I2–I2 will not be possible given the new state that all of its particles will have assumed before they created it–or in the destruction of I1–the “memory” that each particle has will be insignificant and so I1′s consciousness will end as soon as he travels in time)

      • Another way not to allow duplicates would be for I1 and I2 to “swap” places: as soon as I1 travels backwards in time, it takes I2′s place and I2 takes I1′s place in the future. When I1 gets to the time when it first traveled in time, he ceases to exist. There is no paradox because time travel transfers both I1 and I2. It doesn’t matter whether I1 actually enters the time machine the second time around or not, because his existence ceases past that point anyway.
      • Finally, the Universe may choose some option in between, for example, I1 and I2 will be entangled in a way that doesn’t increase entropy. This may look like a kind of constrained time travel, where paradoxes are not possible because they are prevented by the entanglement of I1 and I2 (in other words, I1′s and I2′s actions will either make both of them survive the interval of their co-existence, or make them both self-destruct. At the event of time travel, I2 goes back and I1 is the only entity remaining.

        This brings me to an interesting idea: what if time travel and quantum theory are actually one and the same? What if the time interval where I1 exists in the past (and influences outcomes) is equivalent to the cat being both alive and dead: it cannot be inspected, and nothing can be said about what happened or what any of the outcome that I1 could have influenced was. The instant at which I1 entered the time machine would then correspond to the box being open — we find out what all those outcomes were.

  • Now let’s suppose there are many versions of the Universe. This is similar to the first case (rewriting history) but if the Universe bifurcates with every time travel, an awful lot of energy is needed to do time travel. Alternatively, the Universe may already exist in its virtually infinite forms, each form corresponding to a different possible unfolding of an event. We know from Newton that at a high level the world seems deterministic, but at a quantum level it’s not — this randomness I see as a basis for the different unfolding of the events (hence, once and for all answering the problem of free will: there is no free will, but there is also no determinism — what we perceive as “choosing” is just a particular folding up of all the quantum uncertainties). So every time we put a cat in a box, there are Universes in which the cat is dead and Universes in which it’s alive. We know which path we’re on as soon as we open the box. Time travel would then simply be an opportunity to follow a different path.

There is one problem with many of the sub-theories above, and that is a problem of the sudden injection of matter/energy. It couldn’t have been created from nothing. It’s possible that as this new matter/energy is injected, some other matter/energy is transferred into the future (where the travel originated). Possibly an arrangement such as one in Primer is needed where travel is only possible to a limited point in time, where all the prep work has been done, for example enough energy has been set aside to be “displaced” by the newly arriving energy. It may also be that the time travel portal has a standby energy consumption — it consumes energy at some rate, like a leaking pipe, all the time — this would allow energy of at most that rate to be transferred from the future.

Another way to solve the sudden injection problem is to borrow me for the duration of the time travel episode from the time chronologically after the event of time travel. That is, if in the year 2010 I go back to the year 2005, my extra existence for five years between 2005 and 2010 will be borrowed from what would have been my existence between 2010 and 2015. In other words, as soon as I reach the year 2010 the second time around, I jump to the year 2015. This is a kind of quantum entanglement, but not of I1 and I2, but rather of I1 and the future version of I1.

Programming PCs circa 2000

Monday, October 18th, 2010

As a teenager I spent a lot of time programming. I was mostly interested in making games, and for this I had to get involved in the fairly low-level structures, such as interrupts, system calls, and I/O ports. While I mostly programmed in C (DJGPP — a C clone that was available for free for PCs, implementing an extended memory module which allowed me to finally relax the limitation of being able to use up at most 640 kB of memory in my games), I had to implement some assembly routines because using a high-level language for this was simply too slow. The most complex graphics routine I implemented was a routine to copy a rectangular block of pixels from one place (usually an off-the-screen buffer) to another in a way to preserve all pixels marked with a special color (a mask).

It was a wonderful world–there is something magical about dealing with low-level operations. The information I needed to display pixels on screen, or to control the mouse felt in a way like knowing a secret code that unlocks the door with the treasure behind it.

Around 2000 I had enough knowledge (all before I ever got a modem!) to compile it into a kind of cheatsheet. Now, about ten years later, it’s time to share it with the world. Of course, very little of it is relevant anymore — although most if not all of the information should still produce the same effects, thanks for the crippling yet comforting fact that PCs have been painfully backwards compatible for the past decade or more.

The PDF is a little dense, so it deserves a brief walkthrough.

  • Some operations were possibly simply by inspecting a fixed location in the computer’s memory. Most of the information could simply be read, but some could also be fetched by writing a particular set of codes in specific locations. Putting information directly in the computer’s memory has never been recommended (and these days, virtual memory makes it almost impossible), but by inserting bytes directly in memory the computer’s behavior could be changed wildly — most times it would crash the OS, but sometimes it allowed you to get infinite lives in your favorite game or get some creepy screen effects. I used to stay up at night and hunt for locations in memory, mucking with which produced the most spectacular effects.
  • Most low-level operations were provided through issuing a set of interrupt operations to the microprocessor. The OS (in this case DOS) would interpret them in a particular way. Usually you needed to specify additional information — you did that by writing directly to the processor’s registers
  • I spent a lot of time figuring out how to display graphics on the screen. Back in the early 2000, everyone’s resolution of choice was a 320×200 resolution with a color table of 256 colors. Since every pixel was a byte, and the colors could be changed globally, this allowed for a number of games that displayed graphics fast and cycled through the colors. Extended modes (called VESA) were also possible and they offered higher resolutions and full color spectra (15-bit, 16-bit or 24-bit)
  • When you wrote a game, you pretty much had to intercept everything that the OS (MS-DOS) tried to do for you. The default mouse offered by MS-DOS was awful, the keyboard had a frustrating delay that you couldn’t get rid of and the OS wouldn’t even inform you when most of the keys were pressed. Fortunately, it was possible to handle the keyboard and the mouse through similar OS interrupts
  • Finally, the document concludes with some common file formats.

Fortunately, technology today has great abstractions and high level routines that make it unnecessary to know most of what’s in the cheatsheet. I am proud to have had to figure all this out, though — in an extension to many Java jokes, I think in order to be a great programmer, you have to understand the technology stack all the way down to microprocessor commands. The effect is a kind of deep connection with technology, the ability to make optimizations based on what’s going on deeper in the stack (such as my need to write assembly code back in 2000), but also a good deal of humility.

Here it is: programming-cheatsheet-2000.pdf

Unsubscribing

Thursday, October 14th, 2010

I often get periodic emails from technology vendors who are marketing their products. I’m happy that all these emails have an option to unsubscribe, but I am very unhappy with how the unsubscription is often handled.

  • The link takes you to a form that forces you to type in your email address again
  • Confusing check boxes (where it’s unclear whether you’re opting in or out of subscriptions)
  • A good one I saw today: the page says in small font that I’ve been unsubscribed, and presents me with a huge button to “resubscribe”. I wonder how many people accidentally press that button hoping to proceed with the unsubscription
  • And, the absolute worst: a message saying that the request will take four to six weeks to process. (“Huh? What exactly needs to happen to your automated email system to remove me from it that takes four to six weeks??”)

It’s Easter Eggs all the way down

Monday, October 11th, 2010

I love the idea of Easter Eggs — small pieces of functionality hidden from the user (and, obviously, undocumented). If you haven’t already, you should read Thompson’s paper on trust, and, related, the possibility of a combination of scary, but very clever Easter Eggs: hidden functionality that allows you to login to any Unix terminal. The login utility is frequently recompiled, but if there is a corresponding Easter Egg in GCC that introduces the backdoor whenever login is compiled, the backdoor could be preserved. GCC itself is recompiled frequently — but it’s recompiled with another, older version of GCC — so if GCC also included an Easter Egg that tells GCC recompiled with it to introduce an Easter Egg whenever login is compiled with it… voilĂ !

What if we take this principle and apply it even further, as far as we can? Using the fact that as systems get more low-level, they get more complex, and so it’s increasingly more difficult to audit their functionality. So, if we’re worried that people may inspect the assembly language of that original GCC (or write their own GCC), we could put an Easter Egg in the microcontroller that looks for a specific combination of assembly instructions and executes special, tucked away code. At this point inspection becomes very difficult. Of course, the particular sequence of commands to look out for is complicated (and there are probably many such sequences — depending on the compiler optimizations, a simple compiler instruction may get assembled into all sorts of crap). However, with any system that’s complicated enough, you can see any pattern you like, and you shouldn’t underestimate the possibility of even simple patterns remaining undetected for a long time.

Can we keep going (as if there was much point in continuing!)? Of course; people use layout software (and–even better–usually simply just higher level synthesis software such as Verilog) to lay out what will become a microcontroller. We can add an Easter Egg there. This takes us back to software which is compiled with GCC — and you can see how we could continue this process indefinitely, with tools that we would never think would be used in that “critical path”. So I dare you, dear reader, to create the longest chain of Easter Eggs you can. Bonus points for creative inclusions! (Of course, it would be silly to keep doing it a lot, for the resulting code would likely be massive — think lots of lookup tables. Unless we do some serious hackery — it is, after all, possible for very short code to generate very long sequences…).

Can we protect ourselves against such a mindblowing seemingly infinite chain of Easter Eggs (or–more relevantly–security vulnerabilities)?

Disposable Software

Monday, October 4th, 2010

So far we have been optimizing our software development practices for the increased lifetime of our software — yes, simple features, especially around the beginning of the project will take a long time to develop because we want to structure our code in a way that will reduce tech debt in the future. We tend to keep tech debt at a steady low number — something like 10% — precisely because it’s debt, and we don’t want to pay it off over a long period of time.

What if we make it easier for software to be thrown away, and start optimizing for rapid release? That would be a huge paradigm shift: our users would have to get used to the feature set changing rapidly, even losing feature they may like. There are some cool things we could do, for example write code that literally expires (and a countdown clock for the user so he/she is not surprised when the feature disappears).

Something to think about…

Lifehack #31: Hot corners

Saturday, September 25th, 2010

If you have an operating system that allows you to assign functions to corners, take advantage of that feature. I use it to show my desktop, and to show all windows in one view.

The reason I prefer to use the mouse for the operation is that when I want to see my desktop or all windows I’m planning on using the mouse anyway (to open a file on the desktop, or to select the window I want). While using keyboard is in general faster, if you have to switch between the mouse and the keyboard you’ve lost that advantage anyway.

Interchanges

Wednesday, September 22nd, 2010

Here is my version of a stack interchange — a system of two highways intersecting such that cars coming from any direction can either go straight, turn right onto the intersecting highway, or turn left in the opposite direction of the intersecting highway (I didn’t allow U-turns so as not to complicate things too much).



My highway interchange: the red arrows show the paths that drivers going in a particular direction could take. Note that at most two lanes intersect at a point which makes it conceivable to build the interchange with two levels only; in the diagram the broken lane is below the other

And here is a slightly different version that doesn’t suffer from the problem of a center being too dense — if you look very carefully, you’ll see that in the version above, the centers of each of the arcs would meet unless the drop is not uniform.



Addressing the problem of a dense center

It seems to me that it can be built with two levels only — although something makes me think that it’s not that viable to build (since existing stack interchanges require four or more levels), plus to ensure a practical speed it would either have to have a rather large surface area, or only allow passenger cars driving with reduced speed. Here it is in three dimensions



My stack interchange in three dimensions



My stack interchange, zoomed in. The lane splits into three lanes and each separate lane takes you into one of the three directions.

You can download my Google SketchUp file here.

The structure of elevenseconds.com

Tuesday, September 21st, 2010

I tend to favor building to buying when I want to learn something, so when I first started constructing the main site elevenseconds.com I thought of building myself a small Rails-like framework. The main difference would be that it would apply to a simple principle of just-enough abstraction layers, that is, I would introduce a new abstraction layer when I left that the cost of maintaining the current code was too high. I am currently pretty happy with the structure of the site, although updating the front page takes a bit of time so perhaps it’s time to introduce a new layer of abstraction.

At a high level, all requests go to an index page

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.cgi [QSA,L]

which grabs the desired page to be visited from the URL as well as the subpage option (I thought it would be cool to separate the option with a colon — I never liked the questions marks and ampersands, and overloading slashes for paths and parameter separations never agreed with me. And so http://elevenseconds.com/photography/italy:slides takes you to an index page which knows to display a page called photography/italy with an option of slides.

Most of the pages are very similar so I put in place a kind of Metacontent-Metaview paradigm: every page request will fetch content from the /content/ directory. The ruby files there are organized in the same hierarchy as the URLs, so the above link will fetch content from /content/photography/italy.rb.

The actual content file is very configuration-like; let’s take a look at a part of the main content file (root URL resolves to /content/main.rb):


append = []
append << rendering('text', {
  'x'=>1,
  'y'=>0,
  'text'=>'<img src="/images/ui/whatis.png"/>11seconds: on exploration, introspection and creation'
})
append << rendering('verticalLine', {
  'x'=>1,
  'y'=>2,
  'size'=>3
})
append << rendering('imageWithCaptionOnRight', {
  'x'=>1,
  'y'=>2,
  'link'=>'http://blog.elevenseconds.com/trends/',
  'src'=>'/images/thumbs/main/glogo.png',
  'text'=>'trends'
})
append << rendering('imageOnRight', {
  'x'=>1,
  'y'=>11.5,
  'link'=>'/pictures/glowdoodle',
  'src'=>'/thumb.cgi?im=/images/pictures/glowdoodle/sadterminator.jpg&x1=197&y1=74&ss=344',
  'id'=>'projects',
  'text'=>'glow doodles'
})
render('main', {'append'=>append})

append is really a collection of items to append. Each item is a rendered view with some parameters. Each view is simply some HTML markup with Ruby inline code. For example, imageOnRight.rb contains

<div class="rightOfLine" style="left:#{x*35+2}px;top:#{y*35+69}px">
  <a href="#{link}">
    <img class="image" src="#{src}"
      onMouseOver='caption("#{id}", "#{text}", "#{link}")'
      onMouseOut='caption("#{id}", "", "")'/>
  </a>
</div>

(To make the page more structured, I decided on absolute positioning — maybe that’s because I’m a bit of a control freak.)

Note that I’m not quite allowing hierarchical content — there is no need for it given the current design of the site. All I need to do is a two-level hierarchy: a main view (the last line in the main.rb file above may include a bunch of other views.

I needed to introduce another abstraction because a lot of the sites with photography looked the same and I saw myself writing the same code over and over again. So I wrote a function that displays a generic set of pictures. Take our italy.rb content page:


category = 'photography/italy'
caption = 'italy june 2010'
images = [
  ['italy-0', true, '115, 45, 305'],
  ['italy-1', true, ''],
  ['italy-2', true, '296, 20, 54'],
  ...
  ['italy-45', true, '117, 75, 85'],
]
append = []
append << generateSeries(images, category, caption, [534, 356, 2.42])
render('main', {'append'=>append})

The above specifies the absolute minimum that is needed to render the Italy photographs — a definition of each images (I don’t always just number them in sequence), with a specification of whether the image is in landscape (true) or portrait (false) mode, and the top-left coordinate and the size of a window which will be made into a thumbnail. If not specified, the function chooses a smart default.


$explore = [
  ['http://www.gagneint.com/Final%20site/Animation/Sensology/Sensology.html', '/images/thumbs/main/sensology.png', 'sensology'],
  ['http://js1k.com/demos', '/images/thumbs/main/js1k.png', 'demos'],
  ...
]

I do the same with the front page — since it’s mostly made up of a bunch of links, I define each (in the example above, all I need for a link is a URL and a thumbnail picture) and then just cycle over the array. I only look at the latest 10 images for each category (except for EXPLORE which gets 20) but when you click on the link you get them all (http://elevenseconds.com/detail:explore) — again, code reuse.

As the content gets more streamlined (and as I get more lazy), I’ll probably go a step further towards configuration and just define everything in some standard configuration format like JSON (XML may be human-readable, but it’s certainly not human-writeable!). My goal is not quite to minimize the number of characters that I type (because then the conventions at play will no doubt be too obscure, plus the amount of plumbing code I’ll have to write too much for me to remember what I wrote in a year), but I’ll want to get close to it.

The thumbnails are also pretty painless. The utility page, thumb.cgi, generates a thumbnail out of any picture. You just need to specify the top-left coordinate and the size of the window to made into a thumbnail, and the resulting size. Most thumbnails on my page are 32×32 (it’s a kind of hallmark of the site). Some are 67×67 (not 64×64 because I want the images to line up — two 32×32 in a row actually take up ((1+32+1)+1+(1+32+1)) = 69 pixels because of the border and the one-pixel gap so to replace it with a bigger picture means it needs to be 67: (1+67+1)=69.

thumb.cgi saves the autogenerated thumbnails in a cache directory so that the images don’t have to be scaled each time the page is loaded. That is, when thumb.cgi is called with the same arguments again, it will just bring up the saved thumbnail instead of resizing and cropping the picture:


# by default output png unless the target size is specified
format = cgi.has_key?('sc') ? 'jpeg' : 'png'
hash = Digest::SHA1.hexdigest(ENV['REQUEST_URI'].to_s())[0..7]
cacheFile = "cache/" + hash + "." + format
if(File.exist?(cacheFile))
  puts cgi.header("image/#{format}")
  file = new File(cacheFile, "r")
  puts file.sysread(20)
  exit
end

But (great example of just-enough abstraction layers), I go even further: instead of having thumb.cgi do the logic, I replace the source of the image when rendering the view with its cached image. That way I don’t even have to call thumb.cgi which significantly speeds up the page load:


def gen2cache(html)
  source = html.clone
  links = []
  while(source =~ /"(\/thumb.cgi\?[^"]+)"/)
    links.push($1)
    source[$1] = ''
  end
  links.each { |link|
    format = link.index('sc=') ? 'jpeg' : 'png'
    hash = Digest::SHA1.hexdigest(link)[0..7]
    cacheFile = "cache/" + hash + "." + format
    if(File.exist?(cacheFile))
      html[link] = "/"+cacheFile
    end
  }
  return html
end

I guess the next step would be to actually autogenerate the entire HTML response.

Anyway, while Rails is certainly a much better solution to arrive at the final answer, I’ve learned a great deal about Ruby through this exercise. I doubt I’ll make the site much more complex than that.

Life Hack #30: VPN

Sunday, September 19th, 2010

Use VPN if you’re abroad and your favorite movie or TV show streaming service is using some legal excuse to prevent you from catching up on that episode of Lost where they explain everything. (I used to do that back when Skype had free calling anywhere within the U.S.)

You can search for personal VPN services with servers located in the U.S. — I am not in the business of endorsing other services unless they are, like, the best thing since sliced bread — there are even some free ones.