While browsing articles about website optimization, I came across a tip to use a modern image format like WebP. The idea is that WebP files are smaller, so pages load faster. At the time, I didn’t really understand why that would work, so I started digging into it, and I ended up going down a rabbit hole.

Some background: the well-known image formats JPEG, PNG and GIF have been around for 25 years or more. They were designed when storage and processing power were expensive, so each one was built for a specific purpose. JPEG became the standard for everyday photos, PNG for icons and computer-generated images, and GIF for short animations (once the patent on its compression algorithm expired in the early 2000s).

Modern Python has powerful features such as asynchronous programming (using async and await) and memory-efficient data processing with generators and iterators. These capabilities, found mainly in Python 3, can noticeably improve both performance and maintainability. Taking advantage of them often means migrating existing Python 2 projects, and the effort involved ranges from a simple conversion to a major refactor. To help you plan, here are some of the most important differences between the two versions.

Years ago, in the country where I grew up and back when I still watched TV, a pattern kept repeating: TV stars would take their shows to rival stations, only to find themselves in a worse position a few months later.

They were often offered better contracts and sometimes even managed to bring part of their original crew along. Yet they rarely held on to their audiences for more than a short while, and some were pushed out of television altogether.

You rarely get to work with Linux namespaces directly. Usually they sit behind the scenes in container tooling or hosting platforms that enforce hard resource limits for customers. But sometimes containers are too heavy for the job. I once needed two instances of the same service to talk to each other over the network.

Why not just have them listen on different addresses or ports? Because it isn’t always that simple. If you can’t change the code and only want to replicate a certain behavior, there may be no way to make an instance use a different port. If the protocol also relies on broadcasting, it gets harder still, since you often don’t have two IP addresses on separate interfaces attached to the same network. Virtualization or containers would solve this, but they’re overkill here. A lightweight alternative is to manipulate Linux network namespaces.

Some intense months later, I’m back with fresh ideas and stories to share. Secrets follow. Well, not really, but I’ve put everything in a list to make it easier to digest.

Once the commercials are over, the movie begins: the interview and then the orientation don’t prepare you for the environment you’ll be swimming in when the daily work starts. On my path to enlightenment I realized that the kitchen staff, the people who cook that good food for you three times a day, are likely evaluated on par with the people they feed. At the end of the day, nobody gets a free meal.

Setting up a public yum repository with S3 is straightforward, but making it private takes more effort. Access control has to be handled by a plugin that fetches files from the S3 bucket through the API, typically using stored credentials. On EC2 instances with an appropriate IAM role, you can skip storing credentials, but in any other environment that isn’t an option.

Either way, the first steps are the same for public and private setups.

Back in the early 2000s, many businesses offered web hosting or ran their services straight from bare-metal servers. The “cloud” only gained real traction within the last 5 to 10 years, and plenty of those older businesses are still around today.

What did it take (and in many cases still takes) to provide services from a colocated or on-premises bare-metal server?

• Hardware first. The physical server had to be bought before anything else, and enclosure size requirements sometimes ruled out consumer-grade hardware.
• Manual OS installation. The operating system had to be installed by hand from installation media.
• Tedious configuration. Setup was a slow process, and many details kept getting fixed in the days after going live.
• Hard-to-handle problems. Unplanned issues, failures, and upgrades (hardware and software) were difficult to deal with and sometimes meant taking the whole server down. Meeting any SLAs was often a matter of luck.

Despite all this, things often worked just fine.

Suppose you ignored my advice from a few months ago and actually landed that job. That’s a real achievement, but it isn’t what I want to write about. In most cases, what you leave behind matters more than what lies ahead of you.

Your current job probably doesn’t compare with the likes of Googamazbook, and that’s fine. Or maybe you feel you didn’t accomplish everything you hoped for when you signed up for the role you’re about to leave. That’s fine too. Let’s go through some common frustrations.

FOSDEM is an annual event for open source software developers, held in Brussels on the first weekend of February.

This year’s event was the 5th FOSDEM I have attended since 2010. Over that time I have watched it evolve: the talks followed the industry’s shifting focus, and some topics disappeared to make room for newer ones. Many of those newcomers never gained real traction and faded away as well.

Note: The go-to tool for XFS repairs is, unsurprisingly, xfs_repair. Getting it to run, however, can sometimes be the hard part.

How does filesystem corruption happen? There are several likely causes:

• Kernel bugs: Rare, but they have happened many times in the past and will happen again. Little can be done beyond applying patches and keeping the kernel up to date.

• Memory issues: For example, memory errors that propagate into the filesystem’s control structures. ECC memory mitigates this, but it can never be fully ruled out.

• Underlying storage problems: Quite unlikely, but still possible.

• Hitting the reset button on a running server: Journaling filesystems can almost always recover from this.

• RAID controller issues: Possibly the leading cause, and not easy to mitigate, even though a firmware upgrade is sometimes available.