Programming Leftovers

posted by Roy Schestowitz on Jun 06, 2026

• Scoped Commits ☛ Scoped Commits

  Scoped Commits is a loose standard for formatting commit messages that focuses on making the commit log quickly understandable to contributors.

  Normal commit messages should be formatted as follows: [...]

• Herb Sutter ☛ C++: The Documentary released today

  C++: The Documentary premiered today on YouTube, and it was great to be on the live chat with Bjarne and many other key folks who participated in C++’s history. I’m honored to have been one of hundreds of people who have played a part in advancing Bjarne’s wonderful project over the years.

• Dedoimedo ☛ Software security in 2026 - Practical tips for the mildly paranoid

  The "modern" Web is one giant pile of crap. If you disagree, you should probably close this article now, as pretty much anything I write here won't really matter. If you believe social media, vertical videos and apps are cool and amazing, have at it. On the other hand, if you still practice sensible computing, use your desktop as a good, trusty tool, find little joy in smartphones, and you feel concerned about the direction the Internet is going in, then you may want to stick around for some good old-fashioned security tips from a dinosaur.

  In this guide, I want to talk about what you can do to make your online experience slightly less sufferable. I can't promise any great satisfaction, but I can perhaps lessen your pain. Furthermore, with "AI" blurring the lines between lightweight crap and heavyweight crap that passes off as the Web today, you really need to exercise extra caution, if you want your Internet to be quiet and pristine. Let's commence.

• Andrew Nesbitt ☛ Install-script allowlists

  Per-package opt-in lists name which dependencies may run their install code: npm, pnpm, Bun, Deno, and Composer plugins all work this way. Global sandboxes (opam, Swift Package Manager, Nix, Guix, Portage) take a different shape, executing everything but constraining what that execution can reach. Identity and signature verification (RubyGems trust policies, Gradle dependency verification, NuGet trustedSigners, apt-secure) gates which artifacts get installed in the first place by who signed them, with no bearing on what their code subsequently does.

• Andrew Nesbitt ☛ gittuf - a signed log for git refs

  The 2016 USENIX paper that came up in the previous post described this pattern: a hostile server can roll a ref back to an earlier commit, or swap it for a different valid commit on another branch. The fetching client gets a tip that verifies cleanly, a real commit properly signed, just not the one the maintainers most recently advanced the branch to. Git does not sign refs, and the repository carries no record of which commit was the last legitimate tip.

• The Ladybird Browser Initiative ☛ Changing How We Develop Ladybird

  This is not a change we make lightly. Many valuable contributions have come from outside the maintainer group over the years, and we are grateful for them. Many of us also came up through open source by sending patches to projects we cared about.

  For decades, code contributions have been how open source projects learned who to trust. People would show up, do the work, take responsibility for their changes, and stick around. Over time, trust emerged from the work itself.

  AI tools have changed the economics of this very quickly. We use them ourselves every day, but a pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds.

• LWN ☛ Ruby's Bundler adds a cooldown feature

  Version 4.0.13 of Ruby's Bundler package-manager has added dependency cooldowns in order to help mitigate the effect of supply-chain attacks: [...]

• Shell/Bash/Zsh/Ksh

  • [Old] Simple Thread LLC ☛ The Tmux Intro I Wish I Had Gotten

    Tmux is a terminal multiplexer. This means that tmux allows you to run and use multiple programs in parallel in a single terminal window. It uses specific terminology for its components. Understanding them is important for this post, but will also help you if you read tmux’s documentation later.

    Tmux uses a client-server model. State is stored on the server and thus protected from client disconnect. Note that this is true even when using tmux locally–tmux protects against ssh disconnects, but also against accidentally closing your terminal when running programs locally. When using tmux, you are always starting a client that connects to the server.

    A session is a persistent, independent workspace in tmux. Tmux can manage multiple sessions. A client attaches to a session, which allows you to see and manipulate its contents. Sessions have windows, which are like application tabs in the sense that you see one at a time and can switch between them. Windows can be split into multiple panes, which contain running programs.