I have some quite old laptops laying around, and one even has a working battery, because I rebuilt it with new cells.
I need something with a display and some memory for showing data while logging. It has an RS-232, and while it is not expandable, it is expendable, so no catastrophe if I accidentally fry it, drop it, or it gets stolen.
It has a meager 12 MB RAM, 250 MB HD, and the chassis matches the screen which can only show dark and light grey. These are however sufficient.
Most "small" Linux distributions are not particularly small at all, but more adjusted to the size of phones, which typically have about 1/4 GB RAM and some gigabytes of flash.
I found 2 distributions for my size range, which I tested:
ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/4.11-RELEASESo, when installing I had to choose FTP through a firewall, and specify that address.
It is 200 prames per second.
This should work on a lot of netbooks as well.
I do it by accessing the screen memory directly. This was not easy.
I need it for rendering graphics that fill a lot of the screen, 60 times per second realtime. The standard libraries cannot do this.
This thinkpad uses Intels 915GM chipset, which shares the screen memory with the processor. To find this memory, I drew some random noise using X11, and searched for it in /dev/mem after doing mmap(). It turned out that the video memory was not sequential at all, but instead organized into blocks of 128x8 32bit pixels, where each block could be anywhere. This makes my graphics routines more complicated, since instead of looping on X and Y, it has to loop on 4 variables; 2 inside each block, and 2 for the array of blocks. But it is very fast anyway. I achieve about 200 frames per second of 1024x768 on this 1.5 GHz Pentium M.
This complexity also explains why XShmCreatePixmap and XFree86-DGA does not work, even though their lying libraries claim they do.
The fastest libraries in reality, XvShmPutImage, XShmPutImage, and OpenGL, has about the same speed of 50 frames/second. Ordinary XPutImage is twice as slow.
Ubuntu has destroyed /dev/mem, so I had to fix this by recompiling the
kernel with the option:
CONFIG_STRICT_DEVMEM=n
The picture on the screen is only partially visible when drawn,
because a lot of it is still in the caches, so each cache-line has to
be explicitly flushed when finished to make it visible in reality, on
the screen. This can be done with something like this:
if( (x&15) == 15 ) // flush cache line of 64 bytes
asm volatile("clflush (%0)" :: "r"( &(*Blocks[y2][x2])[y][x] ) );
I remember from the eighties that there were some research to make computers with them, but it was abandoned, because there were too much trouble with material fatigue and shrinkage when cooled to superconducting temperatures.
Today, hobbyists cool mass produced processors to those temperatures, such as the AMD Phenom II 940, to run it at twice its speed, reaching 6.4 GHz and more. And the superconductors conduct at much higher temperatures. So, where are the Josephson junction processors now? At NSA?
The connection between cancer and power lines is an old controvercy. Statistically, there is a connection between how close people live to power lines and how often they get cancer, but when animals are exposed to electrical fields in laboratories, they do not get cancer.
So my theory is that electrical fields do not cause cancer, but ozone do, and ozone is produced by high voltage power lines. Ozone is a powerful chemical which oxidized tissue.
I can hear the sparks from the power lines when I go under them, when they discharge to stuff in the air, thus generating ozone. An easy way to stop this, would be to sheat the lines in something loose and airfoil shaped, or paint them.
2 years ago I made a serious attempt at learning Go, because my experimental Othello player was sort of finished, and I needed a better challenge.
(I have since probably discovered a much better way to do minimax, and will prioritize implementing that over making a player of a another game.)
Go is said to be easily understood, but I soon found situations where any of the accepted asian "rules" do not apply. Even japanese monks have quarreled for several hundred years about some situations, and Japan has big books on how different situations are to be interpreted.
This means that Go is not a game, but instead a set of asian traditions.
I have since found 2 real rule sets for Go:
1. The
Tromp-Taylor rules,
which are understandable, but lack the weirdness of the Japanese tradition.
2. The
Japanese 2003 Rules
by
Robert Jasiek , Which reproduces the weirdness of the Japanese
tradition, while actually being rules, which are complicated and
recursive on several levels. Not a game fit for mere humans.
I found no joy in playing Go. Neither by pretending there were rules, nor by trying to understand the real rules. I suspect the optimal games tend to maximally long traversals of position space.
I walked down from the mountain I live on, through the forest growing on the hill side, along the gravel road cut through the bedrock. When I made a very short scrunchy sound with my foot in the gravel, I could hear the echo from the rock outcroppings like a weak shhh sound moving fast beside me.
It was possible to hear the main features of the hard rock, while the snow remained silent. The trunks of some big trees close by could also be heard. The time delay of echoes from rock a few meters further away came a little later, making the echo sound like it moved along. This made it easier to discern details, and of course sense the distance to the rocks.
The main problem was the difficulty of making the scrunchy sound short enough to avoid masking the echoes. Just one pebble bouncing away from my step would be enough to destroy the effect. I tried clapping, and making sounds with my mouth, but that seemed to be loud enough to mask the echoes too. It felt somewhat like trying to see after being blinded by a flash.
Why now?
Because of the UN resolution of forbidding criticizing religion.
But that was just the last drop filling the chalice. I have been thinking about writing a blog for a long time, containing mainly scientific themes, in no particular style, but with a focus on Ockhams Razor and the K.I.S.S. principle, which are some of the very few core principles of science and engineering, which are the opposite of religion, since they approach truth and quality, while religion is belief and superstition.