Project Announcement

I’ve been meaning, for a long time, to learn gjs, and write up a bunch of tutorials about it. Matthew Garrett’s “The Desktop and the Developer” is now two years old, and it’s sounded like a good idea since before then. I like Gnome, I like GTK+, I wish I could use it for more things in my life. I should just be the change I’d like to see in the world, and do something useful. I kind of even started doing it in gist a long time ago-

• https://gist.github.com/krakensden/4aee5194c82ae90d85fd
• https://gist.github.com/krakensden/8098445206af95b7281e
• https://gist.github.com/krakensden/eb218a3358f2c2db6f44

but it was all just never good enough and I never got far enough. Maybe declaring a commitment to trying to do that a little bit would be worth something in my head.

I’ve been convinced, for years, that I could never do self improvement, because it was so obvious how self improvement could fail. The patent, lame self trickery of pretending to not allow yourself a luxury without doing something else, the unmoored self-boosterism of self esteem, and all their worthless little variations. I’m starting to worry that I’m so persnickety I won’t even let myself grind towards self improvement.

So here we are. Excuse the vanity and narcissism.

Gnome is great, but I get a little grumpy about the visual design sometimes. Thankfully the technical design is elegant enough to make that a fixable problem

A Short Exploration of Github URLs

Github urls look like:

https://github.com/$user/$repo/blob/$commit/$path

A fun & interesting fact is that $commit can contain slashes.

So how do you deal with the possible ambiguities? First, it looks like git does not allow you to have commit IDs (like branches or tags) that are both root and leaf paths:

~/src/github-url-parsing$ git checkout -b release
Switched to a new branch 'release'
~/src/github-url-parsing$ git checkout -b release/README
error: unable to resolve reference refs/heads/release/README: Not a directory
fatal: Failed to lock ref for update: Not a directory

~/src/github-url-parsing$ git checkout -b test/1.5 
Switched to a new branch 'test/1.5'
~/src/github-url-parsing$ git checkout -b test
error: there are still refs under 'refs/heads/test'
fatal: Failed to lock ref for update: Is a directory

which means you can’t have both release/README (branch + path) and release/README (branch). The same holds true for tags:

~/src/github-url-parsing$ git tag foo
~/src/github-url-parsing$ git tag foo/bar
error: unable to resolve reference refs/tags/foo/bar: Not a directory
fatal: refs/tags/foo/bar: cannot lock the ref
~/src/github-url-parsing$ git tag bar/baz
~/src/github-url-parsing$ git tag bar
error: there are still refs under 'refs/tags/bar'
fatal: refs/tags/bar: cannot lock the ref

this appears to be reliably enforced by github, even though they use a non-standard git implementation:

~/src/gup2$ git tag root/branch
~/src/gup2$ git push origin root/branch
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:krakensden/github-url-parsing.git
 * [new tag]         root/branch -> root/branch

~/src/github-url-parsing$ git tag root
~/src/github-url-parsing$ git push origin root
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:krakensden/github-url-parsing.git
 ! [remote rejected] root -> root (cannot lock ref 'refs/tags/root': 'refs/tags/root/branch' exists; cannot create 'refs/tags/root')
 error: failed to push some refs to '[email protected]:krakensden/github-url-parsing.git'

Performance and Composability

I’ve read blog updates and manifestos from the Unikernel crowd for the last couple years with interest and some trepidation, and I think this article is as good an excuse as any to discuss why.

First, I’d like to mention that most of the claims are true. Context switches are expensive, the venerable socket API is a limiter for super high-traffic servers, and C code is dangerous, and subject to an un-necessary array of flaws. On the other hand, I don’t believe the cases for Xen is that strong, although I’m not sure this is the best place to litigate it.

Most deployments are worried about operability and availability, not performance. I make this assertion based on my own experience- which involves a lot of worries about application-level locks, and lots of database bottlenecking- and not much that was limited by the fundamental design of Unix sockets. It’s also worth noting that it’s really not very hard to work around this problem with money- if your application is bottle necked on context switches, adding more boxes will solve that problem. This is an amazing, and amazingly easy, situation to be in, and probably any company in this position will solve it with money. It’s not even going to be very expensive. The problems that seem to keep people up at night are about things that are really hard to solve with money, and have to be solved with engineering time instead- “how do we change our database schema to scale out”, “how do we manage a migration from X to Y”, and “how is our caching layer subtly broken?”

The author also gives no value to having a common operating layer. Given a broken application, in any application, an operating system lets me run all sorts of arbitrary tools to instrument, trace, and debug the problem. All of this breaks with a unikernel. Worse, it’s now entirely language specific, which means everything must be redone from scratch on a per-language basis. It also lets people collaborate outside of the tyranny of development tooling- running statsd alongside applications that report stats is a very effective way of keeping the complexity of batching, retries, etc., outside of the various language libraries, and inside of a common, reusable program. Footnote 10 is an interesting concession to this. But it’s not clear why every other part of the author’s critique doesn’t apply- to get between VMs, you have to context switch. You could imagine building a tower of unikernel’s to get back to something that looked like a standard Unix, but to what end?

To be frank, most of the author’s identified problems with Linux look like the problem of systemic underinvestment in boring but necessary base libraries and utilities. It’s not clear to me that rewriting that universe from scratch solves that problem- wait ten years and you’re there again.

hugo is kind of nice

hugo is kind of nice. Put a web frontend in front of it, and you’d have a serious wordpress competitor. Integrate automatic pushing to S3, and you have super-duper-bulletproof georedundant hosting. Disqus for comments.

Too bad the blog is dead.