How to build a Do-It-Yourself beamer

Nowadays, everybody has a home theater. Most people pay lots of money and don’t have fun. We paid almost no money (300 €) and had lots of fun.

Signal source:

1. Get an old and silent computer on eBay. VGA is enough. We got a HP Vectra VL400.
2. Get a good and old PCI  sound card with 4.1 or 6.1 with proper Linux driver support. We got an SB Live!
3. Use a VDR distribution like easyVDR, assuming you also want to watch DVB or simply use mplayer on the console with the frame buffer.
4. Assuming you use VDR, hack FBTV to center your image on the framebuffer and do deinterlacing [patchset found via google]. Ensure that you have a 1:1 mapping between signal source (PAL TV or anamorphic DVDs in my case), and the screen pixels.

Video:

1. Get an old overhead projector, 4000 ANSI lumen or more. Mine is a 3M 1750 with suboptimal but cheap halogen lamps.
2. Get an old robust TFT monitor, and remove the panel from the electronics. Mine is a EIZO L365.
3. Build a mask from cardboard in adequate size and put it on the OHP
4. Build two parallel spacers from wood and put them between the cardborad and the TFT
5. Get a tangential fan that can be built into a slot, and put it from the side between the panel and the OHP
6. Get a cheap used but quality projection canvas. Don’t use eBay, usually they are to expensive. In Germany, you can use quoka.de to find cheap ones. We got a Stumpfl AV 1:1 4 m^2. If you don’t find any, build it yourself. The most important thing would be a planar framing, and a proper canvas. In Central Europe, I can recommend boesner.com for the frame, and gerriets.de for a molleton base layer followed by a reflective foil layer.

Audio:

1. Get an old but very good and defective audio amplifier on eBay. The Grundig V5000 is amazing, really! For 4.1 or 6.1, you’ll need two or three of them because in the 80s, they “just” needed Stereo.
2. Know somebody with adequate electronic skills for repairing it, or repair it yourself.

Now: Have fun! A classical 80/20 solution: (even less than) 20% of the (financial) complexity and 80% of the optimum result - achievable with 10000 € or more.

Possibly related:

How to reconstruct broken mechanical components from some random hardware

1. Be upset that knob X or handle Y is not produced or shipped anymore by any support in the world
2. Find a skillful model building company which does prototype development - so they make also small batches (say, 1)
3. Use a CAD tool like CATIA, and construct the mechanical component on your computer. Use a (digital) sliding caliper, and work at least to 1/10 mm.
4. Give the CAD construction to the model builders who have CNCs or do rapid prototyping for you.

Now: Be totally happy that you got your component!

I hope this animated everybody who totally focused on software to also consider hardware recompilation. It’s fun, really :).

I read up on the history of the ancient convention that 1024 Bytes are called 1 Kilobyte. The problem with the convention is that it’s totally unintuitive unless you know it.

Unfortunately, Microsoft decided to use the following conventions and now the whole world uses it:

• 1 KB = 1024 Bytes
• 1 MB = 1024 * 1024 Bytes
• 1 GB = 1024 * 1024 * 1024 Bytes.

Basically, that is a mish-mash of the ancient 70s convention of using kB for 1000 Bytes and KB for 1024 Bytes, and an abuse of the SI definitions of M and G prefixes. Actually, there is no mB or gB convention, although that would have been logic in the original convention. This is due to the fact that in the 70s - the age of large and expensive computers -, nobody believed that mass storage would actually be achievable at all.

Just assume you never used a computer, ancient UNIX tools or listened to a computer science lecture, or were taught anything about computers. Wouldn’t you expect that

• 1 KB = 1000 Bytes
• 1 MB = 1000 * 1000 Bytes
• 1 GB = 1000 * 1000 * 1000 Bytes?

I filed a bug report against glib, with an historical analysis of the usage of all conventions and formalized nomenclatures in existence (slightly wrong) demanding that g_format_size_for_display() uses the latter conventions. This actually matches IEC recommendations.

One important side-effect of the conventions are:

• K=1000: Memory sticks and main memory cells are made in powers-of-two - because the address line uses binary logic (i.e. powers-of-two). Historically, their size is advertized with K=1024 to get nice, non-fractional values. Below the 1 GB limit, they were probably advertized with kB rather than KB - but that shouldn’t be relevant anymore. With K=1000, on your computer screen memory (and memory sticks) shows up LARGER than advertized.
• K=1024: Hard disks do not have such cell architectures, and they are advertized with K=1000. It was some kind of marketing trick in the very beginning, making the disk look larger than you expect, when you set K=1024 as old-fashioned “IT geek”. The effect is that with K=1024, on your computer screen hard disks look SMALLER than advertized.

Compare for yourself: Which of the two statements is positive, psychologically:

• In contrast to Windows, under Linux my 70 GB hard disk has 70 GB as advertized, and my 1 GB memory sticks grow to 1,07 GB
• Like under Windows, under Linux my 70 GB hard disk shrinks to 65,1 GB and my 1 GB memory sticks have 1 GB as advertized

Wouldn’t it also be nice to have a 100 MB file with 100 * 1000 Kilobytes? No more calculator I/O or right-clicking required for estimating the “actual” size in byte units!

I am mostly writing this blog entry to get some feedback from our users, rather than from programmers. Please also mention your background in your blog comments! Further concrete information regarding historic conventions and IEC and SI standards is available in the bug report mentioned above.

