catitw

Motivatation

• modern CMake is required for building a lot of new software
• CMake is dependency for many packages (e.g. ROS related)
• we don't want to remove CMake (which would remove packages that depend on it)
• we want safe procedure to update CMake that can be reversed easily

Current version in OS

Check current version

quad

Don't use log levels, use structured logging

I read [an argument for only two log levels: INFO and ERROR][only-info-error]. I [responded][log-response] essentially saying:

1. I lightly agree that we could get away with two log levels.
2. I strongly disagree that we only need two ways to log.

Like the blog post's author, most of systems that I've worked on have had poor logging practices. But unlike the blog post's author, I strongly suspect that's because most logging APIs offer poor affordances.

quad

I've been writing Rust full-time with a small team for over a year now. Throughout, I've lamented the lack of clear best practices around defining error types. One day, I'd love to write up my journey and enumerate the various strategies I've both seen and tried. Today is not that day.

Today, I want to reply to a blog post that almost perfectly summarised my current practice.

Go read it; I'll wait!

---

bmegli

Motivatation

• modern CMake is required for building a lot of new software
• CMake is dependency for many packages (e.g. ROS related)
• we don't want to remove CMake (which would remove packages that depend on it)
• we want safe procedure to update CMake that can be reversed easily

Current version in OS

Check current version

brson

Edit: This list is now maintained in the rust-anthology repo.

• Introduction
  • Understanding Over Guesswork
  • An Alternative Introduction to Rust
  • Rust and CSV Parsing
• Ownership
  • Where Rust Really Shines
  • Rust Means Never Having to Close a Socket
• The Problem with Single-threaded Shared Mutability