Well, ideally you should be able to make two versions of the code that work for the different platforms. Most of the code is shared between them. The biggest problems arise from slight hardware differences like the timers and USB hardware.

2.41 and 2.43 are practically identical. Probably some obscure bugfix somewhere.

So, I'm adding a poll: Select the different versions of the OS you would install.

The system didn't originate with electronics. I'm just claiming that when it did it was a joke.

You should throw in some of DJ's metal stuff.


Also:

On the plus side, this tech has really high seek speeds since the spindle motor relative to the tape is moving along more data. (Same area with more data on it.) This means that you should be able to read significantly faster than earlier tape drives. However, writing will still take the same style of magnetization, so it likely does not see any real improvement.

It's worth noting that the only real difference between tapes and drives from a functionality standpoint is that drives can move in two dimensions, whereas tapes move in only one. This means the drives can seek exponentially faster relative to size, but tapes can be infinitely large.

For data backups tape is the perfect medium. dd literally writes sequentially, byte by byte.

Let me think: 300 DPI on paper that's 8.5"x11" (US Letter Size, same width but shorter than A4 for you metric folks)
300^2 = 90000 Pixels per Square Inch
8*10.5 = 84 Square inches printable per page (approximate, depends on your printer's feed mechanism and print head)
84*2 = 168 Square inches, double sided
90000*168 = 15120000 pixels per paper
15120000/64 = 236250 sprites per paper
2^64/236250 = 78081456396655 papers
assuming 0.000984252 inches thick (.025mm)
0.000984252*8.5*11*78081456396655 = 7185646069593.465 cubic inches of paper
7185646069593.465 / 12^3 = 4158359994 cubic feet of paper
4158359993 / 5280 = 0.028250121258480552 cubic miles of paper

So, in conclusion, probably an obtainable amount of paper, but not a feasible amount as far as cost or indexing goes, and the printer ink will be the main cost anyway.

Actually it's 8 bytes per sprite, not two.

We wouldn't need to store them all. We could generate them on the fly extremely easily, since it's just a 64-bit number. Pass the 64 bit number and a small javascript program could generate it using a small canvas element.

The easy way to test if you have opengl acceleration is to use the glx programs in mesa.

So,  sudo pacman -S mesa.

glxinfo | grep rendering

That should give you a line that says either yes or no. Yes means you have some form of opengl acceleration.