r2vcap

Nobody should feel insulted simply because a project decides to port its codebase to another language. It is a technical decision, not a personal attack.

Zig’s response has been a serious mistake. The TypeScript team ported the TypeScript compiler and language service from TypeScript to Go for TypeScript 7.0. Did anyone interpret that as the team insulting TypeScript itself? I certainly did not.

Those problems are partly attributable to Zig itself. If the project accepted AI-assisted contributions, this controversy might never have happened. Completely shutting out one side of the industry and taking a dogmatic position is not helpful, especially for a pre-1.0 language that is still relatively immature.

Now the Zig community is attacking one of the largest and best-known codebases ever built with the language. Anthropic’s motives are clearly promotional, but even so, I would not choose Zig for any project.

From a supply-chain perspective, Cargo is still in the same broad risk category as npm and PyPI: installing packages means trusting externally published code, including code that may execute during build or installation.

Rather than looking for someone to blame - in this case, GitHub - we should focus on constructive ways to harden the ecosystem.

This is frustratingly one-sided writing. Yeah, WebRTC has limitations, but relying on a standard buys you a lot of correctness and reduces long-term engineering cost. The fact that WebRTC is complicated does not mean it is wrong; it means real-time media over the public internet is complicated.

Also, networking is inherently stateful. NAT traversal, jitter buffers, congestion control, packet loss, codec state, encryption, and session routing do not disappear because you put audio over TCP or WebSocket. Pretending otherwise is not architectural clarity. It is just moving the complexity somewhere less visible.

Yeah, GCC’s recent major releases have been remarkably regular, much like Fedora’s spring releases, and their releases seem to fit into the same broader rhythm. Hint? Red Hat.

Just use Fedora :)

As LLMs improve and adoption grows, maintaining a FOSS project is becoming more complex and more expensive in terms of time and manpower. That part is easy to understand.

It is also become a trend that LLM-assisted users are generating more low-quality issues, dubious security reports, and noisy PRs, to the point where keeping the whole stack open source no longer feels worth it. Even if the real reason is monetization rather than security, I can still understand the decision.

I suspect we will see more of this from commercial products built around a FOSS core. The other failure mode is that maintainers stop treating security disclosures as something special and just handle them like ordinary bugs, as with libxml2. In that sense, Chromium moving toward a Rust-based XML library is also an interesting development.

Does the Python ecosystem have anything like pnpm’s minimumReleaseAge setting? Maybe I’m being overly paranoid, but it feels like every internet-facing ecosystem should have something like this.

It feels like many democratic leaders are starting to think the CCP model—mass surveillance of citizens—is the right direction, with growing demands for chat control, facial verification, age verification, and more. Fxxk any politician who thinks they are above the citizens in a democracy.

Interesting idea overall, and I would support doing this if we can.

Some constraints are:

- Non-programmers are not used to working with Git.

- In practice, they (usually PMs or feature designers) need to write their documents somewhere else.

Possible solutions are:

- Make non-programmers use Git as a documentation tool (upgrade your tooling or GTFO).

- Build a two-way sync tool so that programmers and non-programmers can work from the same source.

  - However, in practice, an SSOT (single source of truth) architecture is usually much simpler. Two-way sync tends to be quite difficult, especially across different platforms.

Damn. Please use UTC.

From my understanding: Peak time (non-promo): UTC 12:00–18:00 / KST (UTC+9): 21:00–03:00 Off-peak time (promo): UTC 18:00–12:00 / KST (UTC+9): 03:00–21:00

I guess I’ll need to do more coding during the daytime.

Atari? I never expected to see that ancient name again. If I remember correctly, I've been playing OpenTTD for more than a decade without the original TTD assets, and I usually build it from source, so this change won’t really affect me. Still, it feels a bit strange (even if it may be somewhat legitimate) to see Atari suddenly asserting rights over it.

Cool. Let’s release Android NDK for Linux arm64 host, too.

The strength—and also the weakness—lies in how WASM is consumed in the browser. During instantiation, JavaScript engines validate the module and reject it if it uses unsupported instructions or features. In practice, due to browser compatibility differences, WASM modules often need to be built in multiple variants, such as a baseline version, a SIMD version, a SIMD+threads version, and so on. This is a significant pain compared to native binaries, which can rely on runtime feature detection and dynamic dispatch.

I don’t think there is a good algorithm (or guts) for differentiating between well-written comments and AI-generated comments.

That’s super interesting—I didn’t know that.

Before modern standardization, maintaining calendars and clocks was typically the responsibility of states or similar authorities, often guided by astronomers. Now it seems that international organizations are effectively following the early UNIX/POSIX model, and astronomers no longer have the same authority over timekeeping.

Yuck. I’ve already noticed compilation times increasing from C++17 to C++20, and this feature makes it much worse. I guess I’ll need to audit any reflection usage in third-party dependencies.

I assume you live in the free world. Some socialist states in history, such as East Germany, pushed child-rearing and early education much further into the hands of the state through extensive state-run childcare and kindergarten systems. That model is gone, and for good reason.

Even with schools in place, the basic responsibility for raising children still belongs to the parents. Schools can support, educate, and compensate to some extent, but they cannot replace parental responsibility.

I also see far too much awful news — in my country, Korea, for example — about terrible parents harassing school teachers because their children are out of control.

Fxxk off, to all political actors pretending this is about child protection. Protecting children is not the job of the OS, the device manufacturer, or the internet service provider. It is the parent’s job. If you cannot supervise, monitor, and discipline your child’s internet use, that is your failure, not theirs.

They can provide tools, sure. But restricting adults because some parents fail at parenting is insane. That is how a totalitarian state grows: by demanding the power to monitor and control every individual.

If you cannot control your children, that is your fault. And if that is the case, you should think twice before having kids.

Well, it’s a clever idea. Discord seems to have intentionally softened its age-verification steps so it can tell regulators, “we’re doing something to protect children,” while still leaving enough wiggle room that technically savvy users can work around it.

But in practice, this only holds if regulators are either inattentive or satisfied with checkbox compliance. If a government is competent and motivated, this approach won’t hold up—and it may even antagonize regulators by looking like bad-faith compliance.

I’ve also heard that some governments are already pushing for much stricter age-verification protocols, precisely because people can bypass weaker checks—for example, by using a webcam with partial face covering to confuse ID/face matching. I can’t name specific vendors, but some providers are responding by deploying stronger liveness checks that are significantly harder to game. And many services are moving age verification into mobile apps, where simple JavaScript-based tricks are less likely to work.

A few days ago, Notepad++ got compromised—apparently by a state actor (or a proxy). And now, today, Windows’ built-in Notepad has a fresh CVE. What a life.

At this point, what am I supposed to do other than uninstall Windows completely? No real sandboxing, a mountain of legacy…

Sorry, the era of free communication is fading. Across middle powers, developed countries, and increasingly North America, governments are tightening the rules around online speech—and often jawboning platforms into going further than the law strictly requires. The list of examples is so long I can’t even begin to type them all.

I tested it a bit yesterday, and it looks good—at least from a structural perspective. Separating the LLM invocation from the apply step is a great idea. This isn’t meant to replace our previous deterministic GitHub Actions workflow; rather, it enables automation with broader possibilities while keeping LLM usage safer.

Also, a reminder: if you run Codex/Claude Code/whatever directly inside a GitHub Action without strong guardrails , you risk leaking credentials or performing unsafe write actions.

Thanks for clarifying. Since I don’t use the LLM features in Xcode, I’m leaning toward skipping this version.

From my years of iOS development—and based on https://xcodereleases.com typically ships two major Xcode updates each year:

- X.0 (September): bumps Swift, SDK versions, etc. It also tends to have a noticeably longer beta cycle than other releases. - X.3 or X.4 (around March): bumps Swift again and raises the minimum required macOS version.

Other releases in between are usually smaller updates that add features or fix bugs, but they don’t involve major toolchain-level or fundamental changes.

Today’s release doesn’t bump the Swift version, which suggests the core toolchain is essentially the same as Xcode 26.2—so it makes sense that the minimum macOS version wasn’t raised either.

Wait…

https://xcodereleases.com hasn’t shown anything since last December, so I assumed Apple had taken a breather from Xcode development, but they released an RC build today?

Anyway, the Swift version seems unchanged (6.2.3), so is this update mainly for the so-called “Coding Intelligence” features?

In any case, Xcode isn’t my favorite IDE—it’s too slow and feels quite different from other major IDEs—so I probably won’t use it for day-to-day coding (though it’s fine for building and debugging).

I think a large part of this comes from the fact that the expressiveness of LLVM’s C++ APIs does not translate well into a “plain old C” style interface. Many of the abstractions and extension points are simply awkward or impractical to expose in C.

On top of that, there is little incentive for contributors to invest in the C API: most LLVM users and developers interact with the C++ API directly, so new features and options tend to be added there first, and often exclusively. As a result, the C API inevitably lags behind and remains a second-class citizen.

Why not take the best of both worlds? Use pre-commit hooks for client-side validation, and run the same checks in CI as well. I’ve been using this setup for years without any issues.

One key requirement in my setup is that every hook is hermetic and idempotent. I don’t use Rust in production, so I can’t comment on it in depth, but for most other languages—from clang-format to swift-format—I always download precompiled binaries from trusted sources (for example, the team’s S3 storage). This ensures that the tools run in a controlled environment and consistently produce the same results.

Suppressing car usage isn’t about punishing individuals; it’s about correcting urban systems that made car dependency the default in the first place. The Lewis–Mogridge position is well established, and making driving less convenient while improving proximity and alternatives is a core principle of sustainable urban planning.

A lifestyle that requires burning large amounts of fuel just to buy groceries, or maintaining water-intensive lawns at scale, only works under very specific economic and environmental conditions. As those conditions disappear, cities have to adapt—even if the cultural shift feels uncomfortable at first.

I get the impression that https://github.com/pytorch/executorch is Meta’s take on TFLite / LiteRT, which is quite interesting.

While reading the README and related documentation, I noticed that Samsung Exynos NPU acceleration was listed, which immediately caught my attention. According to https://docs.pytorch.org/executorch/main/backends/samsung/sa..., Samsung has finally built and released an NPU SDK—so I followed the link to check it out.

Unfortunately, the experience was disappointing.

The so-called “version 1.0” SDK is available only for Ubuntu 22.04 / 20.04. There is no release date information per version, nor any visible roadmap. Even worse, downloading the SDK requires logging in. The product description page itself https://soc-developer.semiconductor.samsung.com/global/devel... does contain explanations, but they are provided almost entirely as images rather than text—presented in a style more reminiscent of corporate PR material than developer-facing technical documentation.

This is, regrettably, very typical of Samsung’s software support: opaque documentation, gated access, and little consideration for external developers. At this point, it is hard not to conclude that Exynos remains a poor choice, regardless of its theoretical hardware capabilities.

For comparison, Qualcomm and MediaTek actively collaborate with existing ecosystems, and their SDKs are generally available without artificial barriers. As a concrete example, see how LiteRT distributes its artifacts and references in this commit: https://github.com/google-ai-edge/LiteRT/commit/eaf7d635e1bc...