No, Nanomsg is NOT dead /dev/dump

There seems to have been some pretty misleading data out on the Internet, indicating that "nanomsg is dead".  The main culprit here is a "postmortem" by Drew Crawford.  Unfortunately comments are apparently not working on that post according to Drew himself.

The thing is this (apologies to Samuel Clemens):  "reports of the death of nanomsg have been greatly exaggerated".

So it's time to set the record straight.

I've been working hard on nanomsg, and the Scalability Protocols that are intrinsic to nanomsg for quite some time.  It has been generally occupied my full time paid job for approximately the past year.  I've been working on this stuff part time for longer than that.

The main focus during this time has been a complete rewrite of the core library, known as NNG.  NNG, or nanomsg-next-gen, aims to be a far superior version of nanomsg, with significant new capabilities, greatly improved reliability, scalability, extensibility, and maintainability.  It is wire compatible with legacy nanomsg and mangos, and retains a backwards compatible API (though it also offers a newer API which should be quite a lot easier to use).

During all this time, I've continued to act as the maintainer for nanomsg, although at this point I'd say that nanomsg itself is in sustaining mode, as I'm very focused on having NNG stand in as a full replacement for nanomsg.

We've also published the first NNG book, which is really just the reference manual.  There are over 400 pages (actually about 650 in the 7.5"x9.25" printed edition, which I've not put up yet) of detailed API documentation available.  (Let me know if you're interested in the print edition -- it costs me about $35 to produce, but I'm willing to make it available for folks that are willing to pay for it.  Admittedly the electronic version is probably a lot more useful since it has working hyperlinks and supports searching.)  Oh, and by the way, the book also covers the legacy API used with legacy libnanomsg.

I'm working on the second NNG book, which will be much more of a "how-to" (backed up with case studies and code) now.  (This will take some time to come to market.  At the moment these books are a secondary effort, since the time spent on them is time spent away from working on the code itself or on related commercial activities.)

There have been more contributors to NNG of late, and interest is picking up as NNG itself is already on final countdown for its FCS approach.  (The first beta release, 1.0.0-beta.1 was released last week.  I expect to release a 2nd beta today, and then the final release will probably come a week or so later, depending upon beta test results of course.)

The work I've done for NNG has also inspired me to make further improvements to mangos.  Over the course of the next few months you can expect to see further harmonization between these two projects as NNG gains support for the STAR protocol from mangos, and mangos gains some new capabilities (such as optional separable contexts to enable much easier development of concurrent applications.)

So, if you've heard that "nanomsg is dead", now you know better.  In fact, I'd venture to say that the project is healthier and more alive than it ever was.

Furthermore, in many respects the new NNG project is far more robust, scalable, and stable than I believe nanomsg or ZeroMQ have ever been.  (This because NNG has been designed with a serious eye towards production readiness from the first line of code.  Every error case is carefully considered.)

If you haven't looked at any this stuff lately, give it another look!

Dell XPS/Windows as a Dev Env Lice!

I’ve recently gotten a Dell XPS 15" 2-in-1 and started using it as a development environment for the last week. To be honest as a long term MacBook user I expected a rather disapointing experience but to my big surprise I do really like it so far. But enough of a preamble. Why I’m writing this? Because I figured that the mistakes I made, the hints I got all over the place would have really helped me if someone had collected them - so I do that now. Mind you a lot of it is not specific to the Dell and will work for every system.

The goal

Let’s set expecations. This is not about making the perfect system, after all a week isn’t enough to decide what perfect is and find out all the little things that need to get tweeked. The goal here is to get a ‘good enough’ system that works for most everything without regretting it or missing my MacBook in as little time as possible.

The OS

I suspect many people will be surprised but I decided to stay with windows as a operating system, partially because I’ve not the best opinion on Linux (which I’m not going to discuss here) and partially because I wanted to see how good the out of the box experience is. Last but not least the whole 2-in-1 experience seems to be excelently integreated with the OS and I’m a bit scared to have to fight a different OS to get it all working as it’d be two unknowns to fight instead of just one.

WSL is brilliant, I’ve had very little problems (read none but one super esoteric one we’ll get to later) with it.

My setp

To my great fortune I do use Eemacs which means that my environment of choice works nearly everywhere. OSX, Linux, Windows, WSL, there is an Emacs. Other then that I obviously need my Erlang, I really can’t go without it ;). In addition I tossed in some rust and since I’m writing this post on the XPS ruby. The usual suspects, gcc, make, git and friends come with the terretory.

