CGI/ssh Upgrades

We’re officially introducing three new realms for CGI and ssh, not only to help us stay up to date as CGI languages evolve but also to let us better meet the needs of different members who want different, often conflicting, versions of a language, like Python 2.7 and Python 3.3.

What’s in a name?

The biggest problems with our realms are probably their names. For a long time, the two supported realms were called freebsd72 and 2011Q4. Both of these naming schemes are awful, as the names are very misleading about how out of date they are. (2011Q4, for instance was updated in August of this year.) In fact, we actually had one person cancel earlier this year because they thought the existence of the “freebsd72” realm meant our servers were running FreeBSD 7.2. (In fact, we’re currently running most member sites on FreeBSD 9.2, and that’s not even out yet!)

The venerable freebsd72 realm has been retired. It still works, but you can’t switch sites to it anymore. If your sites are using it — and statistically speaking, they probably are — you ought to think about switching them away from it. The merely outdated 2011Q4 realm has become the default for new sites. (But not for long, keep reading!)

So what are you going to do instead?

We are happy to introduce three new realms that have appeared over the past month (and a new naming scheme meticulously crafted to mean absolutely nothing by expert consultant Roy G. Biv):

red: A stable realm. Stable realms receive only security updates, so they are very good choices for any production site. The “red” realm will become the default for new sites around October 1st.

orange: A beta realm. Beta realms receive regular updates and new package install requests. They are pretty stable, but there is always a minor risk that a shared library version or language minor version could break something. (In practice this almost never happens, maybe once every couple of years.) The “orange” realm will become stable around December 1st and will become the default for new sites around January 1st, 2014.

black: An experimental realm. This is a special realm that features bleeding edge versions of CGI languages that may have major backward compatibility issues. For example, it currently features Python 3.3, Ruby 2.0, and Perl 5.18. This realm is not part of the stable cycle. It will never become beta or stable, it will always be updated to the latest language versions. (So if it seems not to fit the naming scheme, that’s why.) We don’t recommend this realm for any production use; it’s intended for people who want to have access with the latest and greatest in language evolution, even if it means laughing in the face of backward compatibility. Once new language versions settle down, they’ll pop up in the next beta realm and eventually make it to stability that way.

We have also been busy developing and deploying technology to make creating and managing realms easier, so we can do it more often. That effort has now been completed. The “orange” realm went from nonexistence to usability in 8 partially-unattended hours. Contrast that to 2011Q4, which required over a week of labor to set up. We’re happy.

Our goal is to introduce a new beta realm about every three months (starting with “yellow” in December), and to support four stable-track realms at a time: stable/deprecated, stable/default, stable, and beta. When a stable/deprecated realm is replaced, sites using it will be bumped to the new stable/default realm. This should provide a good tradeoff between keeping sites on a stable, well-tested foundation and making sure they receive important security updates.

Since this is a new scheme, we will be a bit conservative at first. Any site still using the archaic “freebsd6” realm will find themselves upgraded to the red realm shortly after it becomes the default in early October. Sites using freebsd72 or 2011Q4 will be automatically upgraded to orange when it becomes the default in January. Then all three of those realms, and their naming schemes, will be sent to live on a farm upstate.

Is that all?

That is not all. If you read our PHP-related blog post, you may have noticed us practically cackling over a brand new layer of secret sauce called NFGI that makes PHP run better than ever. Don’t feel left out! NFGI can be made to work with other languages as well, making them first-class citizens of our service, just as fast and integrated as PHP currently is. This paves the way for making all sorts of frameworks viable that have traditionally been too slow when run through CGI. Rails. Catalyst. Django. We also believe it can be leveraged to make node.js work on our service, but we’re not 100% sure about that.

Now, that’s not ready yet. Each language has to be separately integrated. That’s a lot of work for each language, and we need to know which language to work on next. So head over to our Feature Voting page and look for the proposal to add NFGI support for your favorite language. (And if it’s not listed, propose it! The primary requirement is that you have to be able to embed it from C.)

3 Comments

RSS feed for comments on this post.

1. Really glad to see new blog posts !
   Thought perhaps you’d abandoned the blog.

   Not at all, we just don’t talk when we have nothing to say. And it’s been all work, work, work for a long time to bring these things to fruition. -jdw

   Comment by Jawala — September 21, 2013 #

2. I’m not sure if node.js can be supported considering it seems 99% of tutorials I have seen for it for web page use starts with how to make a web server with it… I have yet to see one that uses node.js as a cgi script.

   We think we have a way around that, but we have 0 staff experts on node.js, so research is needed. -jdw

   Comment by MiquelFire — September 21, 2013 #

3. It sounds like NFGI is a new gateway interface that replaces CGI, much like FastCGI/WSGI/PSGI or similar.

   Is there going to be a spec and an open-source implementation of it for Apache? I’d hate to write a WSGI/PSGI adapter that implements a proprietary gateway interface for NFSN only; that seems against the openness and transparency NFSN usually stands for.

   Like much of the rest of our hosting stack, NFGI is highly customized to our unique environment and is entirely non-portable. Anything to do with it is inherently specific to us, which is why we will be doing most/all of the implementation to make it work with other languages ourselves. Once that’s done, the type of proprietary glue you’re talking about should be minimal or (hopefully) nonexistent for most languages. -jdw

   Comment by Jasper — September 21, 2013 #

Sorry, the comment form is closed at this time.