@MrStickman

Find Hacker News Who Is Hiring jobs worth applying to today in 60 seconds, then save your search as a daily no-spam alert.

Verify public proofs, inspect SFCS private proof coverage, and navigate deterministic provenance from one planetary instrument.

Devlog This page contains a curated list of recent changes to main branch Zig. Also available as an RSS feed. This page contains entries for the year 2026. Other years are available in the Devlog archive page. June 30, 2026 All Package Management Functionality Moved from Compiler to Build System Author: Andrew KelleyNow that there is a separate process for users’ build.zig scripts and the build system itself, it makes sense for that to be the place that package management logic lives.I moved these subcommands to the maker process:zig buildzig fetchzig initzig libcThis means that large parts of what used to be included in the compiler executable are now shipped in source form instead, including:package fetching logicHTTP client and networkingTLS (Transport Layer Security) and associated cryptoGit protocolxz, gzip, zstd, flate, zipparsing, validation, and otherwise dealing with build.zig.zon filesConsequently, this functionality can now be patched without rebuilding the compiler, making it easier for users and contributors to tinker.Furthermore, it means that package management in zig now has safety checks enabled when doing networking, since the maker executable is compiled in ReleaseSafe mode. Plus, all the crypto used for networking and file hashing can now take advantage of special CPU instructions available on the host, even the ones that are too rare to normally depend on when distributing software. We can have AOT cake and eat JIT, too!My original motivation for doing this was in relation to exposing a build server protocol in order to unblock ZLS after maker/configurer process separation made breaking changes to the --build-runner override flag.Originally, the process tree looked like this:zig build (the zig compiler + package manager) └─ builder (the user's build.zig logic + build system implementation) The process separation changeset made it look like this instead:zig build (the zig compiler + package manager) ├─ configurer (the user's build.zig logic) └─ maker (build system) At this point, consider a long-running zig build --watch process, watching files and rebuilding on source code changes. If any changes to build.zig are detected, or any files observed during execution of that logic, it means configurer needs to be rerun, meaning that maker process must exit to give zig build a chance to repeat the package management logic.Now, after the changes described in this devlog entry, it looks like this:zig build (the zig compiler) └─ maker (build system + package manager) └─ configurer (the user's build.zig logic) Thus, when configuration needs to be rerun, maker process can continue to live because it is the parent process rather than a sibling. In terms of the upcoming build server, it means avoiding an awkward situation where the server has to exit and the client has to reconnect, rather than simply informing the client of a configuration change.This is almost entirely a non-breaking change, but there are some observable differences:Zig executable binary size: shrinks 4% from 14.1 to 13.5 MiB (no LLVM, ReleaseSmall)--maker-opt flag is replaced by ZIG_DEBUG_MAKER environment variable--zig-lib-dir flag is replaced by ZIG_LIB_DIR environment variableThe follow-up issues to this changeset are the main blockers until we tag Zig 0.17.0:build server protocol MVP (needed to unblock ZLS)introduce the concept of adding path dependencies of the build script itselfmake zig build --watch detect modifications to the build script and rerun itselfdifferent cwd causes build script cache missI have two conferences coming up in July and I need to work on my talks, so being realistic, I don’t think I will have time to wrap these up until early August. Contributions welcome, of course.Big thanks to Techatrix from the ZLS team for reaching out and working with me on the build server protocol! They are seeking sponsorship, by the way. June 26, 2026 SPIR-V Backend Progress Author: Ali CheraghiThere’s quite a bit to cover. The SPIR-V backend had bitrotted in a number of places after the recent compiler changes, so I spent the past several weeks dragging it into a better state.@SpirvTypeSPIR-V has a handful of types that couldn’t be expressed in Zig’s type system. The new @SpirvType builtin has been introduced to address the longest-standing blocker for writing shaders. See #20550, #23326 and #35461 to trace the background.const Sampler = @SpirvType(.sampler); const Image = @SpirvType(.{ .image = .{ .usage = .{ .sampled = u32 }, .format = .unknown, .dim = .@"2d", .depth = .unknown, .arrayed = false, .multisampled = false, .access = .unknown, } }); const SampledImage = @SpirvType(.{ .sampled_image = Image }); const RuntimeArray = @SpirvType(.{ .runtime_array = u32 }); const sampled_image = @extern(*addrspace(.constant) const SampledImage, .{ .name = "sampled_image", .decoration = .{ .descriptor = .{ .set = 0, .binding = 1 } }, }); Execution Mode on the Calling ConventionExecution mode info (workgroup size, fragment origin, etc.) is now carried by the calling convention instead of being emitted via inline assembly OpExecutionMode. The old std.gpu.executionMode() helper is gone, and the SPIR-V assembler now rejects manual OpExecutionMode instructions. Two new calling conventions, spirv_task and spirv_mesh, were also added for mesh shading pipelines.export fn vert() callconv(.spirv_vertex) void {} export fn frag() callconv(.{ .spirv_fragment = .{ .depth_assumption = .greater } }) void {} export fn comp() callconv(.{ .spirv_kernel = .{ .x = 8, .y = 8, .z = 1 } }) void {} export fn task() callconv(.{ .spirv_task = .{ .x = 1, .y = 1, .z = 1 } }) void {} export fn mesh() callconv(.{ .spirv_mesh = .{ .stage_output = .output_lines, .max_primitives = 1, .max_vertices = 2 } }) void {} Capabilities and Extensions from CPU FeaturesCapabilities and extensions used to be emitted ad hoc by codegen or via inline assembly. They’re now driven entirely by the CPU feature set like other targets, with dependency chains extracted from SPIRV-Headers (excluding external vendors for now), and the assembler now rejects any attempt to emit OpCapability or OpExtension directly.Multi-Threaded CodegenFrom day one, the SPIR-V backend ran codegen single-threaded inside the linker thread. Each codegen job now produces an Mir value just like every other self-hosted backend, and gets scheduled on the compiler’s thread pool.The same change brought back two ISel passes that had been removed during earlier refactors: dedup_types (which merges equivalent type instructions) and prune_unused (which strips dead code from the final module). These had originally been deleted back when codegen was single-threaded.Object File Linking.spv files are now recognised as object files. You can compile multiple .zig files (or external .spv objects) and have the SPIR-V linker stitch them into a single module.Tens of bugs have also been fixed along the way with a nearly 10% increase in total passing behavior tests (49% now) on the spirv64-vulkan target, std.gpu was renamed to std.spirv and the SPIR-V backend is meaningfully more useful than it was a month ago, but there’s still a long way to go. Plenty of behavior tests remain skipped on SPIR-V. That said, if you’ve been on the fence about trying Zig for shaders or compute kernels, this is a good time to give it a shot. Bug reports are very welcome on Codeberg. Happy hacking! June 25, 2026 New @bitCast Semantics and LLVM Backend Improvements Author: Matthew Lugg(Quite long devlog coming up, apologies—I got a little carried away with this one!)A few weeks ago, I began working on a branch implementing an improvement to the LLVM backend which had been planned for a long time. This ended up snowballing into a bigger change which implemented a few language proposals you might be interested to hear about.LLVM Backend Integer LoweringZig has always lowered arbitrary bit-width integer types (e.g. u4, i13, u40) directly to LLVM IR’s bit-int types (i4, i13, i40). However, we’ve known for a long time that this lowering is not optimal, because LLVM’s documented semantics for representing these types in memory are unnecessarily restrictive to the optimizer. Perhaps more importantly, because Clang never emits LLVM IR like this, these code paths in LLVM have never been properly tested, and so are poorly supported in practice—over the past few years, we have observed many instances of trivial optimizations being missed and even straight-up miscompilations.So, the original goal of the PR was to only use these bit-int types when manipulating values in SSA form, and to zero- or sign-extend them to ABI-sized types (i8, i16, i32, etc) when storing them in memory. This should be well-supported, not least because it matches how Clang lowers C’s _BitInt(N)!That change was actually fairly straightforward, but I hit one issue which led me down a bit of a rabbit-hole.The Problem with @bitCast@bitCast is an interesting builtin. In the past, it was defined as being equivalent to the following sequence of operations:Take a pointer to the operand valueCast it to a pointer to the destination typeLoad from that pointerIn other words, it was essentially syntax sugar for reinterpreting bytes of memory. However, over time, we diverged from this definition—for instance, it became allowed to use @bitCast to reinterpret a [3]u8 as a u24, even though on most targets @sizeOf(u24) is greater than @sizeOf([3]u8) so the above definition would invoke Illegal Behavior.Up to now, the LLVM backend had implemented these underspecified semantics for the @bitCast builtin. However, because that definition involved reinterpreting memory, changing how we store integer types in memory ended up impacting the implementation of @bitCast, and introducing Illegal Behavior which led to crashes in the compiler test suite.The easiest solution to this would probably have been to implement logic in the LLVM backend to approximately match the old behavior. I instead opted for a better solution—implement a new definition of @bitCast.Redefining @bitCastIn 2024, Jacob Young wrote up language proposal #19755 which aimed to solve the problems with @bitCast by precisely specifying a new set of semantics for it. This proposal was accepted shortly after it was submitted, and in fact, the semantics it details are already implemented by the self-hosted x86_64 backend! So to solve the LLVM backend’s problems, I didn’t necessarily need to match the old @bitCast semantics—instead, this seemed like a good time to finally get the new semantics implemented everywhere.As an aside, another advantage to doing this is that we could take advantage of the compiler’s Legalize pass, which takes difficult-to-lower operations and rewrites them in terms of simpler operations, so that compiler backends only need to support those simple operations. Legalize already had functionality, used by the self-hosted x86_64 backend, which converted complex @bitCast operations into simpler ones, and it could be easily adapted to aid the other compiler backends too (mainly the LLVM and C backends)—but only if they implemented the new semantics.Regardless, the point is, I set out on a side quest (which ended up being harder than the original quest) to implement these new semantics throughout the compiler. This includes not only the LLVM and C backends, but also comptime execution—after all, Zig allows you to do almost any operation at comptime, @bitCast included! Because the new semantics are meaningfully different from the old (more on this later), I also had to audit a lot of uses of @bitCast across the standard library, compiler, and supporting libraries (e.g. compiler_rt). But after a few mostly-painless fixes for CI failures, I was able to finally get my PR green, and landed it in master yesterday (closing a good few issues in the process!).The New @bitCast SemanticsNow that we’ve gotten through all of the background, it’s finally time for me to actually explain new @bitCast behavior. Instead of being based on reinterpreting bytes in memory like before, the builtin is now defined in terms of the bits which logically represent a type.Every type which supports @bitCast has a “logical bit layout”—a representation of that type as an ordered sequence of bits. For instance, u5 is composed of 5 logical bits, which we order from least-significant to most-significant. [2]u5 is composed of 10 logical bits—the 5 from the first element, followed by the 5 from the second element. The new definition of @bitCast is that it reinterprets the logical bits of one type as the logical bits of a different type.The simplest example is to take an unsigned integer, say a u8, and convert it to a signed integer of the same size, in this case i8. This operation does exactly what you’d expect—the bits are unchanged, and we just reinterpret the most-significant bit as a sign bit. Also unchanged are the semantics of @bitCast between an integer type and a packed struct/packed union type.The place where the new semantics differ from the old is when you get aggregate types (arrays and vectors) involved.Consider, for instance, bitcasting a [2]u8 to a u16. Under the old semantics, the result of this operation depends on the target endian: on big-endian targets, the first array element became the 8 most significant bits, whereas on little-endian targets, the first array element became the 8 least significant bits. Under the new semantics, because we only care about logical bit representation (which is endian-agnostic), the operation behaves identically on every target: the first array element becomes the 8 least significant bits. As a general rule, the new semantics tend to match the behavior of the old semantics on little-endian targets.This definition also allows for some weirder operations, such as converting [2]u3 to @Vector(3, u2):test "bitcast [2]u3 to @Vector(3, u2)" { const arr: [2]u3 = .{ 0b001, 0b011 }; const vec: @Vector(3, u2) = @bitCast(arr); // Concatenate all bits of `arr` starting with the least-significant bit of `arr[0]` to find the // logical bit sequence, then read off 2-bit chunks from it to get the elements of the resulting // vector value `vec`. // // arr[0] arr[1] // 0b001 0b011 // ------------- ------------- // 1 0 0 1 1 0 // -------- -------- -------- // 0b01 0b10 0b01 // vec[0] vec[1] vec[2] try expect(vec[0] == 0b01); try expect(vec[1] == 0b10); try expect(vec[2] == 0b01); } const expect = @import("std").testing.expect; This kind of operation isn’t very useful most of the time, but it’s there if you need it! For instance, perhaps you want to deconstruct an integer into a vector of individual bits to operate on—that can now be done by a @bitCast to @Vector(n, u1).While doing all of this stuff, I also implemented a couple of smaller accepted proposals—I won’t detail them here, but you can take a look at the issues if you’re interested:Disallow @bitCast to/from vectors of pointers (#18936)Allow @bitCast on enums (part of #35602)Of course, all of these changed semantics will be explained in the 0.17.0 release notes (hopefully a bit more concisely than what I managed here!), and suggested migration steps outlined.LLVM Backend PerformanceOn a final note, I just wanted to mention that the original motivation for this branch—changing how the LLVM backend lowers non-ABI integer types—was demonstrably successful at restoring missed optimizations. In fact, the Zig compiler itself—despite not making heavy use of arbitrary bit width integers internally!—saw around 5% performance improvements from the better optimization. This means you might have some minor runtime performance gains to look forward to in 0.17.0!Thanks for reading, I hope this was interesting to some of you. Happy hacking! May 30, 2026 ELF Linker Improvements Author: Matthew LuggI’ve spent the past few weeks working on our new ELF linker which debuted in Zig 0.16.0. At the time of the 0.16.0 release, this linker implementation was in its fairly early stages, and only really supported linking Zig-only code without any external libraries (even libc)—hence why it was (and still is) disabled by default (it can be enabled with -fnew-linker). However, quite a lot of progress has been made since that initial release!Here’s a nice milestone—as of my latest PR, the new ELF linker is capable of building the self-hosted Zig compiler with LLVM and LLD libraries enabled, a task which requires quite a few features under the hood.[mlugg@nebula master]$ # Build the Zig compiler using the new linker: [mlugg@nebula master]$ zig build -Dno-lib -Dnew-linker -Denable-llvm [mlugg@nebula master]$ # Use that compiler to build something with LLVM and LLD: [mlugg@nebula master]$ ./zig-out/bin/zig build-exe ~/hello.zig -fllvm -flld [mlugg@nebula master]$ ./hello Hello, World! [mlugg@nebula master]$ Of course, an ELF linker isn’t necessarily the most exciting thing in the world, which is why the headline feature of this new linker is its support for fast incremental compilation. After the recent enhancements, it is now possible (on x86_64 Linux) to perform incremental rebuilds while linking external libraries, C sources, etc—without any additional performance overhead! Here’s a clip of me trying it out on Andrew’s Tetris clone: A few silly changes to Andrew’s Tetris clone being built in around 30ms each.Oh, and fast incremental rebuilds also work nicely on the Zig compiler itself:[mlugg@nebula master]$ zig build -Dno-lib -Denable-llvm -fincremental --watch Build Summary: 4/4 steps succeeded install success └─ install zig success └─ compile exe zig Debug native success 36s Build Summary: 4/4 steps succeeded install success └─ install zig success └─ compile exe zig Debug native success 244ms Build Summary: 4/4 steps succeeded install success └─ install zig success └─ compile exe zig Debug native success 228ms Build Summary: 4/4 steps succeeded install success └─ install zig success └─ compile exe zig Debug native success 288ms Build Summary: 4/4 steps succeeded install success └─ install zig success └─ compile exe zig Debug native success 283ms The biggest missing feature of this linker implementation right now is that it still does not yet support generating DWARF debug information for Zig code—that’s definitely my next priority. But even without that support, it’s amazing just how useful instant rebuilds can be, for example in any situation where you’re doing a lot of print debugging.If you’re using the master branch of Zig and you’re on x86_64 Linux, consider trying out incremental compilation with the new ELF linker if it previously wasn’t working with your project! I expect many codebases to already work great with it, unlocking the ability to rebuild your project in milliseconds. Of course, if you come across any bugs, please do open an issue.And if you’re currently sticking to tagged releases of Zig, don’t worry—as Andrew mentioned in his last devlog, Zig 0.17.0 is just around the corner, so it won’t be long before you can try this too! May 26, 2026 Build System Reworked Author: Andrew KelleyBig branch just landed: separate the maker process from the configurer processThis devlog entry is essentially a preview of the upcoming release notes, but serves as an advanced notice to those who want to help test out the new features and provide feedback that will guide the Zig project moving forward.Before, build.zig files plus the build system implementation were all compiled into one bloated process, in Debug mode. After build.zig logic finished constructing a build graph in memory, the “build runner” code executed it.Now, build.zig files are compiled into a small process (the “configurer”) in debug mode. After this logic finishes constructing a build graph in memory, it is serialized to a binary configuration file. The parent zig build process is aware of this file and caches it for next time. While waiting for all that, it asynchronously compiles the build graph execution process (the “maker”) in release mode. Once the configuration file is available and the maker process is finished compiling, the maker process is executed, passing it the configuration file. The maker process only needs to be compiled once per zig version thanks to the global cache. The maker process then executes the build graph, which is contained within the serialized configuration file.The primary motivation of this change was to make zig build faster, in three ways:Only the user’s build.zig logic will be compiled with each change, rather than the entire build system along with it. This is starting to become more valuable now that we have introduced --watch, --fuzz and --webui. The build system can grow more features without making zig build take longer.Now the build system can skip rerunning the build.zig logic entirely when it knows nothing will change, for example if you add -freference-trace to your zig build command line, it now avoids re-running your build.zig logic redundantly, using the same configuration as last time.Now the process that actually executes the build graph is compiled with optimizations enabled.To demonstrate points 2 and 3, here is the difference between running zig build --help before and after:Benchmark 1 (34 runs): master/zig build -h measurement mean ± σ min … max outliers delta wall_time 150ms ± 5.52ms 145ms … 165ms 4 (12%) 0% peak_rss 84.8MB ± 275KB 84.2MB … 85.1MB 0 ( 0%) 0% cpu_cycles 593M ± 4.01M 588M … 608M 2 ( 6%) 0% instructions 995M ± 52.5K 995M … 995M 0 ( 0%) 0% cache_references 25.8M ± 165K 25.4M … 26.1M 0 ( 0%) 0% cache_misses 651K ± 20.1K 619K … 697K 0 ( 0%) 0% branch_misses 918K ± 7.44K 906K … 935K 0 ( 0%) 0% Benchmark 2 (348 runs): branch/zig build -h measurement mean ± σ min … max outliers delta wall_time 14.3ms ± 744us 13.2ms … 23.3ms 8 ( 2%) ⚡- 90.4% ± 0.4% peak_rss 78.5MB ± 562KB 77.1MB … 81.4MB 7 ( 2%) ⚡- 7.4% ± 0.2% cpu_cycles 24.1M ± 821K 22.8M … 27.1M 3 ( 1%) ⚡- 95.9% ± 0.1% instructions 43.7M ± 23.8K 43.7M … 43.8M 56 (16%) ⚡- 95.6% ± 0.0% cache_references 1.46M ± 14.6K 1.40M … 1.50M 19 ( 5%) ⚡- 94.3% ± 0.1% cache_misses 142K ± 4.87K 127K … 157K 2 ( 1%) ⚡- 78.1% ± 0.4% branch_misses 126K ± 1.37K 120K … 129K 12 ( 3%) ⚡- 86.3% ± 0.1% It’s dramatic because before, build.zig logic was being executed with each zig build command, but now, the build system uses the cached, serialized configuration instead.Aside from performance, I expect third-party tooling such as ZLS to benefit from consuming the serialized configuration file rather than maintaining a fork of the build runner.This changeset heavily reworks the internal mechanism of the zig build system, however, it is mostly non-breaking from an API perspective, with the exceptions noted in the PR linked above.For most people I’m guessing this is the main breaking change they’ll hit:if (b.args) |args| { run_cmd.addArgs(args); } ⬇️run_cmd.addPassthruArgs(); This removes a capability from build scripts since they can no longer observe those arguments. In exchange, it means that when changing those arguments, build scripts no longer must be rebuilt from source.If you’re someone who wants to influence the direction of Zig, this is a good time to upgrade your projects to the development version and try out these changes. We’ll be releasing 0.17.0 within a couple weeks from now. However, if you don’t have time, and you find out that 0.17.0 broke your build, don’t worry, there will be plenty of opportunity to get fixes in for the 0.17.1 tag as well. April 08, 2026 Incremental compilation with LLVM Author: Matthew LuggI’ve been spending a bit of time working on personal projects after merging my type resolution changes last month, but I did find the time recently to make some improvements to the LLVM codegen backend. This involved a few different enhancements with various goals, but one nice user-facing change was that I managed to get incremental compilation working with the LLVM backend.Sadly this can’t do anything to speed up the dreaded LLVM Emit Object: that time is entirely down to LLVM. However, what incremental compilation does help with is minimizing the time spent in the actual Zig compiler code, which means that if your code has compile errors (so “LLVM Emit Object” will be skipped), you’ll usually get those errors very quickly. (Of course, it does still give you a slight speed-up in successful builds too.)This support is available in master branch builds right now, and will be in the 0.16.0 release (which we’ll be tagging very soon).For anyone who still hasn’t tried it, especially if you’re using Zig’s master branch, please do try out incremental compilation by passing -fincremental --watch to zig build! The Zig core team have benefited from incremental compilation in our workflows for a good year now, and we’re also hearing good things from users. The feature is relatively stable at this point, and people are often surprised how much time they can save just by getting up-to-date compile errors in milliseconds rather than seconds.I haven’t really personally used incremental compilation with the LLVM backend, but all of the incremental test coverage in CI is now enabled for the LLVM backend, and I’ve had positive feedback from users, so it’s definitely worth giving a shot. As always, if you encounter bugs in incremental compilation, please report them if you can!Thank you, and I hope you find this useful :) March 10, 2026 Type resolution redesign, with language changes to taste Author: Matthew LuggToday, I merged a 30,000 line PR after two (arguably three) months of work. The goal of this branch was to rework the Zig compiler’s internal type resolution logic to a more logical and straightforward design. It’s a quite exciting change for me personally, because it allowed me to clean up a bunch of the compiler guts, but it also has some nice user-facing changes which you might be interested in!For one thing, the Zig compiler is now lazier about analyzing the fields of types: if the type is never initialized, then there’s no need for Zig to care what that type “looks like”. This is important when you have a type which doubles as a namespace, a common pattern in modern Zig. For instance, when using std.Io.Writer, you don’t want the compiler to also pull in a bunch of code in std.Io! Here’s a straightforward example:const Foo = struct { bad_field: @compileError("i am an evil field, muahaha"), const something = 123; }; comptime { _ = Foo.something; // `Foo` only used as a namespace } Previously, this code emitted a compile error. Now, it compiles just fine, because Zig never actually looks at the @compileError call.Another improvement we’ve made is in the “dependency loop” experience. Anyone who has encountered a dependency loop compile error in Zig before knows that the error messages for them are entirely unhelpful—but that’s now changed! If you encounter one (which is also a bit less likely now than it used to be), you’ll get a detailed error message telling you exactly where the dependency loop comes from. Check it out:const Foo = struct { inner: Bar }; const Bar = struct { x: u32 align(@alignOf(Foo)) }; comptime { _ = @as(Foo, undefined); } $ zig build-obj repro.zig error: dependency loop with length 2 repro.zig:1:29: note: type 'repro.Foo' depends on type 'repro.Bar' for field declared here const Foo = struct { inner: Bar }; ^~~ repro.zig:2:44: note: type 'repro.Bar' depends on type 'repro.Foo' for alignment query here const Bar = struct { x: u32 align(@alignOf(Foo)) }; ^~~ note: eliminate any one of these dependencies to break the loop Of course, dependency loops can get much more complicated than this, but in every case I’ve tested, the error message has had enough information to easily see what’s going on.Additionally, this PR made big improvements to the Zig compiler’s “incremental compilation” feature. The short version is that it fixed a huge amount of known bugs, but in particular, “over-analysis” problems (where an incremental update did more work than should be necessary, sometimes by a big margin) should finally be all but eliminated—making incremental compilation significantly faster in many cases! If you’ve not already, consider trying out incremental compilation: it really is a lovely development experience. This is for sure the improvement which excites me the most, and a large part of what motivated this change to begin with.There are a bunch more changes that come with this PR—dozens of bugfixes, some small language changes (mostly fairly niche), and compiler performance improvements. It’s far too much to list here, but if you’re interested in reading more about it, you can take a look at the PR on Codeberg—and of course, if you encounter any bugs, please do open an issue. Happy hacking! February 13, 2026 io_uring and Grand Central Dispatch std.Io implementations landed Author: Andrew KelleyAs we approach the end of the 0.16.0 release cycle, Jacob has been hard at work, bringing std.Io.Evented up to speed with all the latest API changes:io_uring implementationGrand Central Dispatch implementationBoth of these are based on userspace stack switching, sometimes called “fibers”, “stackful coroutines”, or “green threads”.They are now available to tinker with, by constructing one’s application using std.Io.Evented. They should be considered experimental because there is important followup work to be done before they can be used reliably and robustly:better error handlingremove the loggingdiagnose the unexpected performance degradation when using IoMode.evented for the compilera couple functions still unimplementedmore test coverage is neededbuiltin function to tell you the maximum stack size of a given function to make these implementations practical to use when overcommit is off.With those caveats in mind, it seems we are indeed reaching the Promised Land, where Zig code can have Io implementations effortlessly swapped out:const std = @import("std"); pub fn main(init: std.process.Init.Minimal) !void { var debug

Cryptography & Security Newsletter 138 The Threat of Residential Proxies 30 June 2026 Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić. The last several years have seen the continuous rise of so-called residential proxies. If you’re not familiar with this term, the name refers to the proxies usually (but not always, as we will see later) installed at residential addresses and used for website scraping and similar activities. It’s a fairly niche topic, and it’s quite likely that you won’t have heard about it. It is, however, a phenomenon that requires your attention. What Are Residential Proxies? A great number of services on the Internet try to walk the fine line between providing their wares to the general public while also detecting and eliminating unwanted traffic. Take scraping, for example. It’s ever popular, but increasingly difficult to do. If you try to monitor some of the top websites from a single IP address, you will often end up being blocked, and quickly. If you then try to scale your scanning to use multiple IP addresses from servers at various cloud providers, you’ll find that data center traffic is very often blocked wholesale. Looking for a solution, it’s usually at this point that you learn about the existence of residential proxies. Scraping is often not desired, but it’s not necessarily illegal. Intensive scraping, however, is definitely a problem that websites need to deal with. Those reaching for residential proxies exist on a spectrum from entirely legitimate (as anyone wanting to do any sort of paid network monitoring can attest to) to nefarious. Criminals attempting to exploit websites, for example, often reach for residential proxies to hide their tracks. Recently, the rise of AI and AI agents has further increased the demand. For example, the AI vendors want to train on the content available on the Internet. In addition, individuals using AI want to give their tools the same unrestricted access that they enjoy. It is now believed that bots generate more internet traffic than humans. Perhaps this is a problem we can address by balancing the economy of scraping, by finding a way for the bots to pay for their access. (Cloudflare had this idea in 2025 and later created the x402 standard with Coinbase. AWS recently added support for this payment protocol to their WAF product.) It’s Worse Than You Think To start a residential proxy operation, you need a great many network endpoints all around the world. But how do you build such a network? As it turns out, there are two approaches. One is where you’re pretending that you’re doing it legally. You create software development kits for popular devices that exist in large numbers—for example, mobile phones and TVs—and then entice software developers (with money, of course) to embed your proxy software in their applications. In the worst case, the proxy code is silently deployed alongside the applications, which are often provided for free. In the best case, a consent screen is presented to end users, and they opt in to operate a proxy exit node, but does anyone really believe that such consent is informed? If you’d like to understand more, read this recent report from Include Security. According to Synthient, most victims are, well, residents. The other approach is to build your network in any way you can, using any means, including the very illegal ones. Hacking into routers is always effective, but enterprising criminals are getting much more creative than that: it’s documented that many of the cheap devices one can buy come with residential proxy malware preinstalled. Imagine this: you buy a nice digital frame for your family photos. Unbeknownst to you, the frame is a Trojan horse, and you’re now part of a botnet. KrebsOnSecurity published an in-depth report on how some of these networks operate. Your Local Network Is Under Attack It’s easy to think that this is not a big problem, because—what’s the worst that can happen? If you’re lucky, someone benign will scrape from your IP address and use some of your bandwidth. If your IP address becomes associated with a residential proxy network, you may quickly discover that you can no longer access your websites. If you’re really unlucky, you may get a visit from the FBI or your local government agency because someone used your IP address as a stepping stone in a cyber attack. Increasingly, residential proxy networks are used by criminals to give them access to your internal networks. Although some providers claim to restrict access to private IP addresses, their code is usually poorly written. No one claimed these people understood network security. Apparently, a great many Android-based devices are shipping with something called Android Debug Bridge, designed for manufacturer troubleshooting. On your network, it allows your devices to be quickly rooted. There is increasing evidence of residential proxy traffic from enterprise networks. A recent report from Infoblox (providers of protective DNS services) claims that as much as 65% of their customers have traffic traveling to residential proxy networks. It’s not easy to know what to do. At home, consider using virtual networks to separate important devices from everything else. Monitoring of the traffic volumes is a good idea, too. Other than that, there is no certainty, if anyone in your household can install new apps on your TVs. In enterprise environments, you’d ideally not allow unknown devices on your networks, but that’s easier said than done. Protective DNS services that are aware of the commonly seen residential proxy networks can help contain such traffic as well as point to the offending devices. Some devices may skip DNS altogether and connect via hardcoded IP addresses. In that case, having good threat intelligence and/or enterprise traffic inspection and monitoring. Subscribe to the Cryptography & Security Newsletter This subscription is just for the newsletter; we won't send you anything else. Short News Artificial Intelligence Samuel Judson (Trail of Bits) tested skill scanners from ClawHub, Cisco, and skills.sh and bypassed all of them in under an hour, demonstrating that static skill security tools offer little real protection against malicious AI agent skills in public marketplaces. Cloudflare details their model-agnostic vulnerability discovery harness that scans 128+ repos using parallel hunt/validate agents, cross-repo dependency tracing, and a second model for independent triage, compressing 20,799 raw candidates down to 7,245 actionable findings, with the initial audit skill released on GitHub and the promise of releasing the whole thing as open source. Matthew Green reverse-engineers the encrypted "reasoning" blobs sent via OpenAI and Anthropic APIs, finding they are authenticated ciphertexts returned to clients for multi-turn continuity, and probes what tampering reveals about how frontier LLM providers protect chain-of-thought data. Nahum Korda and Gadi Evron present OpenAnt, an open-source LLM vulnerability discovery pipeline that decomposes codebases by reachability (reducing analysis surface by up to 97%), uses adversarial attacker simulation for verification, and auto-generates sandboxed exploit environments, finding previously unknown vulnerabilities in OpenSSL, WordPress, and Flowise. arXiv paper. Lenny Zeltser and Sounil Yu's AI Defense Matrix is a structured framework for identifying gaps and selecting controls to defend AI systems, aligned with NIST CSF 2.0 and extending the Cyber Defense Matrix. Cryptography Real World Cryptography 2027 conference (Seattle, April 5-7) invites talk proposals on real-world cryptography topics, with submissions due October 15, 2026. Guy Lewin announces that Meta's Messenger now distributes HSM public keys via Cloudflare Key Transparency to strengthen end-to-end encrypted backups. Michele Orru, Trevor Perrin, Nora Trapp, and Greg Zaverucha propose encrypted collaboration spaces, an architecture layering group key management, ratcheting, retention trees, and zero-knowledge fast-forward proofs atop untrusted servers to give collaborative apps verifiable confidentiality and integrity. Aaron Cope (SFO Museum) describes their experience cryptographically signing vector embeddings using X.509 and OpenPGP, their struggles with C2PA's certificate requirements and cost barriers, and why a "Let's Encrypt moment" is needed before C2PA can achieve mass adoption. Andy Tockman reverse-engineers how C#'s System.Random linear seed initialization creates exploitable correlations between Slay the Spire 2's RNG streams, allowing players to predict curses, potion drops, and event outcomes from visible game state. Keegan Ryan (Trail of Bits) and Hanno Böck discovered hundreds of "short-sleeve" RSA keys in the wild with structured zero-bit patterns caused by a type mismatch bug in CompleteFTP, and developed a polynomial-based factoring technique to recover 603 RSA and 74 DSA private keys. Thai Duong uses a one-byte AEAD tag bug (CVE-2026-34182) affecting OpenSSL, wolfSSL, Bouncy Castle, and GnuPG's gpgsm to explain why ciphertext formats are attack surfaces and argues that ciphertexts should carry nothing but a local key id plus an opaque blob, with all parameters bound to the key record. How to format a ciphertext. Nadim Kobeissi announces that his free Applied Cryptography course, originally created for Lebanon and the Levant region, is now adopted at four European universities including Ruhr University Bochum and the University of Edinburgh. Public Key Infrastructure Rob Stradling (Sectigo) releases ctsubmit, an open-source CT submission proxy that handles policy-compliant SCT collection, intelligent log selection, parallel submissions, and monitoring. Stephen Davidson notes that Microsoft's Trusted Root Program has launched a PQC TLS Pilot for CAs to test ML-DSA-enabled certificate hierarchies in closed, non-public environments, requiring ML-DSA-87 for roots and capping leaf certificates at 90 days. Lenny Zeltser traces how observability, short-lived credentials, and active enforcement held the web's certificate trust model together through a decade of CA failures, and examines what lies ahead with post-quantum cryptography and Merkle Tree Certificates. Past, present, and future of web trust. Shodan offers a free API endpoint that returns all hostnames for a domain based on certificate transparency logs, with sample Python code in the Shodan book. Adriano Santoni reports that Firefox 152 now displays a prominent QWAC UI with the EU Trust Mark, replacing the minimal indicator from version 150, though it still requires a couple of clicks to surface rather than appearing automatically. Jake Edge (LWN) explains how Microsoft's 2011 Secure Boot signing key for Linux shim expires in September, why many systems lack the 2023 replacement key, and how LVFS and fwupd are the main path to getting firmware updated before Linux installation media stops booting on Secure Boot systems. Alex Polyakov (Adversa AI) publishes AIRQ, an open-source framework rating 100+ AI agents on security, finding only 11% are both capable and well-defended and 98% combine private data access, untrusted content, and outbound actions. AIRQ framework. Post-Quantum Cryptography Alfred Menezes releases the first version of their comprehensive introduction to lattice-based cryptography, covering Kyber and Dilithium. Apple details its custom formal verification approach using Isabelle, SAW, and Cryptol to prove the correctness of ML-KEM and ML-DSA implementations in corecrypto, releasing the tools and proofs publicly. Marin Ivezic's deep dive series covers how to build a quantum computer from commercially available modular components, including facility prep, cryogenics, control systems, and cost. Google outlines its opinionated strategy for quantum-safe certificates, favoring ML-DSA, Merkle Tree Certificates for Web PKI, and dual-certificate chains for private PKIs, targeting a 2029 migration deadline. European Union Agency for Cybersecurity (ENISA) has made the draft of their Agreed Cryptographic Mechanisms 3.0 open for public comment. ML-DSA, XMSS, LMS, SLH-DSA, ML-LEM, and FrodoKEM are included. Hybrids are recommended. Bas Westerbaan notes that researchers reverse-engineered Google's secret quantum algorithm in under two months, with the paper and Craig Gidney's confirmation now public. Docusign details its quantum-safe strategy: migrating PDF signatures from RSA 4096-bit to ML-DSA, adopting a hybrid cryptography approach, and planning early to address harvest-now-decrypt-later risks. Let's Encrypt outlines its plan to adopt Merkle Tree Certificates (MTCs) for post-quantum Web PKI authentication, targeting a staging environment in late 2026 and production in 2027. Stephen Davidson notes that Chrome 150 (releasing June 30) will add ML-DSA certificate support in TLS for enterprise private PKI, while public Web PKI will instead adopt Merkle Tree Certificates. Patrick Longa announces that FrodoKEM has been standardized in ISO/IEC 18033-2:2006/Amd 2:2026, the first ISO standard for post-quantum cryptography, alongside ML-KEM and Classic McEliece. NTRU is also in the document. Marin Ivezic releases version 2.1 of the Applied Quantum PQC Migration Framework, a completion release that takes explicit positions on hybrid and composite signatures, adds CBOM security and a migration verification and program closure framework, and aligns all six sector extensions to the v2.0 baseline. The PKI Consortium's PQC Working Group introduces the Post-Quantum Cryptography Maturity Model (PQCMM), a six-level vendor-neutral framework giving procurement and supply chain teams a standardized way to evaluate and compare quantum-readiness claims across products, with a formal certification program planned for late 2026. France's ANSSI confirmed it will stop certifying security products lacking quantum-resistant encryption from 2027, requiring hybrid PQC implementations and effectively locking PQC-free vendors out of French government and critical infrastructure markets. Symbolic Software's Dr. Nadim Kobeissi releases a 67-page Post-Quantum Migration Playbook covering primitive selection, hybrid constructions, TLS/PKI migration, secure messaging, library readiness, and common audit findings, with opinionated recommendations calibrated against the asymmetry of migrating too early versus too late. IETF publishes RFC 9958 "Post-Quantum Cryptography for Engineers" by M. Ounsworth, explaining the threat of cryptographically relevant quantum computers to existing public-key systems, the challenges of transitioning to post-quantum algorithms, and why this shift may require significant protocol redesign due to the unique properties of PQC algorithms. Michael Osborne (IBM) argues PQC migration should start with TLS key exchange given the harvest-now-decrypt-later threat, deferring TLS authentication, full crypto inventories, and ECH for later, citing testing across eight TLS stacks that exposed middlebox handshake failures, conflicting server cipher preferences, and FIPS compliance gaps. ICANN's OCTO, in a paper by Paul Hoffman, now recommends the DNSSEC community actively pursue a transition to post-quantum signature algorithms given shortened timelines for cryptographically relevant quantum computers, and that DNS protocols using TLS or QUIC follow the web community's PQC key exchange adoption. Trump signs an Executive Order directing a whole-of-government push to maintain U.S. quantum supremacy, establishing the QC-ADDS national quantum computing effort, updating the National Quantum Strategy within 180 days, and requiring agencies to protect QIST supply chains and restrict adversary access. Daniel J. Bernstein demonstrates two exploitable ML-DSA software vulnerabilities, each recoverable in 1 second on a laptop, and argues that hybrid ECC+PQ signing results in far fewer breakable keys than solo PQ even years after a quantum attack. Paper. Privacy and Society The Cypherpunk Library collects 15 canonical cypherpunk texts, including manifestos by Eric Hughes and Timothy C. May and essays by Hal Finney and Philip Zimmermann, freely readable online. Holly Dagres describes how Iran's latest and longest internet blackout, imposed during this year's war, shows that shutting down connectivity remains a deliberate and repeatable tool of authoritarian control, with Starlink offering only a partial and increasingly risky workaround for Iranians. Security Zack Whittaker reports Meta confirmed 20,225 Instagram accounts were hijacked via an AI chatbot flaw that sent password reset links to attacker-controlled emails on accounts without 2FA, with hacks running from April 17 until Meta disabled the chatbot this week. Steven Murdoch (UCL) reveals that the U.S. military has likely been broadcasting encrypted cryptographic keys over public GPS satellites for nearly 20 years via a hidden subframe field, using the GPS constellation as a covert global numbers station for its Over-the-Air Rekeying (OTAR) network. Interisle Consulting Group's analysis finds cybercriminals registered at least 10 percent, and potentially closer to 20 percent, of new gTLD domains in 2025, with abuse heavily concentrated among a small number of registrars and registries. Paradigm Shift publishes "usbliter8", an unpatchable Boot ROM vulnerability in Apple A12/A13 chips (iPhone XS through 11) that requires physical access and enables potential jailbreaks by defeating early boot security checks. Classifieds Senior Software Engineer, Firefox Security | Mozilla. Contribute to improvements in Firefox's core security systems, with a focus on cryptographic protocols, WebPKI, and security-sensitive web APIs. MOZILLA Software Engineer, Crypto Services - Key Management | Apple. Imagine what you could do here. At Apple, we believe privacy is a fundamental human right. We are looking for a collaborative and innovative Software Engineer to help us design the next generation of security infrastructure. APPLE Applied AI Security Architect | Anthropic. As an Applied AI Security Architect, you will serve as Anthropic's trusted security expert for our most demanding enterprise customers. ANTHROPIC Lead Product Manager, Safety | Wikimedia Foundation. Wikimedia’s Product Safety and Integrity team is charged with keeping Wikipedia a stable and trustworthy place while protecting its many readers and contributors. We are hiring a lead product manager to join this team and help drive this strategy by overseeing a cross-functional product team of engineers, designers, data scientists, and others. WIKIMEDIA Looking to hire? Promote your open roles via our classifieds section. Early-bird discount available, please get in touch. Applying? Please them know you found the position through our newsletter. Your support helps us grow! We use Claude to help us create the short news section. Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications. Remote and trainer-led, with small classes and a choice of timezones. Join over 3,000 students who have benefited from more than a decade of deep TLS and PKI expertise. Find out More

Wikipedia:Deleted articles with freaky titles - Wikipedia Jump to content From Wikipedia, the free encyclopedia List of deleted Wikipedia pages with peculiar titles This page contains material that is considered humorous. Such material is not meant to be taken seriously.ShortcutsWP:DAFWP:DAFWP:DAFTWP:DAFTWP:DAWFTWP:DAWFTWP:FREAKWP:FREAKWP:FREAKYWP:FREAKY Strange titles are rarely added to Wikipedia under the guise of real encyclopedia articles. Occasionally, Wikipedians lose their minds (especially on April Fool's Day) and if their posts are good they wind up here. Silliness can come in the form of creativity, insanity, or just boredom. As with other "silly things", often it seems a shame to delete the best of this humor which has been submitted to us. Unlike bad jokes and other deleted nonsense, however, some of these article names were made for good reasons, on real topics that the writers thought might be useful for Wikipedia. That doesn't always mean that – out of context – the title will be any the less ridiculous-sounding. If you find an article with a strange title up for deletion at WP:AFD, consider this page. If you do add it to the list, simply put it in its correct alphabetical place. Please don't link it – it'll only encourage them. As to this page's title, consider it a mild addition to the collection of "freaky" titles – the real reason for it was just so that it abbreviates to DAFT. Bewildering titles, bizarre titles, and surreal titles – all are equally fair game. Notes for adding titles to this page[edit] A small note of explanation is OK, but please do not sign it – this isn't a talk page. This is for articles or redirects that really existed on Wikipedia which have been deleted – provide proof of the deletion if you can, generally in the form of an XFD discussion page (AFD debates can be quite humorous themselves) or deletion log entry (for articles deleted before December 2004; see also the Wikipedia:Deletion log). If a title, or a slight modification of it, has been recreated either as an article or redirect, it should be removed from this list. Don't stuff beans up your nose. Do not wikilink article titles. Don't glorify vandalism. If an article title was clearly and unquestionably the work of a vandal, or was speedy deleted as a G3, G5, or G10, it's better off forgotten. Don't notify police on the crimes you commit. In other words, making something that would be DAFT, then getting it deleted, then reporting it here, is hands-down idiotic. We're assuming an infinite number of monkeys with an infinite number of typewriters are out there making article names with the hopes that, if one of them is DAFT enough, a user will find it and put it here. Let the chips fall where they may; don't dump them on the floor. Contents 0–9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Categories Drafts Files List articles Portals Talk pages Templates Project pages Titles[edit] Special characters[edit] !"$%&'()* ,-./0123456789:;=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^ `abcdefghijklmnopqrstuvwxyz~ [1] A list of all of the printable ASCII characters. Was a redirect to ASCII. !deargirlloveme! [2] A non-notable band. $10 calculator [3] Was a redirect to Calculator (Nintendo Switch). (((ºJº))) [4] ASCII art redirect to John Lennon. (?) Pinus [5] (alternate (leaf) [6] (see list of episodes) [7] Appeared to be an attempt to write a complete list of Sesame Street episodes that the author had given up on halfway through and left unfinished. ...Fuck It?! [8] An EP by the mathcore band Heavy Heavy Low Low. ???? [9] Has been deleted 7 times. ???? (Nintendo character) [10] ???????? [11] A redirect to List of Pokémon anime characters#Giovanni. In-game, he is actually referred to as ???. ~( 8^(I) [12] An emoticon of Homer Simpson. ©™® [13] Ç‹¬ç‰¹è§Â解 and Ç‹¬ç‰¹è§ÂÂ解[1] The result of repeatedly encoding "Ç‹¬ç‰¹è§è§£" in UTF-8 and then decoding it as Windows-1252. Ç‹¬ç‰¹è§è§£[1] The only plausible correction of this mojibake is from UTF-8 to x-mac-thai "ร์โ«นยฌรงโ«ฐยนรจยงรจยงยฃ", which is semantically meaningless in Thai, and at any rate is still somewhat mojibaked when converted from the then-Wikipedian ISO-8859-1 into the also-meaningless "ว

Vroni is a Software Delegate: a cloud AI developer that plans, codes, runs checks, fixes failures, and returns software your team can review.

13 live products on Railway — secure internal tools with RBAC, audit trails, live Stripe billing, and demos in Django, FastAPI, React, and PostgreSQL.

drifty goes beyond app-level tracking, using AI to understand what you do inside each app, separate focus from drift, and reveal clearer workday insights.

The Official Rules for Calling Shotgun The following are the official rules for calling shotgun, riding in the front seat of a vehicle, that has been created over many years. The ritual of calling Shotgun is designed with the ideals of fairness in mind, allowing all potential occupants of a vehicle to call dibs on the front

As Brussels pushes tech sovereignty, why are there so few AI data centres in Iceland — Europe's cheapest clean power, going spare?

A day in AI now feels like a year in any other industry. TSMC, Vera Rubin VR NVL72: V for Value

The full effects of the ban may not be clear for a decade.