My initial attempt was to run things on windows. I tried VS code and windos emacs. Erlang, rust, git all exist as native windows binaries but the whole experience wasn’t great especially since in the end it’ll run on a unix or unix like system anyhow. So in the end I used WSL for help and just set everything up there.

Ubuntu 18.04

The WSL installation I picked. I don’t want to go into a distribution war and I’m sure all other distributions just work as well - pick your favourite I simply know ubuntu a bit better then I know SuSe (the alternative from the app store) and can’t be bothered to find out how to add additional distributions.

Most of everything comes in apt, with the exception of rust which uses rustup and erlang wich I fetched the ESL package for to get around ubuntus horrible decision to split up erlang in multiple packages (seriously WTF?!?).


I use space emacs which installes without problems on WSL, just clone the reposit and call it a day. It’ll ask you for additions for languages as you open the files, a lot exist but if you do something that’s more esoteric then erlang you might have to do some additional fiddling.

Here comes the first issue, WSL does not have an X server (I really hope at some point Microsoft will add one) but in the meantime VcXsrv works quite well.

You can add it to auto-start too which helps! After running it the first time it’ll ask you to save the config, do so and then run windows-r and enter shell:startup to open the folder for auto-start, drop the file in there and call it a day.

Once X is started you need to tell the WSL shell where your display is you can do that by adding the line export DISPLAY=localhost:0 at the end of the ~/.profile file.

With that all set you should have a running emacs, feel free to skip the the next section or keep reading here if you want to know a few more fancies.

I really like the Fira Code font, fortunately it comes with ubuntu so you can install it by running sudo install fonts-firacode. To enable it in emacs you can follow their tutorial. Here is the gotcha I talked about while the font works I’ve not yet managed to get the code points to work, but it’s not that big of a deal to me.

A second fancy but not required thing is a Emacs desktop icon. I really wanted the option to just click it and make it start without having to go through bash and running a command or having a console window open. There is a simple trick for that. Create a VB script somewhere with the follow content:

Set oShell = CreateObject ("Wscript.Shell") 
Dim strArgs
strArgs = "bash -c ~/start-emacs"
oShell.Run strArgs, 0, false

and a shell script in your home directory called start-emacs:


export DISPLAY=localhost:0

That’s it you can then link that to the laptop and give it the nice spacemacs icon.

Windows / The hardware

There are a few tweaks to the system I hade to make it more frinedly to my use (read MY use, so YMMV).


The touchpad just isn’t at par with Apples touchpad, honestly none is and I suspect if you ever used a MacBook’s touchpad you easiely agree. But XPS is one of the better ones, probably the best on a PC I’ve ever used and there are a few tweaks that make it more user friendly.

  1. Disable tap to click, it’s just super annoying if you’re used the Mac touchpad.
  2. disable the right side as a right click, two fingers like on the Mac just work fine and feel more natura (to a mac user).
  3. Set 3 finger gestures to “Switching Desktops and showing desktops”.


The XPS uses what dell calls a maglev keyboard, which sounds really cool, it also types quite well. It’s a bit clicky, that’s not for everyone but pressing the key is distinct and you don’t get this “did I press it or not” feeling. Not good or bad but I noticed that compared to the Mac the alt and ctrl keys are placed different. While on the Mac FN and Command/apple/windows are on the outside and alt and ctrl are on the inside the Dell does it the oposite way around. It takes some time to get used to but I think after a few days the way it’s on the Dell feels more natural and better reachable (I still press Windows-D instead of Alt-D way too often :P).

Now the downer. Dell has made the horrible deicsion to put the page up/down keys right about the arrow keys. I hate it. It’s unnatural and trying to count the time I went a page up instead of left resulted in an integer overflow. Fortunately Kevin suggested a toll called AutoHotkey. A simple script like this:


sovles the problem. AHK translates it to a standalone executable that you can put into the auto-start folder mentioned above. Effectively this re-binds the page up/down keys to left/right so that no matter which you end up hitting you get the arrow keys.

USENIX LISA 2018: CFP Now Open Brendan Gregg's Blog

