This is part of a series of posts going through The Elements of Computing Systems. This post covers section 1.2, the specification of a typical set of gates, which will be built on top of later.

We’ll be starting with a Nand gate, and deriving all other gates from it.

Every once in a while I hear people talking about how they’d like to have some useful product, but can’t afford it. Sometimes they complain about how they can’t afford it. Sometimes, very rarely, this is legitimate.

We live in a time where the knowledge necessary to do almost anything is at our fingertips. Can’t afford new shelves? They’re easy to rig up – even some rope, eyelet screws, and wood will do the trick if it needs to.

Can’t afford a projector? If you can get your hands on a transparency projector from a school that’s getting rid of them, or from freecycle or craigslist or similar, you can get a LED screen with a busted backlight off of ebay for very cheap and have yourself a functioning projector in little time.

People seem to make the assumption that they aren’t capable of doing things themselves, and the reasons that people do that are myriad. I’m of the opinion that a lot of it stems from people being surrounded from birth by a culture that promotes consumerism as solution, but that’s a can of worms that would be a better fit for another post.

Making your own stuff is incredibly rewarding. We’re a species that depends on pattern-matching for survival, doing things makes us better at doing things. Anytime you try to acquire a new skill, there will be a period of frustration at the beginning before things “click”. It’s often touted that ten thousand hours of practice at something will make someone a master at that, and the few actual attempts at that have had great results. It takes much, much less time to gain a basic level of competence.

As an example, I taught myself to juggle a few years ago. It took three days of practice for me to be able to do the most basic three-ball cascade. Once I got that down, it became much easier to start learning more complex tricks, and although I haven’t been practicing regularly for a while now, I can still throw a three-ball cascade with ease.

The point of all this is that if you wish you had something, sit down, figure out a way that could potentially provide that something, and then create it. Rinse, repeat.

It’s the most empowering thing I know of, and it’s never been easier to be empowered. We can do amazing things, humanity. We’ve done amazing things. Let’s do more.

This is part of a series of posts going through The Elements of Computing Systems. This post covers the background section of the first chapter, which is about Boolean Logic.

This starts a series of posts that will follow my progress while reading The Elements of Computing Systems, which so far seems like a very excellent book. I’ll be taking notes as I go along and doing the exercises.

I’m posting these partially as a motivator for myself to finish the book in entirety, and just in case someone finds them useful.

Anyhow, on to the start of the runthrough. This post just covers the introductory material.

A few days ago, I posted a link to reddit about the “Customized Linux” project I’m trying to get funded. It generated quite a bit of discussion, which you are, of course, free to read through if you’re so inclined.

One thing that became clear was that I really needed to clarify just what exactly it is that I want this project to be and why the existing tools that let people customize Linux ISOs don’t cut it. I posted a short attempt at clarification, but for one it still wasn’t clear at the level that it needed to be, and for two I didn’t even really get a very solid phrasing of the idea in my head until a few hours after I had posted it.

I’m hoping that this post will provide a clear and understandable overview of what I’d like to accomplish. We’ll start by taking a look at what the problems I’d like to solve are, and then take a look at why existing tools that have similar functionality aren’t solving those problems. We’ll wrap up with a bit of exposition on how we can go about creating good solutions for those problems.

From a small bit of discussion on Hacker News and reddit, I thought it would be a good idea to extrapolate a bit on what the differences are between what I’m trying to do with my project for generating custom linux images and existing tools like SUSE Studio and woof. In short, what I’m trying to build has a very focused scope, and aims to provide a service to people who may not even know basic things about Linux.

The project I’m trying to launch has a much more limited scope than a tool like SUSE Studio – I’m trying to focus on making it easy for individual users to have access to the setup they use on a daily basis, on their personal machines. SUSE Studio is a well-polished tool, but puts a lot of stuff in your face by default that the type of user I’m targeting might not know the first thing about.

The focus, interface-wise, in my tool is going to be on applications and user data. While I do plan on allowing people to tweak things at as fine-grained of a level as they want to, I really want to avoid overwhelming less-technical users with the potential complexity of everything that can go into a distro.

Tools like woof and other existing scripts for generating ISOs require a fair amount of knowledge from the end-user. I want to provide something that allows people to spec everything out if they want to, but will by default provide them with the software they use in a live environment, and after a fresh install, even if they are close to entirely ignorant of what’s going on. This includes doing things like providing a sane partitioning scheme by default, making sure that the live and installed environments are the same in the ways that matter, and setting things up in such a way that it’s possible for people to create the environment they want even if they don’t even know what a package manager is

I’m trying to build something that’s usable by people who aren’t even close to being Linux gurus. Ideally, I’m trying to build something that’s usable by people who don’t know the difference between a web-browser and a bootloader.

One of the reasons that I decided to attempt to maintain aif was because it’s very relevant to something I’ve wanted to do for a long time – make it easy to create customized Linux live and install images that have the setup you want available in the live environment and immediately after a fresh install.

