Project Initialization

After looking around for a long time for a good parent theme to make constructing WordPress themes easier, I finally realized that what I needed wasn’t a good parent theme, but rather a clean theme template that I could use as a foundation.

Currently in design phase, it doesn’t contain much HTML but rather contains a basic set of theme files, pre-filled with commonly used tags as well as a basic Loop.

The goal would be to use these files as a template, filling in HTML to construct elements and adding CSS to style it.

A reset CSS file is included (it is just Eric Meyer’s) for ease of use, but is not linked.

The template, bundled as a WordPress theme, can be downloaded with this link, or if you use SVN you can grab it at this link.

Note: This is not a Parent/Child usable theme, it is a template (a core set of files) for use when developing new themes.

Sermon Browser Rewrite

I’ve been in the process of designing a new website for the church I attend, the front-end interface has been needing an update for quite some time, here’s a screenshot of the old site:

The current method of adding sermons is rather tedious: You upload a sermon, then you rewrite the front page (it’s static) to link to the new sermon, then you modify the (static) page that lists the sermons by date for the year (each year’s list is static) and then add the sermon to a list of sermons by category (also static).

Because of the difficulty to add a sermon, it’s no wonder that the RSS and podcasting feeds are broken.

While doing some research, I found WordPress to be a very easy way to make a new site, especially since I found a Sermon Browser plugin!

Sadly, however, the Sermon Browser plugin has two significant flaws: 1) You can’t search sermons from the built in WordPress search, and 2) the plugin hasn’t been worked on in over a year.

I decided to use the plugin anyway, but decided that I would rewrite the plugin to use the totally awesome functionality found in WordPress 3.0 which should be released later this month.

One of the cool things about WordPress 3.0 is being able to register a new “post type”, which (for the purposes of this discussion) means that each sermon can now be a post. This means the information about the sermon can be stored and managed by WordPress, instead of needing extra database tables and needing extra functionality like in the current Sermon Browser plugin.

I already have the basic core of the plugin coded, and I’ve only spent a couple hours on it. Given my coding skill ( low) this should mostly tell you how awesome WordPress 3.0 is, since it makes such things so much easier.

Also, I think that writing this plugin will be my first major contribution to the internets.

Computer operating system: Layers.

I have mentioned before my love of Linux, and I’ll mention it again: I love Linux. There are so many things about every operating system that I could complain about and Linux is no exception, but overall I love working in Linux more than any other operating system I’ve used. Using Linux doesn’t come without a cost, however.

For some the problem is that bleeding-edge hardware is not usually supported right away. Although the blame for this rests on the hardware designers and not the operating system designers, this is definitely still a valid problem. Companies should write drivers for Linux systems, and I imagine this will be more common as the popularity of Linux (mostly via Ubuntu) increases.

For others (I am in this group) the problem is software: The software that you want to run is not runnable in Linux. For some people this can be solved by switching to different software, but for many people this isn’t a valid option. I am in the second group of people: I need to run SolidWorks and AutoCAD, two programs that are almost exclusively Windows based (AutoCAD is “available” in Mac). There is work being done on a Linux program which would allow a person to run Windows software on it (called WINE), but it’s a little slow to develop and often hard to get working. The other option is virtualization.

Computers today are so powerful that, if desired, you could let multiple users log in to a single computer. You’d have to get multiple screens/keyboards/etc. of course, but still. In fact, it is becoming increasingly common to run a virtual computer inside the current computer: Most Mac users do this so they can get at some bit of Windows software, and the same goes for Linux users. In my own computer use, I usually reboot into the operating system that I want to do work on–Windows for 3D modeling, and Linux for everything else.

I can install Windows on a virtual computer, but then I have a processor intensive operating system running a virtual operating system (also power hungry) running 3D modeling software (also very power hungry). This combination isn’t very good: Everybody wants a slice of the pie, but there isn’t enough pie to go around. To counter this problem, I have developed this scheme which I will implement to my computer:

The core OS is as minimal as possible while providing full hardware support. This core OS doesn’t even have a “real” window manager, and it doesn’t get interacted with. On top of this core OS are the actual working desktops, each one being a virtual computer.

One virtual computer acts as the main visible desktop–things like music and video playing, blogging, etc., go here.

There are multiple other desktops, each functioning as a development platform. One for 3D modeling (i.e., Windows), one for web development, one for software development, one for OS development. There could even be multiples of each type.

The result is that practically every development area has it’s own operating system, each of them at the same “depth”. This would essentially be like running an X server and each window client being a virtual computer. Here’s the plan:

Core OS: Debian + ratpoison (modified) + QEMU

Main Desktop OS: Debian + Fluxbox

Web Development OS: Debian + Fluxbox + Firefox + text editor + SQL editor

3D Modeling OS: TinyXP + SolidWorks

Drafting OS: TinyXP + AutoCAD

Etcetera.

I want to save the state of a virtual machine and be able to fork that machine. Saving the state would make the startup time of a machine minimal, and forking makes it possible to always start a fresh operating system. However, this means that all preferences and files can’t be saved in the machine. The goal is to get a virtual computer set up exactly how I want it to be at startup, and save that state: No matter how I shut that virtual machine down, it always starts in the ideal way. If this can be achieved, and if initialization time could be cut down, I have some pretty neat tricks I could do.

I’ll be working on this idea for a while, I am not sure how hard it will be…

Propagation of copper crystals from a gaseous phase

I’ve been thinking for quite some time now about a cheaper way to print/produce PCB circuits (the printed circuits that you see in electronics), and I’ve come up with several ways to do it that are pretty helpful. Maybe I’ll share those later, but I didn’t like them because of certain inherent difficulties, some thing that it did was costly or time consuming, usually.

