Microsoft Hates My Name (Not Me, Just My Name)

In order to debug nanomsg problems on Windows, I recently installed a copy of Windows 8.1 in a VMWare guest VM, along with Visual Studio 14 and CMake 3.5.2.  (Yes, I've entered a special plane of Hell, reserved for just for people who try to maintain cross-platform open source software.  I think this one might be the tenth plane, that Dante skipped because it was just too damned horrible.)

Every time I tried to build, I got bizarre errors from the CMake / build process ... like this:

Cannot evaluate the item metadata "%(FullPath)

Turns out that when I created my account, using the "easy" installation in VMWare, it created my Windows account using my full name.  "Garrett D'Amore".  Turns out that the software is buggy, and can't cope with the apostrophe in my full name, when it appears in a filesystem path. 

Moving the project directory to C:\Projects\nanomsg solved the problem.

Really Microsoft?  This is 2016.  I expected programs to struggle and for me to find bugs in programs (often root exploits  -- all hackers should try using punctuation in their login and personal names) with the apostrophe in my name back in the 1990s.  Not in this decade.

Not only that, but the error message was so incredibly cryptic that it took a Google search to figure out that it was a problem with the path.  (Other people encountered this problem with paths > 260 characters.  I knew that wasn't my problem, but I hypothesized, and proved, that it was my name.)  I have no idea how to file a bug on Visual Studio to Microsoft.  I'm not a paying user of it, so maybe I shouldn't complain, and I really have no recourse.  Still, they need to fix this.

Normally, I'd never intentionally create a path with an apostrophe in it, but in this case I was being lazy and just accepted some defaults.  I staunchly refuse to change my name because some software is too stupid to cope with it -- this is a pet peeve for me. 

We're in the new millennium, and have been for a decade and half.  Large numbers of folks with heritage from countries like Italy, France, and Ireland have this character in their surname.  (And more recently -- since like the 1960s! -- the African-American community has been using this character in their first names too!)  If your software can't accommodate this common character in names, then it's broken, and you need to fix it.  There are literally millions of us that are angered by this sort of brokenness every day; do us all a favor and make your software just a little less rage inducing by letting us use the names we were born with please.

Leaving github

(Brief reminder that this represents my own personal opinion, not necessarily that of any employer or larger open source project.)

I am planning to move my personal git repositories (including mangos, tcell, govisor, less-fork, etc.)  from GitHub to GitLab.com. 

The reasons for this are fairly simple.  They have nothing to do whatsoever with technology.  I love the GitHub platform, and have been a happy user of it for years now. I would dearly love it if I could proceed with GitHub.  Fortunately GitLab seems to have feature parity with GitHub (and a growing user and project base), so I'm not trapped.

The reason for leaving GitHub is because of the hostility of it's leadership towards certain classes of people makes me feel that I cannot in good conscience continue to support them. In particular, their HR department is engaging in what is nothing less than race warfare against white people.  (Especially men, but even white women are being discriminated against.) By the way, I'd take the same position if the hostility were instead towards any other racial or gender group other than my own.

I'm not alone in asking GitHub to fix this; yet they've remained silent on the matter, leading me to believe that the problematic policies have support within the highest levels of the company.  (Github itself is in trouble, and I have doubts about its future, as both developers and employees are leaving in droves.)

Post Tom Preston-Werner, GitHub's leadership apparently sees the company as a platform for prosecuting the Social Justice War, and it even has a Social Impact Team just to that effect. In GitHub's own words:

"The Social Impact team will be focused on these three areas: - Diversity & Inclusion - both internally and within the Open Source Community - Community Engagement - we have a net positive impact in local and online communities via partnerships - Leveraging GitHub for Positive Impact - supporting people from varied communities to use GitHub.com in innovative ways"

It's no accident that they list "Diversity & Inclusion" as the first item here either.  Apparently this has been more of a priority for GitHub than improving their platform or addressing long standing customer issues.

Those of you who have followed me know that I’m strongly in favor of inclusion, and making an environment friendly for all people, regardless of race or gender or religion (provided your religion respects my basic rights -- religious fundamentalist nut-jobs need not apply).

Lack of diversity cannot be fixed through exclusion.  Attempts to do so are inherently misguided.  Furthermore, as a company engages in any exclusive hiring practices they are inherently limiting their own access to talent.  Racist or sexist (or ageist) approaches are self-destructive, and companies that engage in such behavior deserve to fail.

The way to fix an un-level playing field is to level the playing field -- not to swing it back in the other direction.  You can't fix social injustice with more injustice; we should guarantee equal opportunity not equal results.

There are plenty of people of diverse ethnic backgrounds who have overcome significant social and economic barriers to achieve success.  And many who have not.  News flash -- you will find white men and women in both lists, as well as blacks, latinos, women, gays, and people of "other gender identification".  Any hiring approach or policy (written or otherwise) that only looks at the color of a person's skin or gender is unfair, and probably illegal outside of a very limited few and specific instances (e.g. casting for movie roles).

 Note that this does not mean that I do not support efforts to reach out to encourage people from other groups to engage more in technology (or any other field).  As I said, I encourage efforts to include everyone -- the larger talent pool that we can engage with, the more successful we are likely to be.  And we should do everything we can as a society and as an industry to make sure that the talent pool is as big as we can make it.

We should neither exclude any future Marie Curie or Daniel Hale Williams from achieving the highest levels of success, nor should we exclude a future Isaac Newton just because of his race or gender.  The best way to avoid that, is to be inclusive of everyone, and make sure that everyone has the best opportunities to achieve success possible.

Sadly I will probably be labeled racist or sexist, or some other -ist, because I'm not supportive of the divisive agendas supported by people like Nicole Sanchez and Danilo Libre, and because I am a heterosexual white middle class male (hence automatically an entitled enemy in their eyes.)  It seems that they would rather have me as an enemy rather than a friendly supporter -- at least that is what their actions demonstrate.  It's certainly easier to apply an -ist label than to engage in rationale dialogue.

I am however deeply supportive of efforts to reach out to underrepresented groups in early stages.  Show more girls, blacks, and latinos filling the role of technophiles in popular culture (movies and shows) that market towards children.  Spend money (wisely!) to improve education in poorer school districts.  Teach kids that they truly can be successful regardless of color or gender, and make sure that they have the tools (including access to technology) to achieve success based on merit, not because of their grouping.  These efforts have to be made at the primary and secondary school levels, where inspiration can have the biggest effects.  (By the way, these lessons apply equally well to white boys; teaching children to respect one another as individuals rather than as labels is a good thing, in all directions.)

By the time someone in is choosing a college or sitting in front of a recruiter, it's far too late (and far too expensive).  The only tools that can be applied at later stages are only punitive in nature, and therefore the only reasonable thing to do at this late stage is to punish unjust behaviors (i.e. zero tolerance towards bigotry, harassment, and so forth.)

I'll have more detail as to the moves of the specific repos over the coming days.

PS:  GitLab does support diversity as well, which is a good thing, but they do it without engaging in the social justice war, or exclusive policies.

Stepping Down

(Quick reminder that this blog represents my own opinion, and not necessarily that of any open source project or employer.)

For nearly a year, I've been primary maintainer of nanomsg, a library of common lightweight messaging patterns written in C.

I was given this mantle when I asked for the nanomsg community to take some action to get forward progress on some changes I had to fix some core bugs, one of which was a protocol bug.  (I am also the creator of mangos, a wire-compatible library supporting the same patterns written in Go, which is why I came to care about fixing nanomsg.)

Today, I am stepping down as maintainer.

There are several reasons for this, but the most relevant right now is my frustration with this community, and its response to what I believed to be a benign proposal, that to adopt a Code of Conduct, in an attempt to make the project more inviting to a broader audience.

I was unprepared for the backlash.

And frankly, I haven't got enough love of the project to want to continue to lead it, when its clearly unwilling to codify what are frankly some sound and reasonable communication practices.

As maintainer, I could have just enforced my will upon the project, but since the project existed before I came to it, that doesn't feel right.  So instead, I'm just stepping down.

I'm not sure who will succeed me.  I can nominate a party, but at this point there are several other parties with git commit privileges to the project; I think they should nominate one.  Martin (the founder) still has administrative privileges as well.

To be clear, I think both sides of the Code of Conduct are wrong -- a bunch of whinny kids really. 

On the one side, we have people who seem to feel that the existence of a document means something.

I think that's a stupid view; it may have meaning when you have larger democratic projects and you need therefore written rules to justify actions -- and in that case a Code of Conduct is really a way to justify punishing someone, rather than prevention or education.  To those of you who think you need such a document in order to participate in a project -- I think you're acting like a bunch of spineless wimps.

This isn't to say you should have to put up with abuse or toxic conduct.  But if you think a document creates a "safe space", you're smoking something funny.  Instead, look at the actual conduct of the project, and the actions of leadership.  A paper Code of Conduct isn't going to fix brokenness, and I have my doubts that it can prevent brokenness from occurring in the first place.

If the leadership needs a CoC to correct toxic behavior, then the leadership of the project is busted.  Strong leadership leads by example, and takes the appropriate action to ensure that the communities that they lead are pleasant places to be.   (That's not necessarily the same as being conflict-free; much technical goodness comes about as a consequence of heartfelt debate, and developers can be just as passionate about the things they care about as anyone else.  Keeping the tone of such debate on topic and non-personal and professional is one of the signs of good leadership.)

On the other side, are those who rail against such a document.  Are you so afraid of your own speech that you don't think you can agree to a document that basically says we are to treat each other respectfully?  The word I use for such people is "chickenshit".   If you can't or won't agree to be respectful towards others in the open source projects I lead, then I don't want your involvement.

There's no doubt that there exists real abuse and intolerance in open source communities, and those who would cast aspersions on someone because of race, religion, physical attribute, or gender (or preference), are themselves slime, who really only underscore for everyone else their own ignorance and stupidity.  I have no tolerance for such bigotry, and I don't think anyone else should either.

Don't misunderstand me; I'm not advocating for CoCs.  I think they are nearly worthless, and I resent the movement that demands that every project adopt one.  But I equally resent the strenuous opposition to their existence.  If a CoC does no good, it seems to me that it does no harm either.  So even if it is just a placebo effect, if it can avoid conflict and make a project more widely acceptable, then its worth having one, precisely because the cost of doing so is so low.

Yes, this is "slacktivism".

I've been taught that actions speak louder than words though.

So today I'm stepping down.

I'm retaining my BDFL of mangos, of course, so I'll still be around the nanomsg community, but I will be giving it far less of my energy.

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.

But I also have created and support software that runs on Windows, or that people want to use on Windows.  Software like nanomsg, mangos, tcell, etc.  This is stuff that supports other developers.  Its free and open software, and I make no money from any of it.

Supporting that software is a pain on Windows, largely due to the fact that I don't have a Windows license to run Windows in a VM.  The only reason I'd buy such a license for my development laptop would be to support my free software development efforts.  Which would actually help and benefit the Windows ecosystem.

I rely on AppVeyor (which is an excellent service btw) to help me overcome my lack of a Windows instance on my development system.  This has allowed me to support some things pretty well, but the lack of an interactive command line means that some experiments are nigh impossible for me to try; others make me wait for the CI to build and test this, which takes a while.  Leading to lost time during the development cycle, all of which make me loathe working on the platform even more.

Microsoft can fix this.  In their latest "incarnation", they are claiming to be open source friendly, and they've even made big strides here in supporting open source developers.  Visual Studio is free (as in beer).  Their latest code editor is even open source.  The .Net framework itself is open source.

But the biggest barrier is the license for the platform itself.  I'm simply not going to run Windows on the bare metal -- I'm a Mac/UNIX guy and that is not going to change.  But I can and would be happier to occasionally run Windows to better support that platform in a VM, just like I do for illumos or Linux or FreeBSD.

So, Microsoft, here's your chance to make me hate your platform a little less.  Give open source developers access to free Windows licenses; to avoid cannibalizing your business you could have license terms that only allow these free licenses to be used when Windows is run in a virtual machine for non-commercial purposes.  This is a small thing you could do, to extend your reach to a set of developers who've mostly abandoned you.

(And Apple, there's a similar lesson there for you.  I'm a devoted MacOS X fan, but imagine how much wider your developer audience could be if you let people run MacOS X in a VM for non-commercial use?)

In the meantime, if you use software I develop, please don't be surprised if you find that I treat Windows as a distinctly second class citizen.  After all, its no worse than how Microsoft has treated me as an open source developer.

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.  Clearly, it hasn't been enough, and I think we all can and should do better.  I'm interested in finding ways to increase the diversity in illumos in particular, and the industry in general.  Feel free to post your suggestions in the comments following this blog.

Additionally, no, I don't believe that anyone should have to put up with "high performing toxic people".  The illumos community has appropriately censured people for toxic behavior in the past, and I was supportive of that action back then, and still am now.  Maintaining a comfortable work place and a comfortable community leads to increased personal satisfaction, and that leads to increased productivity.  Toxicity drives people away, and that flies in the face of the aforementioned desire for diversity (as well as the unstated ones for a growing and a healthy community.)

Finally, I didn't mean to offend anyone.  If I've done so in my recent tweets, please be assured that this was not intentional, and I hope you'll accept my heartfelt apology.

Thanks.

A Space Shooter in Curses

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 subsystem, scrolling maps, and support for keyboards and mice.  Its also got pretty nice extensibility as assets are defined in YAML files that are converted and compiled into the program.  (I guess an asset editor needs to be written. :-)

The code is Apache 2 licensed, so feel free to borrow bits for your own projects.  I'd love to hear about it.

Anyway, I thought I'd post this here.  I made two videos.  The longer one, at about 3:30, shows most of the features of the game, animated sprites, some nice explosions, gravity effects, beam field effects, etc.

The second video shows what this looks like on less rich terminals -- say a VT100 with only 7-bit ASCII characters available.  The richer your locale, the nicer it will look.  But it falls down as gracefully as one can expect.

Btw, this framework is now basically design complete, so it should be super easy to product a lot of simples kinds of games -- for example a clone of Missile Command or Space Invaders should be doable in an afternoon.   What makes this game a little bigger is the number if different kinds of objects and object interactions we can have.

Fun with terminals, character sets, Unicode, and Go

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 is just awesome.

Until you have to work in one of these legacy environments.   And some of the environments are not precisely "legacy".  (GB18030 has the same repertoire as UTF-8, but uses a different encoding scheme and is legally mandatory within China.)

If you use Tcell for your application's user interface, this is now "fixed".

Tcell will attempt to convert to characters that the user's terminal understands on output, provided the user's environment variables are set properly ($LANG, $LC_ALL, $LC_CTYPE, per POSIX).  It will also convert the user's key strokes from your native locale to UTF-8.  This means that YOU, the application developer, can just worry about UTF-8, and skip the rest.  (Unless you want to add new Encodings, which is entirely possible.)

Tcell even goes further.

It will use the alternate character set (ACS) to convert Unicode drawing characters to the characters supported by the terminal, if they exist -- or to reasonable ASCII fallbacks if they don't.  (Just like ncurses!)

It will also cope with both East Asian full-width (or ambiguous width) characters, and even properly handles combining characters.  (If your terminal supports it, these are rendered properly on the terminal.  If it doesn't, Tcell makes a concerted effort to make a best attempt at rendering -- preserving layout and presenting the primary character even if the combining character cannot be rendered.)

The Unicode (and non-Unicode translation) handling capabilities in Tcell far exceed any other terminal handling package I'm aware of.

Here are some interesting screen caps, taken on a Mac using the provided unicode.go test program.

First the UTF-8.  Note the Arabic, the correct spacing of the Chinese glyphs, and the correct rendering of Combining characters.  (Note also that emoji are reported as width one, instead of two, and so take up more space than they should.  This is a font bug on my system -- Unicode says these are Narrow characters.)

Then we run in ISO8859-1 (Latin 1).  Here you can see the accented character available in the Icelandic word, and some terminal specific replacements have been made for the drawing glyphs.  ISO 8859-1 lacks most of the unusual or Asian glyphs, and so those are rendered as "?".  This is done by Tcell -- the terminal never sees the raw Unicode/UTF-8.  That's important, since sending the raw UTF-8 could cause my terminal to do bad things.

Note also that the widths are properly handled, so that even though we cannot display the combining characters, nor the full-width Chinese characters, the widths are correct -- 1 cell is taken for the combining character combinations, and 2 cells are taken by the full width Chinese characters.

Then we show off legacy Russian (KOI8-R):   Here you can see Cyrillic is rendered properly, as well as the basic ASCII and the alternate (ACS) drawing characters (mostly), while the rest are filled with place holder ?'s.

And, for those of you in mainland China, here's GB18030:  Its somewhat amusing that the system font seems to not be able to cope with the combining enclosure here.  Again, this is a font deficiency in the system.

As you can see, we have a lot of rendering options.  Input is filtered and converted too.  Unfortunately, the mouse test program I use to verify this doesn't really show this (since you can't see what I typed), but the Right Thing happens on input too.

Btw, those of you looking for mouse usage in your terminal should be very very happy with Tcell.  As far as I can tell, Tcell offers improved mouse handling on stock XTerm over every other terminal package.  This includes live mouse reporting, click-drag reporting, etc.   Here's what the test program looks like on my system, after I've click-dragged to create a few boxes:

I'm super tempted to put all this together to write an old DOS-style game.  I think Tcell has everything necessary here to be used as the basis for some really cool terminal hacks.

Give it a whirl if you like, and let me know what you think.