While I’m capable of accomplishing that from a technical standpoint, I can’t currently afford much of anything, let alone the hosting costs associated with creating and serving install images – it’s intensive in terms of CPU use, memory, and network usage.

I decided to try to start a kickstarter for funding the project. I spent a good amount of time reviewing their project guidelines, and figuring out how to take a decent video of both myself talking, and of a proof-of-concept app doing it’s thing. When I went to submit it for review, I had sent out a preview link to quite a few people, and gotten nothing but positive feedback.

To my surprise, my submission was declined, and the reason given was what looked like a simple form letter saying that I wasn’t within their project guidelines. Kickstarter allows you to appeal for re-approval, which I did, but they only allow you 500 characters with which to do so, a bit on the short end if you don’t provide any feedback as to why a submission is declined.

After submitting the appeal, I received the same form letter back. Exactly the same.

It’s a bit aggravating – I can see how my project would have not been considered the type of thing that kickstarter is for, but if I was being denied on a whim, I would have preferred that to be stated explicitly. As it is, it’s not hard at all to browse through successfully funded projects that are either in blatant violation of one of their “project guidelines”, or that are at least as interpretable as such as mine was.

Back in 2011, Patrick McKenzie gave a talk at Google called What Engineers Don’t Know We Don’t Know About Online Marketing, where he brought up how incredibly bad the support from Google was when someone’s AdWords account would be suspended, and how it was really, really in their best interests to do something about that. I hope Kickstarter starts providing more (or any) feedback to people they deny submissions from at some point, but I suppose we’ll just have to wait and see.

In any case, I’ve since taken what would have been my kickstarter campaign, and started it at indiegogo. Take a look at it if you’re so inclined, or show it to your neckbeard friends. I’d really like to bring the idea to fruition.

I’ve spent the last couple of days setting up a development environment for working on AIF. In this post, I’m going to walk you through the setup I came up with. If you have any suggestions, please let me know – some of this involves stuff that I’m not incredibly well-versed in.

Prerequisites

First off, I’m assuming you’re working on a machine running arch. You’ll also need a copy of the latest install media and git, if you don’t already have that installed.

You’ll need to have a local checkout of both AIF and libui-sh, a dependency of AIF:

1
2

$ git clone https://github.com/jdodds/aif
$ git clone https://github.com/Dieterbe/libui-sh

Setting Up a VM

I’m using qemu. As far as I can tell, you should too. The setup required is quite a bit more involved than the setup for (for example) virtualbox, but it’s a much more suited tool for what we need to do.

Install qemu:

1

# pacman -S qemu

The first thing you’ll need to do is create a disk image for qemu to use:

1

qemu-img create -f qcow2 ~/vms/aif-testing/base.qcow2 8G

If your machine supports kvm, you’ll want to load both the kvm and either the kvm-intel or kvm-amd kernel modules:

1

# modprobe kvm && modprobe kvm-intel

You’ll probably want to stick those in MODULES in /etc/rc.conf. You’ll also want to add yourself to the kvm group:

1

# usermod -a -G kvm $USERNAME

And then either re-login or run su - in your terminal emulator of choice.

Now we should be able to start arch in our vm. I use a simple script:

1
2
3
4
5
6
7
8
9
10

#!/usr/bin/env sh

qemu-system-x86_64 \
    -enable-kvm \
    -cdrom ~/isos/archlinux-2012.08.04-dual.iso \
    -boot order=d \
    -daemonize \
    -m 2G \
    -k en-us \
    ~/vms/aif-testing/base.qcow2

Stick the above somewhere in $PATH and run it, and you should see something like this:

Press Ctrl-Alt-Shift-2 to get to qemu’s “monitor”. You can do a lot of stuff from here, but for now you should at least know that:

• quit quits
• savevm foo creates a snapshot named foo
• loadvm foo loads the snapshot named foo
• info snapshots shows information about snapshots

Press Ctrl-Alt-Shift-1 to get back to the boot screen, and boot. Once you’re in, your host machine is available to the vm as 10.0.2.2.

git-daemon

There are a few ways you could make your working copy of AIF and libui-sh available to your vm, git-daemon is what I went with. If you have git installed from arch’s repos, you should already have it.

I have all the code I actively work on under $HOME/workspace. If you use a similar setup, modify /etc/conf.d/git-daemon.conf to look something like:

1
2
3
4
5

# path to git repositories served
# GIT_REPO="/srv/git/"
# see `man git-daemon` for all available options
# $GIT_REPO will be present twice in most configs
GIT_DAEMON_ARGS="--detach --syslog --verbose --user-path"

The --user-path option allows us to clone from the vm easily later.

Now, start up git-daemon:

1

# rc.d start git-daemon

And then over in your vm, you need to get some basics set up:

1
2
3
4
5

# pacman -Sy git binutils dialog make
# git clone git://10.0.2.2/~$USERNAME/path/to/aif
# git clone git://10.0.2.2/~$USERNME/path/to/libui-sh
# cd libui-sh && git checkout -t develop && make install && cd -
# cd aif && git checkout -t develop

Take a Snaphot

At this point, you’re pretty well set-up in your vm. Switch over to the monitor, and use savevm to create a snapshot that you can reload later with loadvm.

Sharing Packages With Your Host Machine

I ended up using pacserve to do this. Here’s my /etc/conf.d/pacserved:

1
2
3
4
5
6
7
8
9
10
11
12
13

# Use this array to pass additional arguments to the Pacserve daemon, e.g.
# PACSERVED_ARGS=(--multicast --log /var/log/pacserve/pacserve.log)

# See "pacserve --help" for more information.

# The following options are used by the daemon and must not be included in the
# array:
#
# --daemon
# --pid-file
# --su

PACSERVED_ARGS=(--daemon --log /tmp/pacserve.log)

I’m now considering just mounting the host machine’s /var/cache/pacman via nfs or similar, but the code in the experimental branch of AIF assumes the above, and it works pretty well.

At this point you could loadvm if you need to and:

1
2

# make install # assuming you're in the aif checkout on the vm
# aif -p automatic -c unofficial/jdd-generic-install-sda-using-host-packages

And everything should work. You should be able to reboot into a working arch system. In fact, if you do this and it doesn’t work, please let me know.

(optional) Making AIF Available as a Package on the vm

This is really only necessary for using or working onaif-test, and is by far the area where I’m the least sure of whether I’m doing stuff right. In the “experimental” branch, there are two PKGBUILD templates in unofficial/pkgbuild-templates. Here’s a rundown of what you need to do:

1
2
3
4

# cd
# mkdir -p packages/{aif,libui-sh}
# cp aif/unofficial/pkgbuild-templates/PKGBUILD.aif packages/aif/PKGBUILD
# cp aif/unofficial/pkgbuild-templates/PKGBUILD.libui-sh packages/libui-sh/PKGBUILD

Now, edit the two PKGBUILDS, and set _gitroot to an appropriate value. This should be the only required edit.

Next:

1
2
3
4
5
6

# cd packages/libui-sh && makepkg --asroot && cd -
# cd packages/aif && makepkg --asroot --nodeps && cd -
# mkdir repo
# repo-add repo/aif.db.tar.gz \
#   packages/libui-sh/libui-sh*.pkg.tar.gz packages/aif/aif*.pkg.tar.gz
# cp packages/{libui-sh,aif}/*pkg.tar.gz repo/

And now the aif-test scripts should run, and make use of your host’s packages. As far as I know, none of them are actually working entirely, and this entire step is only actually necessary if AIF is a dependency on the vm after the install finishes in order for aif-test to finish. I haven’t read enough of it to know quite yet.

It would also be unnecessary if AIF and libui-sh were still available in the repos. I don’t particularly like the PKGBUILD-template idea, even though it works. If this actually is necessary right now, hopefully it won’t be for long.

Basic Development Workflow

• Work on your host machine
• loadvm in qemu monitor
• git pull
• make install
• run the part of aif you want to test

Conclusion

Well, that was a lot of setup, but it also helps keep the feedback loop short, which is nice. If you’ve got any suggestions, I’d love to hear them!

Updates

• Updated on Mon Aug 13 10:05:47 EDT 2012 to fix typo pointed out by Mr Green.
• Updated on Mon Aug 13 14:27:49 EDT 2012 to fix erroneous groupadd command pointed out by Mr Green.

Deiter Plaetinck recently handed AIF, the Arch Linux Installation Framework over to me, I’m pretty excited about it.

There’s a lot of work that needs to be done – AIF is currently fairly broken. I’m aiming to fix that, and it looks like some major restructuring will be in order. There are some other popular installation tools around – Archboot, and the current tools on the install disks, arch install scripts. There is also work being done on a port to python, which I’m keeping an eye on.

So far, I have support for grub-bios and syslinux working as bootloaders. I recently spent a couple of days setting up a development environment for making testing AIF less of a pain, there will be a post describing that coming soon.

I’m interested in continuing work on AIF for a few reasons. For one, it’s really a pretty nice tool. The ideas that it’s trying to implement are, at the core, pretty solid in my opinion. It was also the default installation tool for arch for quite some time, and people seem to miss it. In addition, I’ve been wanting to start contributing back to the arch community for a little while, and I happen to be working on some tools for making generation of customized Linux install and live images easy that are partially built on top of AIF.

If you’d like to help out, patches, advice, and feedback are always welcome.

For the first time in a while, I’m feeling the urge to start writing about the tech stuff that I do. This seems like a good platform for doing that with, we’ll see how it goes.