Ruby

Ubuntu 22.04 was released a couple of days ago. Fullstaq Ruby now provides packages for this distribution!

I previously designed a robust distributed locking algorithm based on Google Cloud. Now I'm releasing a Ruby implementation of this algorithm: distributed-lock-google-cloud-storage-ruby.

To use this, add to your Gemfile:

gem 'distributed-lock-google-cloud-storage'

Traveling Ruby allows you to easily ship Ruby apps to end users. It lets you create self-contained Ruby app packages that run on multiple versions of Windows, Linux and macOS.

Today I’ve released version 20210206. This release supports Ruby 2.4, bumps all the gem versions, bumps the minimum supported macOS and Linux versions, and fixes some bugs.

It has been a long time since the last release. So this post also adresses an elephant in the room: is Traveling Ruby back?

A couple of years ago, I had a dream: to make it dead-easy to distribute Ruby CLI apps to end users, without requiring those users to install Ruby or muck about with gems and Bundler. And thus Traveling Ruby was born.

Traveling Ruby hasn't seen updates for quite a while now. Recently I tried making a new bugfix release, but I found it to be more challenging than I had hoped. In this article I reflect on those challenges, as well as on the future of Traveling Ruby.

A while ago, the people from Fullstaq and I started the Fullstaq Ruby project: a Ruby distribution that's optimized for server use cases. Compared to normal MRI Ruby, Fullstaq Ruby uses 50% less memory, is faster, and is easier to install and security-patch because of RPM and DEB packages.

Since I announced Fullstaq Ruby on EuRuKo 2019, I have received many questions about Fullstaq Ruby's vision, purpose and nature:

• Is Fullstaq Ruby a commercial product, or are there such plans?
• How will Fullstaq Ruby stay maintained?
• Who is in control of Fullstaq Ruby?
• Why are the changes in Fullstaq Ruby not in upstream Ruby? What is the current, and envisioned, relationship between the Ruby core developers and Fullstaq Ruby?

In other words, people are wondering: "how do I know this is, and stays, a real thing that I can count on?"

These are legit questions! As the author of Passenger and Ruby Enterprise Edition, I've experienced first-hand what the challanges are of building a healthy open source project. In this post, I will describe my vision on this matter.

Fullstaq Ruby is a server-optimized Ruby distribution: 50% less memory, faster, easy to install and security-patch via APT/YUM.

We've reached an important milestone in the Fullstaq Ruby roadmap. Epic 3 introduces a continuous integration and deployment system! This means that from now on, we can release updates much faster, and with fewer defects.

We put the CI/CD system to the test right away, and used it to release Ruby version updates. We now package Ruby 2.7.1, 2.6.6 and 2.5.8.

Additionally, we now support Debian 10 (contributed by Nathan Broadbent).

Want to install or upgrade? Check the installation instructions, or run apt upgrade/yum update.

In this article I'll explain why having a CI/CD system is so important. I'll also give you a sneak peek into what to expect in the near future.

I am happy to announce that epic 2 is now released. There is an APT and YUM repository to make installation and security-patching very easy. Epic 2 also includes the newly-released Ruby 2.6.4.

Learn more about the new APT/YUM repo, people’s experience so far, how to use it, and what’s in store for the future.

EuRuKo 2019 – the largest Ruby conference in Europe, took place on the 21st and 22nd of June. I gave a talk on the 21st about what causes Ruby memory bloat (where I also reported new findings since I first blogged about the issue), as well as about Fullstaq Ruby. Fullstaq Ruby is a server-optimized Ruby distribution that's faster, uses less memory, and is easier to security-patch thanks to being distributed via RPMs and DEBs.

My blog post earlier this month about what causes Ruby memory bloat, and about a way to potentially reduce memory usage by 70%, triggered quite a storm in the community! It's clear that I stumbled upon a significant pain point.

Ruby apps can use a lot of memory. But why? Various people in the community attribute it to memory fragmentation, and provide two “hacky” solutions. Dissatisfied by the current explanations and provided solutions, I set out on a journey to discover the deeper truth and to find better solutions.