Programming Leftovers

posted by Roy Schestowitz on Apr 30, 2026

• Talospace ☛ CopyFail works on ppc64le

  Usually exploits like CopyFail tend to have PoCs or exploits that are architecture-specific. Not this one. Patches should be coming real soon now. Exploit tested using this deobfuscated version.

• Sandor Dargo ☛ C++26: string and string_view improvements

  Let’s continue our exploration of C++26 improvements. Today we focus on string_view. Some types got new constructors accepting string_views, and concatenation of strings and string_views just got easier.

  But let’s start with a brief reminder of what a string_view is.

• Loris Cro ☛ Contributor Poker and Zig's AI Ban

  During my tenure at the Zig Software Foundation I’m having the opportunity to learn many interesting things about software. The one I want to share today is a key piece of understanding for any open source project big enough to attract contributors.

• Kiran Chauhan ☛ TIL: puts() is faster than printf()

  Create a file with name hello.c and write the following code.

• Herb Sutter ☛ My 7-min “lightning talk” is online: Why C++ is growing, and why C++26 will likely be adopted quickly

  At the London C++ meetup last month, I participated on a panel where each panelist gave a short introductory presentation. My 7-minute intro (aka “lightning talk”) just got posted — you can view it here. The one-sentence blurb: “C++ is accelerating, and C++26 is built for what developers need now.”

• SusamPal ☛ Multiple URLs in Git Remote

  Typically a Git remote contains a single URL. For example, when we clone a repository, a remote named origin is automatically created and its URL is set to the location of the upstream repository. For example: [...]

• Akseli Lahtinen ☛ Set up my own Forgejo instance

  Just testing out the forgejo instance I set up. Nothing should really change, my blog just is now on my own instance, so I can be less careful about the amount of data the blog repo uses, since I have tons of pictures.

• Josep Bigorra ☛ Why I Still Reach for Scheme and Lisp Instead of Haskell

  There is a persistent tension in software engineering between the beautiful, mathematically pure ideal of a program, and the messy, pragmatic reality of just getting things done. Over my career, I’ve explored the depths of both extremes in an attempt to find my personal sweet spot for hacking.

• [Old] University of Michigan ☛ Exploratory Experimental Studies Comparing Online and Offline Programming Performance [PDF]

  Two exploratory experiments were conducted at Systems Development Corporation to compare debugging performance of programmers working under conditions of online and offline access to a computer. These are the first known studies that measure programmers' performance under controlled conditions for standard tasks.

  Statistically significant results of both experiments indicated faster debugging under online conditions, but perhaps the most important practical finding involves the strking individual differences in programmer performance. Methodological problkems encountered in designing and conducting these experiments are described; limitations of the findings are pointed out; hypotheses are presented to account for the results; and suggestions are made for further research.

• [Old] Jim Elliott ☛ The Economic Value of Rapid Response Time

  In a pioneering article, inspired by Doherty's work, Arvind J. Thadhani, of IBM's San Jose Laboratory, suggests that the number of transactions a programmer completes in an hour increases noticeably as system response time falls, and rises dramatically once system response time falls below one second. To illustrate (Figure 2), with system response of three seconds, Thadhani found that a programmer executes about 180 transactions per hour. But, bring system response time down to 0.3 seconds and the number of transactions the programmer can execute in an hour jumps to 371, an increase of 106 percent. Put another way, a reduction of 2.7 seconds in system response saves 10.3 seconds of the user's time (Figure 3). This seemingly insignificant time saving is the springboard for sizable increases in productivity.

• [Old] Internet Archive ☛ The Mythical Man-Month (Anniversary Edition)

  Few books on software project management have been as influential and timeless as The Mythical Man-Month. With a blend of software engineering facts and thought-provoking opinions, Fred Brooks offers insight for anyone managing complex projects. These essays draw from his experience as project manager for the IBM System/360 computer family and then for OS/360, its massive software system. Now, 20 years after the initial publication of his book, Brooks has revisited his original ideas and added new thoughts and advice, both for readers already familiar with his work and for readers discovering it for the first time.

  The added chapters contain (1) a crisp condensation of all the propositions asserted in the original book, including Brooks' central argument in The Mythical Man-Month: that large programming projects suffer management problems different from small ones due to the division of labor; that the conceptual integrity of the product is therefore critical; and that it is difficult but possible to achieve this unity; (2) Brooks' view of these propositions a generation later; (3) a reprint of his classic 1986 paper "No Silver Bullet"; and (4) today's thoughts on the 1986 assertion, "There will be no silver bullet within ten years."

• Julien Voisin ☛ Carrot disclosure: Forgejo

  I discussed the conundrum with a friend of mine, and was told to put my money where my mouth is, and just go with carrot disclosure that I usually advocate for in this kind of situation: [...]

