I'm a bit unsure if this conflicts with the new rule:
Pending an upcoming deploy, we no longer allow submissions which are code repositories. While, at first blush, this may seem odd for a community which is primarily centered around programming but it does eliminate the bulk of the "low effort, self promotional" submissions we've been seeing on the site. We've also found that being dropped into a new codebase doesn't start discussions because the reader has to have enough subject matter experience to immediately recognize what's novel or otherwise worth talking about. Instead, we are more interested in content around code bases which cover why it was created, the purpose it serves, the challenges overcome, and the reasons why it's a useful artifact in the ecosystem.
I assume it's okay since I'm linking to a release rather than the projects codebase. I also think this is directly applicable to macos developers specifically as it might improve their development experience (which seems on topic to me).
I'm curious what the admins say. I'm a fan of what Wild is doing but if we're going to have a ban on code repos I don't see why it would matter whether you're linking the root landing page or the release notes or anything else for that matter. Intuitively it seems to me either both are okay or neither are okay, and my understanding of the new policy is the latter. It's hard to see what the intrinsic difference is between linking release notes in the repo vs in a blog post, but sometimes that's how rules work.
My understanding is that release notes are on topic. There is still an active release tag, and release notes also give more context for a focused discussion than the root of the repo itself.
Impressive set of improvements: more linker script options, more support for GNU flags, better support for some architectures.
It fascinates me that linkers, one of the oldest parts of a software toolchain, are still major engineering projects in 2026. Software is never truly finished.
Linkers are crazy!
I have been working in the space roughly 1 year officially towards building massive binaries and the technical aspects of it have been illuminating [1].
COMDAT section group support (PR #2727): This is a major addition that makes performance comparisons between lld/mold/wild much fairer. I blogged about this feature before. However, this feature slows down symbol resolution considerably. I believe the COMDAT winners are different among the three linkers in some corner cases: the differences should be acceptable in practice.
On the feature front, it's sad to see the implementation of niche features that are virtually unused in GNU ld -- such as the LDEMULATION environment variable and --error-execstack.
These original requests typically come from reporters who may not know which options are actually important (likely driven by LLM-generated linker comparisons).
I've noticed a similar trend with mold a few years ago, where several options are implemented that you almost never need, even if you build every package in Gentoo Linux. Rui Ueyama likely would have rejected them back when he maintained lld/ELF.
[OP] patchunwrap | 22 hours ago
I'm a bit unsure if this conflicts with the new rule:
I assume it's okay since I'm linking to a release rather than the projects codebase. I also think this is directly applicable to macos developers specifically as it might improve their development experience (which seems on topic to me).
pervognsen | 20 hours ago
I'm curious what the admins say. I'm a fan of what Wild is doing but if we're going to have a ban on code repos I don't see why it would matter whether you're linking the root landing page or the release notes or anything else for that matter. Intuitively it seems to me either both are okay or neither are okay, and my understanding of the new policy is the latter. It's hard to see what the intrinsic difference is between linking release notes in the repo vs in a blog post, but sometimes that's how rules work.
gnyeki | 18 hours ago
My understanding is that release notes are on topic. There is still an active release tag, and release notes also give more context for a focused discussion than the root of the repo itself.
pervognsen | 11 hours ago
Thanks, the "context for a more focused discussion" makes sense to me as a framing and how it's consistent with the motivation for the policy change.
Wilfred | 17 hours ago
Impressive set of improvements: more linker script options, more support for GNU flags, better support for some architectures.
It fascinates me that linkers, one of the oldest parts of a software toolchain, are still major engineering projects in 2026. Software is never truly finished.
fzakaria | 7 hours ago
Linkers are crazy! I have been working in the space roughly 1 year officially towards building massive binaries and the technical aspects of it have been illuminating [1].
I'm giving a talk this week on the subject: https://llvm.swoogo.com/2026devmtg/session/4409422/building-massive-binaries
[1] https://fzakaria.com/2026/01/30/crazy-shit-linkers-do-relaxation
MaskRay | 5 hours ago
Many interesting updates.
On the feature front, it's sad to see the implementation of niche features that are virtually unused in GNU ld -- such as the
LDEMULATIONenvironment variable and--error-execstack. These original requests typically come from reporters who may not know which options are actually important (likely driven by LLM-generated linker comparisons).I've noticed a similar trend with
molda few years ago, where several options are implemented that you almost never need, even if you build every package in Gentoo Linux. Rui Ueyama likely would have rejected them back when he maintainedlld/ELF.