Well, it’s been a little while (something like 10 years) since I’ve done any 3d rendering. After seeing a bunch of inspirational things recently (particularly caminandes 3 and browsing Fi Silva’s work), I thought I’d crack open Blender and have a go at some low-poly artwork.

Of course, I pretty much had to make a blue wren:

(click for huge wallpaper size)

In terms of picking up Blender after not touching 3D software for a decade, it was actually not too painful. Initially it was frustrating to know what I wanted to do but not remember how to achieve it, but there’s plenty of starter resources out there and after a few hours I was feeling relatively comfortable with the basics. An my faded muscle memory probably worked in my favour, because last time I used Blender I had strong 3DS Max knowledge, making Blender feel weird and alien. But coming at it (relatively) fresh, it’s actually quite easy to get used to, and such an amazing piece of software.

I’m particularly amazed in how straightforward certain highly complex things have become - e.g. the builtin cycles renderer does an excellent (and fast!) job of Global Illumination - I remember pining over Arnold and other specialized renderers while scripting complex dome-light rigs to emulate GI with the standard 3DS Max renderer.

Also physics: just for fun I’ve already made a bunch of “solid object turns into liquid and splats on the ground” animated gifs because it takes literally minutes to set this up and run the simulations in Blender. Last time I tried physics I don’t think I even had access to a liquid sim, the most exciting thing I could do was drape a square cloth over a sphere.

Of course, none of that makes animation or modeling any easier, as those are not something the computer can really help much with. But it’s really encouraging to be able to light a scene and have a pretty result in next to no time, especially as lighting is really not my strong suit. And if I ever need a wren to suddenly dissolve into liquid, I’m all set for that too!

TL;DR: install nix and Xephyr, then try this script.

I’ve worked on a GNOME Shell tiling window extension (shellshape) for 5 years now, since before the first release of gnome-shell. The shell itself is impressively extensible, and it’s pretty amazing that I can distribute a tiling window extension which as just a bunch of javascript. But the development process itself has always been awful:

• you have to restart your window manager all the time, which typically loses the sizing and workspace affinity of every window, leaving you with a tangled mess of windows
• if your extension doesn’t work then you have a broken shell
• it is painfully easy to cause a segfault (from JavaScript code :( )
• you’d better be editing your code in a tmux session so you can fix it from a VTE
• sometimes when restarting the shell, all your DBus-based integrations get messed up so you can’t change volume, use multimedia keys or shutdown
• testing against a new gnome-shell version basically means either upgrading your OS or trying to do a fresh install in a VM, which is a whole new layer of annoyance.

Maybe I’m spoiled from working on projects which are easily run in isolation - I bet kernel developers scoff at the above minor inconveniences. But it makes development annoying enough that I dread it, which means I’ll only fix bugs when they get more annoying than development itself.

All of which is to say that this is freakin’ awesome. As of a couple days ago I’ve been able to run the latest version of GNOME Shell (which isn’t packaged for my distro) in a regular window, completely disconnected from my real session, running the development version of shellshape.

Big thanks go to whichever mysterious developers were responsible for fixing whatever gnome-shell / graphics / Xephyr issues have always prevented gnome-shell from running nested (it does now!), and to the nixpkgs folks maintaining the latest GNOME releases so that I can run new versions of GNOME without affecting the rest of my system.

Unfortunately I can’t guarantee it’ll work for you, since this stuff is heavily dependant on your graphics card and drivers, plus it only seems to work with my system version of Xephyr, not the nixpkgs one. But if this interests you, you should definitely give it a go. You’ll need nix and Xephyr. If you don’t want to use nix, you can probably extract what you need from the script to run your system version of gnome-shell in a Xephyr window.

Just a quick heads up, in case anyone comes here looking for verification: I’ve changed my twitter & github handle from @gfxmonk to @timbertson.

I don’t have particular plans to rename this site, since that’s a lot more complex and it would break All The Links. But “gfxmonk” was a name I picked when I was big into computer graphics (and not a monk, though it sounded cool at the time). A decade or so later I’m more of an enthusiastic observer when it comes to graphics, and still not all that monk-like. So I figured I’d adopt a handle that was based on my name, since I probably won’t decide to change that any time soon.

I’ve been aware of transducers for a little while, but haven’t actually used them, or even really felt like I fully grokked what they were good for. They come from the clojure community, but are making their way into plenty of other languages and libraries too. I’ve seen claims that they are a game-changing, breathtaking new concept, which didn’t really square with what they looked like.

So I thought I’d learn more about them by just attempting some plausible but detailed examples with them in JavaScript. If you’ve heard about transducers but aren’t really sure what they’re good for, perhaps this’ll help clarify. And if you’ve never heard of transducers, feel free to take a detour via the clojure documentation.

I use fish-shell as my default shell on my own computer, because it’s a pretty nice shell.

Occasionally, though, this causes issues. Software tests in particular have a habit of sloppily running shell command. Typically, this can be fixed by just being more explicit, using execvp(['bash', '-c', '<command>']) (or just use execv* directly instead of going through a shell).

But one case I couldn’t figure out is SSH. When you’re testing an SSH client, the most reliable way to do that is to run some shell scripts over a local SSH session, and check that it does what you expect. SSH has no way of passing a nice array of arguments, all you get is a string which will be interpreted by the user’s SHELL.

If you want to use bash for an SSH command, many online resources will tell to you run “ssh bash ...". But that won't work for tests, which want to run _real_ commands against a POSIX shell (including edge cases around argument parsing). Other suggestions include changing your default shell, but I don't want to forsake my preferred shell just to appease some automated tests!

What you can do however, is funnel the whole shell string through to your desired shell using this slightly underhand sshd configuration:

ForceCommand sh -c 'eval "$SSH_ORIGINAL_COMMAND"'

This still requires a default shell that’s normal enough to not do any interpolation within single quotes, but that’s a much simpler requirement (and true of fish-shell).

For the Conductance test suite, we run an unprivileged SSHD daemon with its own checked-in config during testing. So applying this globally is fine. But if you are doing this on actual SSH server, you might want to use a Match directive to make sure this rule only applies to trusted user (e.g I haven’t tested how this works on a locked-down account with its shell set to /bin/nologin, it could conceivably create a security hole).

It’s the new year, and it seems to be a vibrant time for novel Operating System technologies. This is not intended to be an objective list of “the best things”, it’s just some up-and-coming technologies that I’m particularly excited about right now: