Avian’s Blog

When I was designing Galaksija's video amplifier I did some reading on the design of analogue (now called low-definition) TV systems. It's impressive how much science and research went into this.

The resolution of various components of the video stream (luminance, chrominance) for example was chosen on the basis of research into the capabilities of the human eye. Only some relatively minor design decisions were based on technology limitations of the time (like interlaced picture).

Now suddenly there appears to be a general opinion that these 40-years old specifications aren't good enough and that everyone should move to new HDTV standards. These new standards seem to be based on a race who will cram more pixels on the screen rather than some scientific method (it seems they can't even decide on a single picture format).

So I wonder: either the designers of the original TV missed something and the resolution of the analogue TV is really smaller than it should be or are HDTV systems designed only so that they look better in the shop when you're looking at them from a much shorter distance than usual and can actually see the difference in the resolution.

This piece of Z80 code will assemble into a certain 16 byte sequence that seems to be quite popular last few days.

add hl,bc	;0100   09
ld sp,hl        ;0101   f9
ld de,09d02h    ;0102   11 02 9d
ld (hl),h       ;0105   74
ex (sp),hl      ;0106   e3
ld e,e          ;0107   5b
ret c           ;0108   d8
ld b,c          ;0109   41
ld d,(hl)       ;010a   56
push bc         ;010b   c5
ld h,e          ;010c   63
ld d,(hl)       ;010d   56
adc a,b         ;010e   88
ret nz          ;010f   c0

Do you think all this Web-two-point-oh You-control-the-information-age stuff was made possible by fancy XML, Javascript and other technologies I haven't heard about?

Wrong. I think user-provided content on large web sites was feasible only after the use of Captchas became wide-spread. All web pages would be filled with links and advertisements for casinos and porn sites without this inaccessible, politically incorrect and unfortunately also the only reasonably effective way of detecting a living brain on the other side of the HTTP connection.

This post brought to you by last year's disappointment at the impossibility of creating a spam-free comment system that is accessible from a text-only browser (and ignoring specialized solutions such as this interesting example).

I find the quality and design of wast majority of today's mobile phones appalling. I believe these devices are one of the best examples of wide-spread feature bloat. So, here's my idea for an ideal mobile phone (in hope someone from the industry will actually read this):

Hardware

• A durable casing that will survive a fall or two without breaking apart.
• Clamshell design: mobile phones are made for talking. I think the most intuitive way of answering a call is to open the flip, not searching for the right key to press (in a hurry I often happen to press the wrong key). Also with this design the positions of the microphone and earpiece allow for better voice quality.
• Monochrome LCD display: I don't care about colorful menus or a true-color video of a sheep to say "Hello" to me when I turn it on. On the other hand I do want to be able to read the display comfortably in sunlight. Monochrome displays also consume less power.
• No cameras, hard drives, GPS, flashing lights or other nonsense. Your making a telephone not some mixture of all of today's popular electronics.
• Bluetooth for communication with a personal computer and other devices (like wireless headsets). Infrared is history. So are the serial and parallel ports.

Software