Today I’ve been thinking the problem over some more, and came up with this idea that I’ll share here. Note that I don’t call it a solution–it is complicated and likely too costly to produce, but it is a unique way to create circuit boards.

Here is the rough idea: Take copper as a solid, turn it into a gaseous (I’ll call the verb “gassify”) phase, and get it to attract and deposit itself to the circuit board. Why gaseous phase? Why not? (It has some benefits, as I’ll show later)

To gassify the copper, we’ll need to disassociate the copper atoms. The energy required to do this is large, but not prohibitivly. What is prohibitive is the heat generated: If the copper is gassified near the circuit board using electrical conduction/resistance to heat it, it will have thermal radiation which will overheat the circuit board very quickly. I propose to use a wire-feed system (like what is found in welders) which pushes a thin copper wire into a laser beam. Because of the low mass of the copper, and because the heat is point applied, the thermal radiation will be negligible and the copper can be gassified locally. By locally I mean that the copper can be gassified near the point of deposition on the board, as opposed to a system which requires a chamber to be filled with pressurized gassified copper, for example. Also, if the copper can be brought close enough to the circuit board, it may be possible to use an inert gas as shielding, so that the chamber would not need to be evacuated to prevent instant oxidization of the copper.

That first part is “simple”, comparatively. The hard part is trying to get the gassified copper atoms to deposit themselves where they are wanted. If the whole board is made electrostatically opposite the charge of the gassified copper, for example, it would deposit in a thin film across the whole board, which would not be very helpful. I was thinking of many possible solutions to this problem,. but one which came to mind was that the circuit board could be printed on, using a common inkjet ink (hopefully, but this will need to be explored), to dope the surface. When the circuit board is electrostatically charged, the gassified copper would deposit on the places where there is no ink.

Another problem might be the deposition of copper would be too thin. While this may be solveable by way of continuing deposition of gas, I think this has the potential to be difficult. However, the main concern I have is the grain boundary of the deposited copper:

One way of producing fine grained diamonds is to have an evacuated chamber, introduce a carbon dust, and hit the chamber with microwaves. This liquifies the carbon dust, and causes deposits of solidified carbon crystal (diamond) to deposit on the surface of the chamber–usually a single surface is prepared in such a manner that the carbon only deposits in that location. The difficulty here is that, while the individual diamond crystals can grow by way of additional deposition of carbon atoms, if the individual crystals touch, I do not think they can easily join to become a single crystal: Between the two a grain boundary develops.

Granted, this was research that I read over two years ago, so I could be wrong, and the crystals could join without grain boundaries. But I think the same problem would occur within the gassified copper system: As a circuit element is traced, it would likely deposit copper in a single crystal, which is good(ish), but when you trace an element to join it to an existing trace, I would guess that a grain boundary would occur at that point, which might be a problem.

There’s a few guys/teachers at the school that I will talk to about this, once I figure out the right questions to ask.

The hydrostat Baja runs

I’ve been helping the Mini Baja team at school with a research project: We want to see if we can get the Baja to run using hydrostat motors instead of a geared transmission. That would save us the problem of stripped gears and broken CV shafts. Two other students (Mary and Ryan) and myself worked on this for quite a while, and we finally got it put together correctly, and took it outside to run it around.

Unfortunately the top speed is pretty low, and the torque is surprisingly limited. The motors can be adjusted, so we aren’t bothered by the initial results. Ryan estimates (by running next to it while it’s driving) that it probably drives at 10 mph at top speed, so hopefully by adjusting the motors we can get it up to 35 mph for next years car. Here are some pictures of the car:

Side view of the Baja

Front view of the Baja

Mary in the Baja

We saw a smart car in the parking lot

The Baja is about an inch or so taller, and has bigger back tires

These are the hydrostat motors

The other guys are inside working on final assembly of this years Baja, which they will take to the competitions. Here are some pictures of it:

This years Baja

Back end, this one uses a normal transmission (not installed)

The front assembly, showing the brakes and such

Royce standing next to new Baja, to show scale

This years Baja is much smaller than the hydrostat Baja that I am helping with, which was last years model (using a normal transmission). Finally, a picture of our school colors, painted onto the new Baja:

Nebraska Engineering

Installing Debian on the Zipit Z2

This is the first post about installing different OSs on the Zipit Z2. I’ll be posting more as I work on getting a good OS on it, and modifying things to work better. Later on, after I finish some research, I will put together a more complete guide on how to get things running well. Until then:

What it is:

The Zipit Z2 has an internal wifi and a color screen, making it a fun little toy to hack around on. It’s resources are limited—32MB of RAM, and 8MB of flash, with a 300 ish MHz processor—so you aren’t going to be able to run Windows 7 or Ubuntu. Most people install Debian with a very minimal setup, and install Fluxbox, which is a super lightweight GUI (the “desktop” interface).

The Idea:

The Zipit has a minimal operating system installed, a Linux derivative apparently. While it would be nice to put a full operating system on the internal memory, since it is apparently 8MB it won’t hold much of interest. Instead, the idea is to replace the installed bootloader with a different version which will actually allow us to boot from a mini/micro SD card. With this plan, we can plug in a mini/micro SD card of reasonable size and run an OS from there. Doing this from another Linux computer is much easier, so if you have one you should do it that way. I’m going to show the directions from Ubuntu, but the directions should stand for any version of Linux with gParted. If you don’t have a Unix/Linux system installed, you can always install Wubi (it’s a temporary Linux install to the hard-drive) or boot from a thumbdrive.