• One Happy Fellow ☛ The Subprime Technical Debt Crisis

  Technical debt should excite you.

  Deciding to accrue technical debt means there's such a large opportunity in front of you that it's worth sacrificing the short-term quality of the codebase, making the life harder for you and your fellow devs for a while just to capture it. You don't want to let it slip.

• Perl / Raku

  • Perl ☛ Welcome to the Perl Toolchain Summit 2026!

    This is not the first time we're gathering in Vienna. Back in 2010, the third Perl QA Hackathon was held in Vienna, and organized 100% locally.

    Nowadays, the Perl Toolchain Summit is organized in a distributed fashion, with a global team managing the invitations and the recurring sponsors, and the local team finding the venue, the hotel, and organizing the activities around the event (like the pre-conference meeting yesterday).

    So I'd like to begin with a big thank you to the Vienna team: [...]

• R / R-Script

  • Rlang ☛ logrittr: A Verbose Pipe Operator for Logging dplyr Pipelines

    R’s dplyr pipelines are silent. logrittr fills that gap with %>=%, a drop-in pipe that logs row counts, column counts, added/dropped columns, and timing at every step, with no function masking.

• Education

  • Jeff Dickey ☛ Going Full Time on Open Source

    To keep this sustainable I’m doing it under a company: en.dev. Right now that means one person — me — working full time on mise and the rest of the portfolio. If the funds grow enough, the plan is to bring on a second maintainer so mise keeps a bus factor above 1.

• Python, Rust, and Slop

  • Pimoroni ☛ Grab a MicroPython Birthday Discount!

    Developed by Australian programmer Damien George, MicroPython is a version of Python 3 for microcontrollers. George's first line of private MicroPython code was written on April 29, 2013 and we're marking this momentous event with some deep discounts on your favourite MicroPython boards.

  • LWN ☛ Using LLMs to find Python C-extension bugs

    The open-source world is currently awash in reports of LLM-discovered bugs and vulnerabilities, which makes for a lot more work for maintainers, but many of the current crop are being reported responsibly with an eye toward minimizing that impact. A recent report on an effort to systematically find bugs in Python extensions written in C has followed that approach. Hobbyist Daniel Diniz used Claude Code to find more than 500 bugs of various sorts across nearly a million lines of code in 44 extensions; he has been working with maintainers to get fixes upstream and his methodology serves as a great example of how to keep the human in the loop—and the maintainers out of burnout—when employing LLMs.

  • The New Stack ☛ Anaconda acquires Outerbounds to rein in the buggy code AI agents keep shipping

    In addition, this move signals a broader inflection point in how enterprise software is built. AI-generated code now accounts for nearly half of all new code in enterprise pipelines, Anaconda indicates based on analysis. Yet that code produces 1.7 times as many defects as human-written code, and 80% of dependencies recommended by AI coding assistants pose known security risks, the company says.

  • Corrode.dev ☛ Bugs Rust Won't Catch

    If you write systems code in Rust, this is the most concentrated look at where Rust’s safety ends that you’ll likely find anywhere right now.

  • Trail of Bits ☛ Extending Ruzzy with LibAFL

    LibAFL is all the rage in the fuzzing community these days, especially with LLVM’s libFuzzer being placed in maintenance mode. Written in Rust, LibAFL claims improved performance, modularity, state-of-the-art fuzzing techniques, and libFuzzer compatibility. For these reasons, I set out to add LibAFL support to Ruzzy, our coverage-guided fuzzer for pure Ruby code and Ruby C extensions. This gives Ruby developers and security researchers access to a more advanced and actively maintained fuzzing engine without changing how they write their fuzzing harnesses.

  • LWN ☛ One Sized trait does not fit all

    In Rust, types either possess a constant size known at compile time, or a dynamically calculated size known at run time.

    [...]

    The two existing categories of type, colloquially called "sized" and "unsized", might seem to cover all of the possibilities. Unfortunately, some architectures are quite strange. For example, BPF programs can use "compile once — run everywhere" (CO-RE) relocations to adapt programs to different kernel versions. In such a program, the size and layout of a structure may be unknown at compile time, but effectively static at run time. This puts those structures between Rust's existing classes: accesses can't be reduced to offsets at compile time, but some of the same optimizations used for static offsets apply. Currently, Rust programs targeting BPF are simply not allowed to use CO-RE relocations — a substantial limitation that the Rust developers would like to relax if possible.

    Another example comes from the vector extensions for Arm and RISC-V. These extensions define "single instruction, multiple data" (SIMD) instructions that operate over registers of a CPU-dependent size; the same instruction could correspond to 128-bit, 256-bit, or 512-bit registers depending on the specific CPU being used. Rust has support for working with these extensions through some built-in functions, but could potentially generate better code by exploiting the fact that the size of the relevant registers doesn't change at run time.