An Arch VM

While I learned linux on Ubuntu and I'm still fond of its balance of usability and stability, I find that whenever I'm doing anything halfway interesting I need the very latest version of my software. This generally consists of finding PPA's which are of varying quality. Of late, I've instead been using linuxbrew, which gives me the latest version of nearly everything built from source. This is great, but with a very small user base, it's quite common for me to run up against bugs that nobody has found. The homebrew/linuxbrew folk have been quite friendly about accepting my patches, but I'd rather not.

Enter Arch Linux. The one killer feature of Arch is its "rolling release". The only supported version of archlinux contains the latest version of all software, always. Arch doesn't even support partial upgrades, for this reason. While I can't imagine how you could run a business on top of this model (not to say someone smarter than me couldn't), it does nicely solve my above problem. Arch's second killer feature is its wiki. It's a really exhaustive and valuable resource on how to configure everything Linux.

The reason Arch's wiki is so great is that the wiki is essentially the installer. Arch's installation process drops you into a shell and tells you to read the wiki. This isn't quite as bad as it seems since the wiki is truly great. The mistake I made the first time trying arch was to start with the "Installation Guide" which walks through everything with almost no detail. The "Beginners' Guide" got me through the process successfully.

For my own reference, I'll walk through exactly what I did to get my Arch VM were I wanted it, below.

Pre-install

I'll be using virtualbox. Create a new VM. The current virtualbox actually has an "Arch Linux" setting. Weird. I'll give it 1.5G memory, 16G disk and access to all my CPUs. I've also enabled 3D acceleration and allowed 128MB video memory under the "Display" tab. Download the installation media (torrent is the fastest way) and mount it to the VM's CD drive.

Disk Partitioning and Formatting

On boot, you'll be greeted by a cheery "root@archiso ~ #" prompt. Arch's installation process begins here. It's entirely manual, but quite well documented on the wiki. You can follow along under  "Beginners' Guide". What appears below is a summary of the steps I actually took.

parted /dev/sda
  mklabel msdos
  mkpart primary linux-swap 1MiB 1GiB
  mkpart primary ext4 1GiB 100%
  set 2 boot on
  quit
mkswap /dev/sda1
mkfs.ext4 /dev/sda2

Now we have a valid partition table and two valid file systems, starting with 1GB swap followed by a large '/' partition. I've put the swap partition first just to make resizing the main partition easier if it comes to that. (I've since discovered cfdisk. Let's use that next time!) Let's mount them up:

swapon /dev/sda1

mount /dev/sda2 /mnt

Installing the Basic System

Now let's put our mirror list in order. This gives me the top six mirrors in the United States:

cd /etc/pacman.d
cp mirrorlist mirrorlist.orig
grep 'United States' -A1 ./mirrorlist.orig | grep -v -- -- > mirrorlist.us
rankmirrors -n 6 ./mirrorlist.us > mirrorlist

Now the big download:

pacstrap -i /mnt base base-devel

Pre-Boot Configuration 

Things are basically installed now, but we still need to configure things before the system can reboot by itself. First, let's put the fstab in order:

genfstab -U /mnt >> /mnt/etc/fstab

Chroot lets us pretend we've already booted to the new disk:

arch-chroot /mnt /bin/bash

Locale stuff:

sed -i '/^#en_US.UTF-8 / s/#//' /etc/local.gen
locale-gen
echo LANG=en_US.UTF-8 > /etc/locale.conf
ln -sf /usr/share/zoneinfo/America/Los_Angeles /etc/localtime

I've picked  "arch-vbox" as my hostname:

echo arch-vbox > /etc/hostname
echo 127.0.1.1 arch-vbox.localdomain arch-vbox >> /etc/hosts

Get our bootloader in order (see GRUB: install to disk)

grub-install --target=i386-pc /dev/sda
grub-mkconfig -o /boot/grub/grub.cfg

Now we can eject the (virtual) installation CD and reboot to complete the installation.

Network Setup

By default, arch gives some unique names to your network devices, but we can find it in the /sys filesystem. Below we enable DHCP for that interface at boot.

IFACE=$(ls /sys/class/net | grep -vw lo)
sudo systemctl enable --now dhcpcd@$IFACE.service

Setting up Users

I'll set up my user (named "buck") with full admin privileges via sudo:

groupadd user
groupadd sudo
useradd -m -g user -G sudo buck
passwd buck
vi /etc/sudoers
(uncomment the line below "allow members of group sudo")
sudo -iu buck
  sudo -l
  (it should say "(ALL) ALL")
  exit

After making double-sure that sudo works well, let's remove root's password; it's one less security hole that way. That's how Ubuntu works, and I've gotten used to it.

passwd -l root

A (very) minimal desktop environment

I'd like to be able to use some graphical tools even while working in this VM, but I don't need all the bells and whistles of a "full-featured" desktop system. As a bare minimum, I've settled on OpenBox with lxpanel and lxterminal.

sudo pacman -S xorg-server xorg-xinit xf86-video-fbdev
sudo pacman -S virtualbox-guest-utils virtualbox-guest-modules-arch
sudo pacman -S lxde-common lxsession openbox gnome-themes-standard
sudo pacman -S lxpanel lxterminal obconf tmux

sudo systemctl enable --now vboxservice.service
sudo systemctl restart systemd-modules-load.service

cp /etc/X11/xinit/xinitrc ~/.xinitrc
vim ~/.xinitrc

# added by me
VBoxClient-all &
lxpanel &
lxterminal -e 'tmux new' &
exec openbox-session

startx

And that's it! This is the bare-bones environment I've been using for a few weeks now. On login, I run startx and I'm presented with a desktop running a terminal with copy-and-paste working.

Addendum A: Shared Folders

Configuring shared folders in virtualbox is straightforward, but getting them mounted correctly is less so. My solution was to add this line to /etc/fstab. The uid/gid bit means I don't have to worry about funky permissions on files in the host or guest.

buck    /mnt/vbox_buck  vboxsf  rw,nodev,uid=buck,gid=user      0 0

a simple(ish) webpage

Today's goal: A simple(ish) webpage which has some editable number fields and graphs based on the numbers.

I'd *really* like to use python for this, but python in the browser just isn't a thing yet. I looked at ipython notebook and bokeh, but they both seem to need a server running python for the page to work. I really want this to be a static html page, with *all* the logic client-side.

Given that I have to use javascript (boo) and that I'm not very experienced in that realm, I took some time to research tooling. I think yeoman is a pretty good indicator of what the frontend community considers to be a good toolset, and I very much like the ideas behind the react project (state mutation is constrained to tiny parts of the data flow), so I looked for a yeoman react generator. There were a whole bunch: http://yeoman.io/generators/. I filtered on "react", sorted by stars, opened up the top ten or so. I then evaluated on these criteria:

• Recent commits? I want to use a project that's alive, in case I want to submit fixes.
• Project age? I don't really want to use someone's weekend project.
• Issue count? This is a rough gauge of user engagement. People don't file tickets against projects they don't use.
• Issue close ratio? I've noticed that well-loved projects always have below a 1:2 open/closed ratio.

If I had familiarity with the node/react ecosystem, I'd be more discerning by feature set, but since I'm a complete newcomer, I'm aiming for the very lowest-common-denominator. Even given all those criteria, I still have four projects left:

• react-webpack
• react-gulp-browserify
• flux-react
• rf

These differ a bit in tooling, so I'll research a bit there:

• node vs io.js:  This is basically corporate vs developer, so I'm going with the developer fork (io.js).
• grunt vs gulp: Gulp is newer and the API seems better designed. The only drawback is it might be too new, but I see the version is up to 3.0 already.
• flux vs reflux: Reflux is newer and the API seems better designed.
• mocha vs jasmine vs jest: Jest is newest and by the same people as React (facebook). It has built-in support for JSX (the language also invented by facebook/React), but it's auto-mock-everything and fake-dom features seem like terrible ideas I've seen before. I'd rather use phantomjs and less mocking. Mocha is more of a do-one-thing-well test runner while Jasmine also has mocking and assertions built in. I'd prefer Mocha, but Jasmine seems fine.

react-webpack is the most popular among the four generators, and supports everything I chose except for Gulp. I'll live with it.

I use homebrew to get my project started on OSX. On linux I use linuxbrew which seems to work just as well.

brew install nvm
source $(brew --prefix nvm)/nvm.sh
nvm install iojs
nvm use iojs
node --version
# v2.0.1
node -h
# Usage: iojs ...
npm install yo generator-react-webpack
export PATH=$PWD/node_modules/.bin:$PATH
yo react-webpack simplish-webpage
# I chose: react-router, reflux, scss npm install grunt-cli
grunt serve


This brings up a little, mostly empty webpage. Cool. This seems like a fair basis for a project. Let's check it in.
git init
git commit --allow-empty -m '(empty)'
git add .
git commit -m 'generated via yo react-webpack'

(To Be Continued...)