Multiple Concurrent Linux Distributions in Debian Squeeze

Ted Dziuba inspired me to try installing multiple concurrent Linux distributions inside of an existing distribution.  This is really handy for testing.  Go try it (it won't take long).  It's really awesome!

Ted's instructions are rather minimal, although are a great place to start.  I also found the Debian Wiki - Debootstrap page to be helpful.

In my case, I'm running Debian 6 squeeze on my desktop machine.  I've installed Debian 5 lenny and Ubuntu 10.04 lucid as chroot environments.  If after installing a Debian release, when running apt, you get errors about not being able to authenticate packages, make sure you run "apt-get update" first.  That will take care of it.

There's no "debian-minimal" package like there is for Ubuntu but (as root in the chroot environment) a quick "apt-get update && apt-get install aptitude sudo nano" got me to a place where installing the things I want is easy.

One thing to be careful of, your user is still your user inside the chroot environment and your home directory is still your home directory!  If you delete stuff in your home directory, it really will be gone, whereas if you delete / modify stuff (inside the chroot) from /etc and other system directories, it's only within the chroot.

If you'd like to use rinse to install RedHat based distributions that aren't included by default (no recent Fedoras are for Debian 6's version of rinse), take a look at the rinse Gitorious tree and grab the more up-to-date /etc/rinse/rinse.conf and *.packages files.  I'll be doing this shortly and I'll post a follow up after installing some RedHat distros.

See after the jump for list of commands I used to install both lenny and lucid...

sudo mkdir -pv /opt/chroot/lenny
sudo debootstrap --variant=buildd --arch amd64 \
 lenny /opt/chroot/lenny/ http://mirror.rit.edu/debian/
sudo mkdir -p /opt/chroot/lucid
sudo debootstrap --variant=buildd --arch amd64 \
 lucid /opt/chroot/lucid http://mirror.rit.edu/ubuntu/

Read More

Product Compliments & FPGAs, They Don't Get It!

The other day, I was reading Joel Spolsky's blog post about product compliments.  Joel states that, "Smart companies try to commoditize their products' compliments."  The compliments of a product are the other things that people buy with that product.  For example, operating systems and software compliment PC sales.  When you buy a PC, you'll also probably buy an operating system (even if it comes with the PC) and some software.  In this case, the software vendors want to sell you software, so it's their prerogative to make PCs into a commodity such that the price is as low as possible.  For the most part, this has happened.

One interesting side effect of thinking this way is you start to look at other companies and industries and notice how they're not doing this at all.  Like in FPGA land.  Really, there's the two big players: Altera and Xilinx.  Neither of them is trying to commoditize their products' compliments, and for what it's worth, I can't tell which product they sell is the product and which is the compliment.

With FPGAs you really need two things: the physical part and the software to realize a design.  In either case, both Altera and Xilinx will charge you.  You have to pay for the parts (which are really expensive if you buy them from online retailers like DigiKey but are much more reasonably priced direct or from distributors in volume) and you have to pay for the synthesis software!  Some will argue that you don't have to use just Altera's or Xilinx's synthesis software, other vendors will sell you software that will work, but that software isn't cheap either.  (For the companies selling just synthesis software, the physical chip is the commodity compliment, which kind of works, but not well enough.)

If you assume that Altera and Xilinx want to sell you physical chips, they should be driving the synthesis software to be a commodity and be low priced.  If they want to sell you software, they should be working to make their chips as commodity like as possible (easy to switch from one company's chips to the other).  But they aren't doing either of these things!
Yes, you can get free versions of Altera's and Xilinx's tools, but those tools are limited and "real" FPGA designers will probably need the full version of the tools.

So what's my point?
My point is the FPGA landscape is F'ed up.  They're missing out on gaining new customers who are very price conscious (like hobbyists or bootstrapped start-up companies) but need advanced features in the synthesis software.  There's going to be a huge market out there for hobbyist type development for FPGAs soon (if it hasn't started already) and both Altera and Xilinx are going to miss out on it.

I predict that as soon as there's an open source / free software program that can do decent FPGA synthesis, both Altera and Xilinx are going to feel the pain.  I also predict that one of those little FPGA companies are going to reap huge benefits, because they'll be the ones behind it.

Read More

Low Cost ARM Computer

I was thinking about my ARM + FPGA computer idea some more.  There's already a lot of competition in the single board computer space and adding just another entry there isn't really worthwhile on a small scale, the prices would just be too high to attract any users.  However, there's currently a rather small market for single board computer kits with free software like ideals.

What if the goals of the kit were to be a free hardware project?  By free hardware, I mean as close to open source / free software ideals as possible.  The specifications, schematics, BOM, layout, and manufacturing files would all be created using free software and available to everyone.  If you wanted to build your own version of the computer, you can either take the files and modify them and build one yourself, buy each component from the vendor of your choice, or buy pre-built models from a vendor.  Different vendors could compete with a commodity (the free hardware design kits) but also have the freedom to modify the kits to add extra functionality, reduce costs, or change things all together.  It'd be a reference design but with a free hardware spin.

Along with publishing the design of the hardware, there'd also be a book like Cross Linux From Scratch made specific for the released designs.  With the combination of free hardware and free documentation, it'd be an amazing teaching tool for people wanting to learn about embedded systems.

Currently, projects like the BeagleBoard offer some of their design files online for free, but you'll need expensive tools in order to edit them.  There are free software tools out there that are capable (gEDA) along with lower cost tools (Eagle).  If you want to attract hobbyists and very small companies to the embedded Linux market, using low cost or free software tools and providing high quality documentation is the way to go.

Read More

KDE4 Sucks

I upgraded to Debian 6 Squeeze last weekend on my desktop.  I was very excited to get some more up-to-date packages (git, gcc, kernel, and chromium) but I'm disappointed by KDE4.  Yes, I realize I'm a few years behind the rest of the world coming to this conclusion but that's the curse / blessing of Debian stable.

I had been using KDE3 in Lenny.  It did everything I wanted and generally kept out of my way.  KDE4 is completely different, in a very bad way.  My computer isn't slow, although it is 4 years old, but KDE4's out of the box configuration was way too laggy.

It's back to Gnome for me and I'm actually liking the configuration of it that comes with Squeeze.  It does what I need, was quick / easy to configure to my liking, and it gets out of my way.  That's how it should be.

Read More

Pick an ARM ABI When Building GCC

If you follow the CLFS embedded book for ARM, you'll see that your ABI choice isn't used until compiling packages (ie: after you've built a cross-GCC).  What you will also find is that if you want to use the aapcs-linux ABI (EABI) and you choose your target triplet to be arm-unknown-linux-uclibc (like the book says) that you'll have issues.

Your issues will begin with configuring e2fsprogs using the $BUILD variable and will look like this:
error: FPA is unsupported in the AAPCS

That's a very unhelpful error message. What you want it to tell you is why the heck the configure script decided to use FPA and AAPCS together if they obviously don't work.

What happened was you chose your target triplet to be a triplet that GCC's configure thinks uses the OABI, but now you're building some software and telling GCC to use the EABI. Rather than spit out "Hey, you built GCC with the OABI and now you're trying to use the EABI!" it just complains about FPA.

To solve this, if you plan to use the EABI, set your target triplet to be arm-unknown-linux-uclibcgnueabi. Then when you build GCC, pass it the --with-abi=aapcs-linux switch. This will produce a GCC that builds for the EABI.

This caused me quite a few hours of banging my head on my keyboard. The Buildroot people know this, and it's included in their build scripts, but searching Google was not very helpful.

Read More