2) A PORTFOLIO CONSISTING OF:

• A minimum two page comic story starring yourself, a snowman, a robot, and a piece of fruit.

BEST ADMISSIONS REQUIREMENT EVER.

I had heard in the past that the middle range of print quality went from 300 dpi to 600 dpi, with <300 being low quality and >600 being high. However, I looked around while writing this up and found that much of that number has to do with displaying color, and the fact that printers typically work with only 3 colors in fixed sizes (plus black, which is not used in combination). This gives only 8 color values per dot, so they need to use more dots (more dots! Okay stop dots.) per area to get a given color.*

In place of “print quality”, then, I decided I really meant “the unaided eye can’t see pixel boundaries. Now, I have a little bit of experience I can bring to bear here: the OLPC, in monochrome mode, has a DPI of exactly 200. With that, I personally can see pixel boundaries only in small text, when I look very closely. To allow for the possibility of people with better eyes than me, and for proper letter spacing in small text, I’d say 300 dpi would be past the limits of all but a few people. This would be necessary for monochrome, and more than sufficient for color.

Now giant needs to be defined, and what I’m imagining is around 1 meter square (perhaps already too large for a high dpi to matter, but I know I’d be that close to the screen trying to read the book reflected in the mirror in the image taking up only part of the screen).

Assume that at least 85 HZ refresh rate is needed (I know people that can see flicker at 75 on a CRT, other technology such as OLED might make it harder to get annoyed by but still within the eye’s ability to see).

Putting it all together, you get a little under 12000×12000 pixels, and a total pixel clock needed of around 12 billion pixels / second.

Now, I’ve had trouble finding pixel clock numbers on modern graphics cards. The OGP’s upcoming graphics card looks like it’ll be 330MHz. I found a few numbers on older cards at about that range. My guess is that, since there hasn’t been a need for it, even high-end cards are barely above 500. If we say that improvement on this would follow a misstated Moore’s law and double every two years (probably underestimating potential in the early years, but then, they won’t do it anyway because there won’t be enough demand), it’d take about 9 years for a graphics card to be able to handle that many pixels.

If we assume that LCD and plasma can’t get that good a resolution and OLED will be needed (I’m imagining a very thin screen anyway), the question is then “will a screen of that size and resolution be feasible with OLED 9 years from now”. My guess is 9 years from now, if there were enough demand, something like that could be (very expensively) produced.

So, in summary, if enough people wanted it, in about 10 years… in reality, it’ll probably be barely possible to buy in 20.

* Modern printers apparently can have variable amounts of ink per dot, though not as much as monitors vary light

It’s nice to see that, outside some bleeding-edge developer stuff that you can’t even get to without a good knowledge of the OS, this security feature just works. Hopefully it can be enabled by default soon.

File: jesus.c

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    pid_t  pid;

    pid = getpid();
    fork();
    if (pid == getpid()) {
        strncpy(argv[0],"god",strlen(argv[0]));
        sleep(30);
    } else {
    }

    return 0;
}

And then…

$ ./jesus &
$ ps ax | grep jesus
19565 pts/0    Z      0:00 [jesus] <defunct>

Voilà! Your very own zombie jesus! (for 30 seconds)

(See also: http://en.wikipedia.org/wiki/Zombie_process

Sphere packing on the corners of a hypercube (with the spheres defined by Hamming distance) corresponds to designing error-correcting codes: if the spheres have radius d, then their centers are codewords of a d-error-correcting code. Lattice packings correspond to linear codes. There are other, subtler relationships between Euclidean sphere packing and error-correcting codes; thus, the binary Golay code is closely related to the 24-dimensional Leech lattice.

Grr. Stupid wikipedia, I was trying to slack off. >:o