Join us for 3 days in Nashville at LISA18. Post by Brendan Gregg and Rikki Endsley. USENIX’s LISA conference is the premier event for topics in production system engineering. LISA is a vendor-neutral event known for technical depth and rigor, and continues to attract an audience of seasoned professionals. You'll find sysadmins from Wall Street banks sharing stories with SREs at tech giants, as well as experts from many other industries. LISA is where the latest challenges and solutions are discussed face to face, and in more detail than you can find online. It's where important connections are made with other industry professionals, and where they catch up year after year. LISA is a gathering of the pros. The CFP for LISA18 is open now, and we’d love for you to submit talks and tutorials ideas by May 24th, 2018. This is a special year for LISA, which typically alternates between the US east and west coasts. Occasionally, LISA is held in a central location, to attract new people and ideas locally, as well as others remotely who would like a change in destination. In 2018, for the first time, LISA will be in Nashville, Tennessee, October 29-31, and will be hosted at the Omni Nashville Hotel, next to the Country Music Hall of Fame and Museum. Another exciting change for 2018: LISA is now a 3-day event, rather than 6 days; check out the Announcement of Changes to Future LISA Conferences for more details. One of the greatest honors in our industry is to chair a conference, and we (Brendan and Rikki) are excited to be doing this for USENIX LISA18. In addition to our passion for the important role that USENIX plays in our community – a vendor-neutral 501(c)(3) non-profit computing association that advances our industry with conferences, awards, inclusion initiatives, and grants – we also have a strong affection for the LISA conference community. We both have had long careers supporting system administration, and LISA has always felt like a homecoming, reuniting with old friends while welcoming newcomers. We first met each other at LISA, in addition to making many other important industry connections over the years. Apart from networking, attending conferences like LISA in person is an effective way to upgrade your skills: you can block out work interruptions and absorb new knowledge that's been neatly summarized into sessions. You can not only hear from subject matter experts, but also ask them questions from your own environment, and get immediate answers. You could even be that subject matter expert: give a talk or a tutorial, and find people at other companies who want to collaborate, or to give you immediate feedback. ## LISA evolves with the industry

USENIX 1984 speakers: USENIX has been running tech conferences since before the World Wide Web. Photo by Perry Kivolowitz.
Now in its 32nd year, LISA started in 1987 and is one of the longest-running tech conferences. In fact, we’d link to the first LISA conference website for reference, but this conference not only predates the Wayback Machine – it also predates the World Wide Web! LISA originally stood for "Large Installation System Administration," where "large" meant systems with more than a gigabyte of storage, or with more than 100 users. Today's LISA attracts attendees working on all sizes of production systems, and its attendees include sysadmins, systems engineers, SREs, DevOps engineers, software engineers, IT managers, security engineers, network administrators, researchers, students, and more. To survive 32 years, a conference must evolve to stay current with our fast-changing industry. The first LISA events covered topics including email administration, cron, network management, tape backups, uptime, backup and restore, modems and serial ports, and UUCP. Some topics are still present at LISA, such as network management and uptime (reliability), but many others have been updated over the years. In this year's CFP we’re looking for topics covering the latest trends and best practices in cloud computing, containerization, machine learning, big data, infrastructure, scalability, DevOps, IT management, automation, reliability, monitoring, performance tuning, security, databases, programming, datacenters, and more. And we believe that everyone has valuable stories to share: Your tales of trial and error, analysis and workarounds, or architecture migrations, can happen at any company. ## Submit Your Work! We hope you'll consider submitting a talk or tutorial, and plan to attend LISA18. Check out the Call for Participation for details about what we’d like to see at this year’s event and to see the great mix of individuals on the organizing committee. And please help us find LISA18 speakers by sending suggestions to, and by sharing the CFP:
The @LISAConference CFP is open! Have something to say on the present & future of #ops? Submit #lisa18 talk, training, panel, and demo proposals by May 24
Hope to see you in Nashville! – Brendan and Rikki P.S. In addition to from supporting USENIX’s important work and commitment to open access by attending events, you can also join USENIX as a member, and get a subscription to the ;login: technical magazine. P.P.S. To learn more about how LISA has evolved, browse last year's LISA17 conference program, and see the slides and talk videos. Thanks to Liz Markel, USENIX Community Engagement Manager, for edits.

Tallinn Josef "Jeff" Sipek

This post is part of a series named “Europe 2017” where I share photos from my adventures in Europe during the summer 2017.

In late June 2017, Holly and I did a day trip to Wikipedia article: Tallinn. This wasn’t the first time I was in Tallinn, so I knew what the interesting parts of the old town were. As always, there is a gallery with more photos.

Tallinn’s old town is a medieval pocket in a otherwise modern city. In some of the photos you can see the modern civilization right behind a medieval tower.

A view of the Wikipedia article: Alexander Nevsky Cathedral from the tower of Wikipedia article: St. Mary’s Cathedral:

The tower of St. Mary’s Cathedral:

A section of the fortification wall that remains:

