We bought our new house just about a year ago. And in that time I’ve been settling in to the new garage – extra deep. Which has given me some more space for my woodworking tools and general organization. While still having room for cars.

The first step was some simple cabinets:

I used white laminated paneling for the faces of the doors which makes a handy place for labeling the contents.

I also installed some cheap florescent lighting right in front of the cabinets – giving me plenty of light for working, not for photography though.

The next step was some pegboard for organizing those frequently used hand tools to clear off my workbench… as you can see I’ve got a ways to go before the bench is completely clean.

There have been some other woodworking projects I’ve worked on recently – mainly a wood privacy fence from reclaimed wood. Which looks great… and keeps the dog in.

GRRR. ARGH! AVAST Ye SALTY UBUNTU!
Sorry, ‘talk like a pirate day’ has passed, today is ‘frustrated with Ubuntu + MythTV day’ — which is almost synonymous.

If you get this error:

bbieber@baddog:~/mythtv/mythtv$ /usr/local/bin/mythfrontend
/usr/local/bin/mythfrontend: error while loading shared libraries: libmythtv-0.20.so.0: cannot open shared object file: No such file or directory

Pretty simple to fix, create a configuration file for ld.so which tells the linker where to find your libs -
sudo nano /etc/ld.so.conf.d/mythtv.conf

Then add this one line to it:

/usr/local/lib

and run sudo ldconfig

Then you should be good to go.

I now have MythTV running the latest from SVN on Ubuntu, only now my Gentoo box has an older version.
Take my advice, if you ever build a mythtv setup with multiple frontends – use the same OS on all your machines.
My setup consists of one custom built 3.4GHz P4 HTPC in our living room with 2 Happauge PVR 150 capture cards (dual tuners), a 1.2GHz Celeron Compaq Evo frontend w/Streamzap IR in the bedroom, and my desktop which is a 2.8GHz P4 with a pcHDTV HD-5500.
Eh… the best way to visualize this is to flex my Open Office Draw skillz, er maybe not.
On my master backend I went with Gentoo because I was always modifying and compiling the drivers for my PVR 150 capture cards (evidently I was the second guy after Chris Kennedy to use the PVR150 in Linux)… only now Ubuntu lags behind so far, I had to switch from using the packages to SVN. Now of course, Ubuntu is using protocol version 36, and Gentoo is behind with version 35. GRR. I can never win.

Distributive designs are very important in large institutions – especially educational environments. Through two major design changes in 4 years, and a distributed design over a thousand of virtual hosts and 50+ servers I’ve learned a few things about creating a distributive web design which I thought I could share with the community. The challenges are many when distributing a web design which needs to work across many web servers and workstations utilizing different operating systems, but by following a few simple techniques you can simplify design upgrades and synchronization for your distributive web design.

Distributive designs are becoming more popular even as CSS combined with web standards takes hold within educational institutions. By abstracting the presentation from the content of your site, the visual appearance can be applied externally for small or drastic design changes. Through the use of Cascading Style Sheets (CSS), designers can make fluid design changes across an entire website – as long as this stylesheet files (and perhaps other files) are synchronized between all the servers.
The challenge is how to link to this common style. There are many methods of addressing files locally on the same server or externally on another server. I’ll step through the various linking methods and highlight some advantages and disadvantages of each.

“Why not use absolute addressing to one official copy of the CSS file?”
Such as: <link rel=”stylesheet” href=”http://www.example.com/officialsitestyle.css” />

This practice works well for small designs and close teams.

Advantages:

• Very simple to get running
• Easy to update
• Cached once

Disadvantages:

• Large designs will require more than just a CSS file (javascript, snippets of html etc)
• Creates notices of insecure items when accessed through https
• Some IDE’s will not render a design if the CSS is not locally referenced

“What about relative addressing?”
Such as: <link rel=”stylesheet” href=”officialsitestyle.css” />

Relative addressing works well for small sites all working at the same level.
Advantages:

• Simple to distribute
• Works in nearly all IDE’s
• Files can be previewed offline using file://

Disadvantages:

• Limited cache support
• Hard to synchronize many copies without symbolic links/aliases all over
• Leads to many duplicate copies on sites with a large vertical hierarchy

“What about site – root addressing?”
Such as: <link rel=”stylesheet” href=”/officialsitestyle.css” />
Advantages:

• Moderately cacheable (domain specific caching)
• Easy to distribute
• Each server only needs to maintain one copy

Disadvantages:

• Files can’t be previewed directly using file:// as the browser has no context of the site root

As you can see, each method has advantages and disadvantages. If you have a very small design style, and don’t have to worry about secure pages or can easily modify the css link to be secure, you should be fine with absolute linking to one file. Relative addressing works for small teams where communication is good, and you aren’t developing within a deep site hierarchy. The disadvantage is that it leads to many copies which doesn’t work well for pushing out updates.

In our workshop, we use site-root relative addressing, meaning the files are all referenced from the site root so each server just maintains one copy. To overcome the disadvantage I noted, Dreamweaver 9 can generate a temporary file with the content of the referenced CSS files – which fixes that issue.

Site-root addressing works the best for our distributive web design, it may not work for you, but I hope this gives users some advice about the differences when they choose a path to head down. Keep in mind the technical challenges related to updates – keeping many servers in sync can be a difficult task. Expect a post on synchronization when I get around to it.