Posts

Showing posts from 2015

What Microsoft Can Do to Make Me Hate Windows a Little Less

Those who know me know that I have little love for Microsoft Windows.  The platform is a special snowflake, and coming from a Unix background (real UNIX , not Linux, btw), every time I'm faced with Windows I feel like I'm in some alternate dimension where everything is a little strange and painful. I have to deal with Windows because of applications.  My wife runs Quickbooks (which is one of the more chaotic and poorly designed bits of software I've run across), the kids have video games they like.  I've had to run it myself historically because some expense report site back at former employer AMD was only compatible with IE.  I also have a flight simulator for RC aircraft that only works in Windows (better to practice on the sim, no glue needed when you crash, just hit the reset button.) All of those are merely annoyances, and I keep Windows around on one of my computers for this reason.  It's not one I use primarily, nor one I carry with me when I travel. Bu

On Misunderstandings

Yesterday there was a flurry of activity on Twitter, and in retrospect, it seems that some have come away with interpretations of what I said that are other than what I intended.  Some of that misunderstanding is pretty unfortunate, so I'd like to set the record straight on a couple of items now. First off, let me begin by saying that this blog, and my Twitter account, are mine alone, and are used by me to express my opinions.  They represent neither illumos nor Lucera , nor anyone or anything else. Second, I have to apologize for it seems that I've come across as somehow advocating either against diversity (whether in the community or in the workplace) or in favor of toxicity. Nothing could be further from the truth.  I believe strongly in diversity and an inclusive environment, both for illumos, and in the work place.  I talked about this at illumos day last year  (see about 13:30 into the video, slides here ), and I've also put my money where my mouth is.  Clearl

A Space Shooter in Curses

Image
Some of you who follow me may know that I have recently built a pretty nifty framework for working with terminals.  ANSI, ASCII, VT100, Windows Console, etc.  Its called Tcell , and located on github.  (Its a Go framework though.)  It offers many of the same features as curses, though it is most definitely not a clone of curses. Anyway, I decided it should be possible to write a game in this framework, so I wrote one. I give you Escape From Proxima 5 , a 2D multi-axis scrolling space shooter written entirely in Go, designed to operate in your text terminal The game is fairly primordial, but there is a playable level complete with enemies and hazards.   It's actually reasonably difficult to get past just this first level. Mostly the idea here is that you can get a sense of what the game engine is capable of, and see Tcell in action. As part of this, I wrote a pretty complete 2D game engine.  Its got rich sprite management with collision detection, palettes, an events subsy

Fun with terminals, character sets, Unicode, and Go

Image
As part of my recent work on Tcell , I've recently added some pretty cool functionality for folks who want to have applications that can work reasonably in many different locales. For example, if your terminal is running in UTF-8, you can access a huge repertoire of glyphs / characters. But if you're running in a non-UTF-8 terminal, such as an older ISO 8859-1 (Latin1) or KOI8-R (Russian) locale, you might have problems.  Your terminal won't be able to display UTF-8, and your key strokes will probably be reported to the application using some 8-bit variant that is incompatible with UTF-8.  (For ASCII characters, everything will work, but if you want to enter a different character, like Я (Russian for "ya"), you're going to have difficulties. If you work on the console of your operating system, you probably have somewhere around 220 characters to play with.  You're going to miss some of those glyphs. Go of course works with UTF-8 natively.  Which

Tcell - Terminal functionality for Pure Go apps

Introducing Tcell  - Terminal functionality for Pure Go apps As part of the work I've done on govisor , I had a desire for rich terminal functionality so that I could build a portable curses-style management application. This turned out to be both easier and harder than I thought. Easier, because there was an implementation to start from --  termbox-go , but harder because that version wasn't portable to the OS I cared most about , and fell short in some ways that I felt were important.  (Specifically, reduced functionality for mice, colors, and Unicode.) This led me to create my own library; I've made some very very different design choices.  These design choices have let me both support more platforms (pretty much all POSIX platforms and Windows are included), increase support for a much richer set of terminals and terminal capabilities, etc. The work is called " Tcell " (for terminal cells, which is the unit we operate on -- if you don't like the

On Go, Portability, and System Interfaces

I've been noticing more and more lately that we have a plethora of libraries and programs written for Go, which don't work on one platform or another.  The root cause of these is often the use of direct system call coding to system calls such as ioctl().  On some platforms (illumos/solaris!) there is no such system call. The Problems But this underscores a far far worse problem, that has become common (mal)-practice in the Go community.  That is, the coding of system calls directly into high level libraries and even application programs.  For example, it isn't uncommon to see something like this (taken from termbox-go ): func tcsetattr(fd uintptr, termios *syscall_Termios) error {         r, _, e := syscall.Syscall(syscall.SYS_IOCTL,                 fd, uintptr(syscall_TCSETS), uintptr(unsafe.Pointer(termios)))         if r != 0 {                 return os.NewSyscallError(" SYS_IOCTL ", e)         }         return nil } This has quite a few pro

Announcing govisor 1.0

Image
I'm happy to announce that I feel I've wrapped up Govisor to a point where its ready for public consumption. Govisor is a service similar to supervisord , in that it can be used to manage a bunch of processes.  However, it is much richer in that it understands process dependencies, conflicts, and also offers capabilities for self-healing, and consolidated log management. It runs as an ordinary user process, and while it has some things in common with programs like init, upstart, and Solaris SMF, it is not a replacement for any of those things.  Instead think of this is a portable way to manage a group of processes without requiring root.  In my case I wanted something that could manage a tree of microservices that was deployable by normal users.  Govisor is my answer to that problem. Govisor is also written entirely in Go, and is embeddable in other projects.  The REST server interface uses a stock http.ServeHTTP interface, so it can be used with various middleware or fr

MacOS X 10.10.3 Update is *TOXIC*

As a PSA (public service announcement), I'm reporting here that updating your Yosemite system to 10.10.3 is incredibly toxic if you use WiFi. I've seen other reports of this, and I've experienced it myself.  What happened is that the update for 10.10.3 seems to have done something tragically bad to the WiFi drivers, such that it completely hammers the network to the point of making it unusable for everyone else on the network. I have late 2013 iMac 27", and after I updated, I found that other systems started badly badly misbehaving.  I blamed my ISP, and the router, because I was seeing ping times of tens of seconds ! (No, not milliseconds, seconds!!!   In one case I saw responses over 64 seconds.)  This was on other systems that were not upgraded.  Needless to say, that basically left the network unusable. (The behavior was cyclical -- I'd get a few tens of seconds where pings to 8.8.8.8 would be in the 20 msec range, and then it would start to jump up very

vtprint - blast from the past

Image
I recently decided to have a look back at some old  stuff I wrote.  Blast from the past stuff.  One of the things I decided to look at was the very first open source program I wrote -- something called vtprint . vtprint is a tool that borrowed ideas stolen from the pine mail program.  This comes from the days of serial dialups, and legacy ( Kermit  or ProComm for those who remember such things) serial connectivity over 14.4K modems.  Printing a file on a remote server was hard back then; you could transfer the file using xmodem using rx(1), or its "newer" variants, rb(1) or rz(1), but this was awkward.  It turns out that most physical terminals had support for an escape sequence that would start hardcopy to a locally attached printer, and another that would stop it.  And indeed, many terminal emulators have the same support.  (I added support for this myself to the rxvt (1) terminal emulator back in the mid 90's, so any emulators derived from rxvt inherit this suppor

IPv6 and IPv4 name resolution with Go

As part of a work-related project, I'm writing code that needs to resolve DNS names using Go , on illumos . While doing this work, I noticed a very surprising thing.  When a host has both IPv6 and IPv4 addresses associated with a name (such as localhost ), Go prefers to resolve to the IPv4 version of the name, unless one has asked specifically for v6 names. This flies in the fact of existing practice on illumos & Solaris systems, where resolving a name tends to give an IPv6 result, assuming that any IPv6 address is plumbed on the system.  (And on modern installations, that is the default -- at least the loopback interface of ::1 is always plumbed by default.  And not only that, but services listening on that address will automatically serve up both v6 and v4 clients that connect on either ::1 or 127.0.0.1.) The rationale for this logic is buried in the Go net/ipsock.go file, in comments for the function firstFavoriteAddr  () : 76 // We'll take any IP address

Rise of mangos

What is mangos? Those of you who follow me may have heard about this project I've created called mangos . Mangos is a lightweight messaging system designed to be wire compatible with nanomsg , but is implemented entirely in Go . There is a very nice write up of mangos by Tyler Treat, which might help explain some things. Recent Activity As a consequence of a few things, the last two weeks has seen a substantial rise of use of mangos. First off, there was Tyler's excellent article.  (By the way, he's done a series comparing and contrasting other messaging systems -- highly recommended reading.) Second, mangos got mentioned on Hacker News .  That drew a large number visitors to my github repo. Then another open source project, Goq , switched from using libnanomsg to mangos, using the compatibility shim I provided for such use.  As a consequence of that work, several bugs were identified, and subsequently squashed. The upshot of all that is that I saw the