I’ve been to Tallinn twice and all my time there was spent in the old town. This makes me far from an expert about what there is to do. With that said, I enjoyed my time there and I recommend a day trip to anyone visiting nearby.

OH-LCD Josef "Jeff" Sipek

This post is part of a series named “Europe 2017” where I share photos from my adventures in Europe during the summer 2017.

When I attended the Kaivopuisto Air Show in early June last year, I learned about the existence of the Finnish Aviation Museum. It took me a month and a half, but eventually I found a free day to go check it out.

The museum itself is packed with all sorts of aircraft on static display. While they were interesting (and I certainly took plenty of photos of them), they aren’t what this post is about. This post is about Lokki—a retired Wikipedia article: DC-3 (registration OH-LCD) on display outside of the museum.

As luck would have it, the folks from the DC Association were there that day trying to see if they could start up Lokki’s engines—after 12 years of inactivity. After a lot of preparation, they managed to start them!

Without further ado, here are a few photos of Lokki (more photos can be found in the gallery).

Wikipedia article: Aero OY was the original name of Finnair:

One of the mechanics working on the left engine:

One of the people from the DC Association, seeing that I was obviously excited about the plane, asked me if I’d like to climb inside. I said yes, of course.

The inside was pretty bare-bones (which is to be expected of a static display that’s normally closed to public). I took a couple of photos inside, but most weren’t that interesting.

Throttle quadrant (note: most of the instrument panel was removed long ago):

It runs!

The livery is pretty simple—polished aluminum with dark blue lettering and a stripe:

I’m not really sure why they wanted to see if they could start the engines, but I’m happy that it worked out. Radial engines just have a unique roar to them.

Anyway, that’s it about Lokki. Hopefully I’ll get around to post processing the photos from the museum itself soon.

Modern Mercurial - Phases Josef "Jeff" Sipek

This post is part of a series named “Modern Mercurial” where I share my realizations about how much Mercurial has advanced since 2005 without me noticing.

Last year, I had a realization that I haven’t been using Mercurial to its full potential. In this post, I’d like to share my thoughts about and usage of Mercurial Phases.

Phases are not a new feature. They made their first appearance back in 2012 as part of Mercurial 2.1, which makes them a little over 6 years old.

What are phases?

While there is a description of phases on the Mercurial wiki, I’ll take a stab at a short intro.

Each commit belongs to one of three phases (public, draft, or secret) which implies a set of allowed operations on the commit. Furthermore, the phase dictates which other phase or phases the commit can transition to.

You can think of the phases as totally ordered (secretdraftpublic) and a commit’s phase can only move in that direction. That is, a secret commit can become either a draft or a public commit, a draft commit can become a public commit, and a public commit is “stuck” being public. (Of course if you really want to, Mercurial allows you to force a commit to any phase via hg phase -f.)

The allowed operations on a commit of a particular phase are pretty self-explanatory:

Public commits are deemed immutable and sharable—meaning that if you try to perform an operation on a commit that would modify it (e.g., hg commit –amend), Mercurial will error out. All read-only operations as well as pushing and pulling are allowed.

Secret commits are mutable and not sharable—meaning that all modifications are allowed, but the commits are not pullable or pushable. In other words, a hg pull will not see secret commits in the remote repository, and a hg push will not push secret commits to the remote repository.

Draft commits are mutable and sharable—a phase between public and secret. Like secret commits, changes to commits are allowed, and like public commits, pushing and pulling is allowed.

Or in tabular form:

Phase Commits Sharing
public immutable allowed
draft mutable allowed
secret mutable prevented

By default, all new commits are automatically marked as draft, and when a draft commit is pushed it becomes public on both ends.

Note that these descriptions ignore the amazing changeset evolution features making their way into current Mercurial since they can blur the “not yet shared” nature of draft commits. (Perhaps I should have titled this post Modern Mercurial (2012 edition) — Phases.)

A note about hg log

Unfortunately, the default hg log output does not display phases at all. I think this is rather unfortunate (but understandable from a backwards compatibility point of view).

Last year, I dedicated a whole post to how I template hg log information including my reasoning for why I display phases the way I do.

How do I use phases?

Now that we have the basic introduction to phases out of the way, let me describe how I mapped them to my workflow.

First of all, I make all new commits start in the secret phase (instead of the default draft) with a quick addition to .hgrc:

new-commit = secret

This immediately prevents an accidental hg push from pushing commits that I’m still working on. (Recall that secret commits cannot be pushed.) In at least one repository, this allowed me to regularly have more than 6 heads with various work-in-progress feature ideas without the fear of accidentally messing up a public repository. Before I started using phases, I used separate clones to get similar (but not as thorough) protections.