Also note that I do NOT demand to use the additional odd KiBi, MiBi, GiBi IEC convention that in fact make the current situation worse by using prefixes nobody knows, still defining Ki = 1024. My guess is that it was just introduced for offering an alternative for traditionalists who probably wanted “some convention with the beloved 1024”. But it is a non-traditional measurement prefix for a traditional concept, which makes it unattractive both for old(-fashioned) traditionalists and young pragmatists.

Update

I removed the possibly intimidating roundhouse kicks against IT community, and somewhat out-of-context IRC log excerpts. Sorry if anybody felt insulted - some certainly did. You can find an interesting collection of opinions and personal backgrounds in the blog comments.

Since everybody nowadays comments on the future of GNOME/GTK+, I’d also like to add my two cents - although more briefly than others.

In short, I think we’ve reached our objectives and should polish GNOME 2 ’til doomsday.

3.0? No!

As of writing, I see no reason for delivering a (long-term) API/ABI-incompatible GNOME 3.0 or GTK+ 3.0, and many have written the same before. I’m just repeating it here to make sure that everybody, including the kind-hearted individuals who try to force a GSEAL’ed GTK+ to make it more clean, are aware of the massive opposition against this plan.

C is ugly as hell and does not support public/procted/private classes. Therefore, no C programmer can really mind ugly exposed internals. Adding setters and getters is a in principle a good idea, but there is no reason to break working applications that access data exposed in GTK+ structs. Maybe a GSEAL() fan could tell me how third-party subclasses that are derived from GTK+ stock widgets can access protected member variables? If you just expose getter/setter functions, everybody can access the internals, and you could have put it into the object’s struct anyway.

Status Quo: Conservative + Boring

The current GNOME and GTK+ development clearly “stalls” or “stagnates”. From the point of a developer this sounds horrible. However, you could also formulate that positively and call it “solid”. We’ve come a long way. Since GNOME 2.0, our target was to deliver a non-obtrusive, simple and useful desktop environment. We’ve done our best, and people love it. I know many people who use GNOME because it’s simple and clean.

Radical Concepts => New Project

We created a successful brand by radically sticking to one strategy: Simplicity. The current traditional desktop approach without any fancy database concepts is very successful and is used by many people.

The brand will be damaged if we throw in half-baked complex interaction concepts. Like many of you my dear readers, I love the idea to use the computer as a personal assistant or secretary, and I’ve also thought how it could work in such a scenario. However, at least radical concepts (“GNOME Online Desktop”, “everything is organized as database”, etc.) should clearly be put forward outside the GNOME project, at least until they are mature and proven in a testing environment with average people instead of “innovation” fanboys. “Innovation”, after all, is just a buzzword, and in science they often just re-invent old concepts. I’m sure that the scientists among you will agree with this.

It may sound a bit disappointing that we’ve become conservative, but that’s the typical life cycle of people in western civilization, why shouldn’t it also apply to software projects with well-defined objectives?

I’d walk around and tell people to find more useful projects than wasting their time with adding tabs to each single GNOME application. Maybe the semmingly true rumors that one or another GNOME fellow might be somewhat lunatic (panties, anybody?) inspired theprogrammers who are implementing this.

One initial aspect: Calumn is totally right that tab implementations at application level are an effect of the lack of platform MDI support. We implement it at application level where we need solutions today and tomorrow, rather than the day after tomorrow. However, it is not yet clear whether tabs are useful at all for 90% of the applications.

Why tabs for Nautilus (and web browsers, spreadsheet, …) are a good idea

Let me briefly explain why I added tab support to Nautilus: It helps people with their workflow. Today, I used it to tidy up my document folders. I could use it to navigate between file operation source and destination folders extremely quickly, using the keyboard and ctrl-x, ctrl-v, and ctrl-page-up/down. I was two times as fast as with a console (where you need auto-completion), and five times as fast as with a mouse

Tab support for browser-like file managers is a good idea, because people know how to use the tab concept properly since it has been invented for web browser. It is also useful for spreadsheets, where you often compare multiple documents and calculations. It is also useful for having multiple conversations at once, because each of them is linear, and you can use the tabs to switch between losely-associated linear tasks or documents.

Why tabs for media players are a bad idea

On the other hand, tab support in Totem is ridiculous. Somebody must have put LSD into the GUADEC social event food, and everybody now feels like Syd Barrett and his Lucifer Cat!

Regarding Totem: It is already perfectly doing what it should do: Play a song or video, and let me queue more of them. One song or video at once. How can I watch two videos at once?

Why you should think first, and implement features afterwards (i.e. gcalctool tabs)!

Let me exemplify this regarding gcalctool:

Even my non-programmable pocket calculator (Casio FX-991ES) has more features than this non-noticeable desktop calculator. Amongst others, it can not deal with symbolic calculations, complex numbers, nature constants, variables. It does not even have a calculation history as I mentioned in a comment in Scott James’ blog. This is a shame! Before you implement such a craptastic feature, think about how it will be used! Again: gcalctool does not have any calculation history. This is as if I implemented tabs in Nautilus without implementing the back/forward button before, so you had to switch to a new tab each time you want to display a new folder.

Now I’ll do something useful and learn for my function theory exam.

You talented developers at GUADEC should also do something useful and fix the GTK+ tree view mouse interaction.

All-Clear :o)

It turns out that the tab implementations were just mockups. Have fun at GUADEC!