• There are exactly four features to be implemented: voice calls, data calls (in combination with a Bluetooth connected computer), short messages and an address book. A calendar is also acceptable (I personally find a paper calendar superior to any electronic alternative, but many people I know use this function). I don't need games, ring tone composers, photo editors and other such stuff. Most people I know don't know (or don't want to learn) how to operate their WAP browsers and many don't know what a MMS is.
• Don't write everything from scratch for each new phone. Have an operating system that is stable and is optimized for the limited system resources of a mobile phone. This way each release of the software will have less bugs (I have a feeling it's exactly the opposite today - each new phone seems to have more bugs). Don't use stuff like Windows CE or Linux (it's a mobile phone Jim, not a laptop)
• Use a big, friendly font on the display. From time to time I actually read the contents of the display (I've seen a phone display tiny dark blue text on a light blue background). You can make it look good and make it usable. Ever heard of something called usability?
• Stick to standards when communicating with other equipment. AT commands were invented for a purpose. Don't reinvent the wheel and make a Windows-only driver for it just because you're lazy and you didn't do your homework. Bluetooth implementations are notorious today for incompatibility because nobody sticks to the standard.
• Have I mentioned reliability? Dropped connections, software lock-ups, erased address books, garbled messages, etc. are daily occurrences. Since it's happening to everyone almost nobody is complaining. The standard practice today seems to be to ship a product with half-finished software, release two or three patches for most obvious bugs during the production time and forget about it when a new model comes on the market. Spend more time writing quality software instead of adding a hundred new features.
• Don't delete every piece of documentation and software about a model the minute after a new model comes to market. Some people buy used phones and they like to still get user's manuals and software updates from your web page even after you stop selling this particular product. Are you really that short on disk space on your web servers?

For a while I was hoping that at least Apple will fix some of these problems with their iPhone (judging by how well they designed iPods). But now more I'm reading about it, more it looks that Apples product will be just as feature-bloated as everyone else's (it will perhaps just look good on the outside).

Judging by the abstract art my printer sometimes makes I guess it already passes the Turing test.

In reference to yesterday's late-night discussion, Harry Potter seems to be around 8200 times more popular than the Slovenian classic novel Deseti brat (according to the number of hits on Google).

Dear Lazyweb

Can you make a PVM3 compatible library that would:

• Communicate over TCP instead of UDP,
• use strong authentication and encryption and
• would tolerate large roundtrip times and packet loss.

Bonus points if it uses HTTP requests to be more firewall-resistant.

Ordinary PVM is completely useless over large, insecure and slow networks like the Internet. Also a standard library like that would simplify large distributed computing projects where nodes are scattered all over the world.

Thanks.

Recent news make me think that Wickel's program might need to be patched:

 
--- nuke/nuke.c 1997-10-01 12:27:27.000000000 +0200
+++ nuke-2006/nuke.c    2006-02-07 16:37:12.000000000 +0100
@@ -11,7 +11,7 @@
 #include <sys/time.h>
 #include <unistd.h>

-#define WALD 20  /* the Wald Number. */
+#define WALD 30  /* the Wald Number. */

 main ( )
 {

This happens if you try to compress a picture with Ogg Vorbis.

Original picture:

Same picture after compression (highest quality) and decompression:

Original picture:

After compression and decompression:

I think this gives a whole new meaning to the phrase lossy compression.

Here is the shell script I used to make these pictures.

Update: This was not meant to be a serious experiment. I was just curious what would I get if I would try to compress something that is not audio with an audio codec. I did expect pictures to look bad, however I was surprized at just how much a specialized lossy compression sucks for arbitrary data. I mean I didn't expect to just get static - there are some similarities between audio and image compression after all.

Toner transfer etching looks simpler and cheaper than the photoresist method I've been using recently. I have to try it some day. (found via hackaday.com)

Let us say that on average I receive N emails per day, where N is a relatively large number, say 80 or so. On average I manage to read only a part of that quantity of emails, say kN, where k is usually much less than 1. The rest remains unread in my inbox. Since Murphy's law says that those unread messages are the most urgent and the senders of those emails will get upset because I didn't read them, they will re-send them the next day.

So after the first day I have x₀ = N - kN = N(1-k) emails in my inbox. After the second day I'll have x₁ = 2 x₀ + N(1-k) = 2 N(1-k) + N(1-k) = 3 N(1-k) and after the third day I'll have x₂ = 2 x₁ + N(1-k) = 7 N(1-k).

If we substitute W=N(1-k) and write a recursive formula for the number of emails in my inbox on the ith day we get the following result: x_i=2 x_i-1 + W. It can then be proved that the non-recursive formula for x_i is x_i=W (2⁽ⁱ⁺¹⁾-1).

The highest estimate for the number of atoms in the universe today (including possible dark matter) is somewhere around 10⁸¹. A simple calculation shows that for a very optimistic value of k=0.6, the number of stored emails on my inbox will rise above the number of atoms in the universe in n days, where n is roughly equal to (log₂ (10⁸¹ / N(1-k) + 1) - 1 = 266.4.

If we apply the anthropic principle to this result, we arrive to the conclusion that the universe must be rapidly expanding. In the other case all existing atoms in the cosmos would be used for storing emails and none would be left to form carbon-based human beings which could then argue about cosmology and full inboxes. However if we disregard the anthropic principle we can arrive at a different conclusion with much more serious consequences. If the flow of emails will not stop until August 2006 the universe as we know it will cease to exist when it will no longer be capable of archiving arriving emails.

Acknowledgements

I would like to thank Tina for a very interesting and deeply philosophical discussion we had a few hours ago that led me to the conclusions written above. I would also like to thank all CS students who need help writing various GA projects and several high-volume mailing list for providing crucial statistical data for this research. And no, the number of unread emails that have accumulated recently in my inbox had absolutely nothing to do with this line of thoughts.

how much I love to play with Povray and Inkscape?

Idea for this image was shamelessly stolen from this very nice GNOME splash screen by Stephan Aleman.