Zombie Zen

Roxy's Blog

Chromebook Hacking

Posted at by Roxy Light
HP Chromebook 11 showing a command prompt

In my spare time, I’ve been working on Go-SDL2 and Camlistore. I’m usually not sitting in front of my home desktop, so I want to be able to code anywhere. My battle-worn MacBook Pro could do the job, but it’s heavy, bulky, and aging.

To fix this, I bought the HP Chromebook 11. The display is nice, the price is great, and the keyboard is comfortable. It accepts a microUSB charge, so I don’t even have to worry about packing an extra charger. The bummer is development: good luck trying to run anything besides JSFiddle.

For a while, I was using SSH into my desktop to code. Most of the time this works. The problem was me: some days I would forget to turn on my desktop, other days I left it in Windows, and every day I gritted my teeth if I was coding graphics. I fantasized about a machine that booted quickly and had all the programs I needed.

Turns out, the answer was right in front of me: the Chromebook.

Recipe for Success!

  • Buy the Chromebook
  • Enable developer mode
  • Install Secure Shell and set up with Crosh
  • Harden your install
  • Download and run Crouton
  • Install X11 and xmonad
  • Profit!

Total Cost: $279 + half a day’s worth of work.

Over the next few days, I’ll go into more detail on these steps.

Posted at
Permalink
Posted at
Permalink

A night of fun hacks

Posted at by Roxy Light

I discovered that some of my code was still living on my old laptop from high school. The laptop hadn’t been booted in about 4 years, so the clock battery had died, causing the filesystem checks to fail (this is Ubuntu 9.10, which cared about these things). I reset the clock manually, boot up the machine, and decide that to be on the safe (but marginally inefficient) side, I’ll copy my entire multi-GB home directory to my more beefy desktop and filter out what I don’t want there.

Sadly, this laptop came before 802.11n and is limited to 54 Mbps. I have an AirPort Express with only one local port, which is connected to my desktop, but I don’t want to disrupt the network setup. I realize I can chain the Ethernet from my old laptop (named metroid) to my new laptop (named roran), which has 802.11n to connect to my desktop (named nasuada).

It's a UNIX system. I know this.
ross@nasuada$ nc -l 8080 > mybackup.tar.bz2
ross@roran$ nc -l 8080 | nc nasuada.local 8080
ross@metroid$ tar -jcf - $HOME | nc roran.local 8080



I love Unix.

Posted at
Permalink

Why Go Does Not Need Generics

Posted at by Roxy Light

(This developed from a thread with some other Cal Poly students discussing Go.)

One of the frequently asked questions about Go is why are there no generics in the language. It’s a fair point from the perspective of other OOP languages, but idiomatic Go code un-asks the question.

First, it is important to understand how interfaces work in Go. The gist is that interfaces use virtual method lookups, but retain the underlying type, so a conversion back to the original type is still type-safe. An empty interface (interface{}) works as a type-safe equivalent of C’s void*: you can put any type inside of an empty-interface variable, and then you can un-box it later.

The simplest way to define a linked list is through the empty interface: interface{}.

type Node struct {
    Value interface{}
    Next *Node
}

And indeed, this is how the container/list package package works, give or take some complexity. However, my argument is that this is the wrong way to do this. It requires an explicit boxing/un-boxing hit for every access, and this is where (I think) most of the call for generics comes from. There’s a much more idiomatic way to do this. My two case studies here are the sort package and the container/heap package from the standard library.

We start with sort, which defines an interface, sort.Interface:

package sort

func Sort(data Interface)

type Interface interface {
    // Len is the number of elements in the collection.
    Len() int
    // Less returns whether the element with index i should sort
    // before the element with index j.
    Less(i, j int) bool
    // Swap swaps the elements with indexes i and j.
    Swap(i, j int)
}

This may not strike you as a generic container, but that is precisely the point. You can – with a bit of boilerplate – create a type that wraps a typed slice that implements sort.Interface. Thus, the algorithm can work on any type and only works uses indices. This is much cheaper than boxing/unboxing on access.

The second example is container/heap:

package heap

func Init(h Interface)
func Pop(h Interface) interface{}
func Push(h Interface, x interface{})
func Remove(h Interface, i int) interface{}

type Interface interface {
    sort.Interface
    Push(x interface{}) // add x as element Len()
    Pop() interface{}   // remove and return element Len() - 1.
}

Admittedly, there is a bit more boxing/un-boxing going on here, but the idea is still similar. We now have a data structure that requires very few box/unbox operations (two per push/pop). It is important to note that this is still type-safe.

You could implement a binary tree structure similarly:

package tree

func Search(root *Node, val interface{}) *Node

type Node struct {
    Index       int
    Left, Right *Node
}

type Interface interface {
    Len() int
    Less(i, j int) bool
    Push(x interface{})
    Pop() interface{}
}

The Search function would push the val interface and use it for comparisons against the values stored in the tree, then pop it once finished. Admittedly, this isn’t the prettiest interface, but it works in a pinch. It works out to be only one box/un-box round-trip.

As we’ve seen, by “flipping” around the algorithms and separating them from the data structures using interfaces, we can still reap the benefits of generic containers from other languages.

Posted at
Permalink

Today’s xkcd is so sweet I can hardly stand it.

Posted at
Permalink
← Previous Page Next Page →