Now, I work on a commit for a while (keeping it in the secret phase), and when I feel like I’m done, I transition it to the draft phase (via hg phase -d). At that point, I’m basically telling Mercurial (and myself when I later look at hg log) that I’m happy enough with the commit to push it.

Depending on what I’m working on, I may or may not push it immediately after (which would transition the commit to the public phase). Usually, I hold off pushing the commit if it is part of a series, but I haven’t done the last-chance sanity checks of the other commits.

Note: I like to run hg push without specifying a revision to push. I find this natural (and less to type). If I always specified a revision, then phases wouldn’t help me as much.

“Ugly” repos

I have a couple of repositories that I use for managing assorted data like my car’s gasoline utilization. In these repositories, the commits are simple data point additions to a CSV file and the commit messages are repetitive one-liners. (These one-liners create a rather “ugly” commit history.)

In essence, the workflow these repositories see can be summarized as:

$ echo "2018-04-05,12345,17.231," >> data.csv
$ hg commit -m "more gas"
$ hg push

In these repositories, I’ve found that defaulting to the secret phase was rather annoying because every commit was immediately followed by a phase change to allow the push to work. So, for these repos I changed new-commit back to draft.

Edit: I reworded the sentence about Mercurial giving you a way to force a commit to any phase based on feedback on

Kaivopuisto Air Show 2017 Josef "Jeff" Sipek

This post is part of a series named “Europe 2017” where I share photos from my adventures in Europe during the summer 2017.

In early June 2017, we attended an air show in Wikipedia article: Kaivopuisto. Unfortunately, we found out about it last minute, and so we missed the beginning which included a Finnair Airbus A350 flyby. Pity.

The show included a number of trainers and combat aircraft performing various maneuvers. Here are the highlights (for more photos visit the gallery).

Wikipedia article: Red Arrows:

A seagull joining in:

Wikipedia article: Finnish Coast Guard’s Wikipedia article: Turva nearby with Wikipedia article: Suomenlinna visible behind it:

Wikipedia article: Eurofighter Typhoon:

Wikipedia article: Saab 35 Draken:

Wikipedia article: Saab Gripen:

During one of the passes, I took a burst of images and then assembled them into a Southwest 737 “Airportrait”-style image.

Finnish Air Force Wikipedia article: F-18 Hornet:

A Finnish aerobatics team Wikipedia article: Midnight Hawks flying Wikipedia article: BAE Systems Hawk:

Even though this post has more photos than I typically share, there are many more in the gallery. So, if you are into airplanes, I suggest you peruse it.

The blog has moved blog'o'less

I know, who cares?

I think that I will no longer update this blog.
I want to explore new ways to spread my crappy ideas and rubbish. :-)
I want to try the way to self host a blog. Nothing serious, as always.

However you can find my further posts here:

Juhannus 2017 Josef "Jeff" Sipek

This post is part of a series named “Europe 2017” where I share photos from my adventures in Europe during the summer 2017.

You may have noticed that I was a bit quiet during the last summer. I have a really good reason for it: I spent five months in Helsinki for work. On weekends, Holly and I got to explore, which led me to accumulate approximately 12000 photos. Sadly, I am quite behind on post processing them all, but I will get through them eventually.

This post is about how I spent Wikipedia article: Juhannus last year.

Juhannus is the name of the Finnish summer solstice holiday. It is a time to relax, spend time with friends and family, and enjoy oneself. Every year, a nearby island, Wikipedia article: Seurasaari, has an afternoon and evening with an assortment of traditional events and bonfires.

There is of course a gallery of my photos.

Every year, one couple is selected to have their wedding on Seurasaari during Juhannus. Here is 2017’s lucky couple:

Before about half a dozen bonfires are set ablaze, a number of “can fires” is lit:

The largest bonfire gets lit by the newlyweds—from a boat:

I’m not sure how exactly the big bonfire pile was constructed, but it didn’t take long for it to grow:

So, that was Juhannus on Seurasaari in 2017. It was a nice and relaxing afternoon and evening, and if I happen to be in Helsinki around Juhannus in the future, I’ll likely spend the day on Seurasaari.

I’m going to end this post with a bit of Finnish (from because languages can be fun:

– Kokoo koko kokko kokoon!
– Koko kokkoko?
– Koko kokko.


– Assemble the Midsummer bonfire!
– The whole Midsummer bonfire?
– Yes, the whole Midsummer bonfire.

(I’m told that kokoo is a dialect form of kokoa.)