I've tried Chinese models extensively over the last 1 year I've been working full-time on this project [1]. They're borderline useless. 90%+ of my code is written by Codex, and perhaps <10% by Claude and myself.
> Can you share any example prompts where Chinese models aren't good enough?
Nobody is prompting any more, it's more planning, automation, guardrails and reviews. For example, if your tests report that there's a 40% slow down in a particular type of analysis, you have to review possible causes, and approve a plan involving multiple agents to find solutions that won't break 50k tests. And that solution itself is a small part of the work that gets planned in a day.
Codex and Claude are the only tools that work for me, inspite of testing almost everything out there to save costs.
I don't think it helps if they're just random icons. Look at https://github.com/orgs/community/discussions . I went there a few days ago and immediately was distracted by all the random emoji icons scattered everywhere, and none of them provided me any useful information. I swear this is a new thing because it was just that noticeable. I had to put them in my adblock list.
I don't understand why this is strange to you, some people just do things out of personal satisfaction and/or building their legacy. If it's just money, Deepseek founders are already rich because they have a hedge fund company (High-flyer).
Concrete example. Let's say GitHub will add AVIF support at some point (it's not yet handled well by the site as you can notice[1].
You as user can then upload AVIF images to wherever images on the site are processed. And after that, let's say when newer codec inside AVIF will get a good browser coverage, you'll be able to start using it without waiting another decade for GitHub to pipe it through their site code.
For formats without a container, it's always a two step process. Browser coverage first, then another huge period of sites support catching up.
This is not the case. Zod's release CI was not triggerable via commits/tags by design. It used environment-scoped trusted publishing, which requires a GitHub token with elevated permissions. No releases of Zod or Standard Schema were sent to npm. Their security advisory is very misleading in this regard, which is why I tried to clarify the situation in my comment. [0]
Zod maintainer here. As others have noted, this was three weeks ago and no malware was shipped in any release.
Zod's releasing CI was never triggered and it was not vulnerable to this kind of attack. It uses environment-scoped trusted publishing, so a regular push credential is not enough to trigger releasing. There's a security writeup from the NPM team here[0], though it strongly implies that malicious versions of Zod and Standard Schema were caught by their malware scanner. That's not the case. The attacker was not able of triggering Zod's release CI in the first place. I clarified this in my followup comment[1] and asked them to pick more accurate wording to avoid unnecessary FUD like this.
It seems like a git push credential, probably an SSH key, was exfiltrated from my local computer. The attacker used this to try to push malicious versions of Zod, Standard Schema, and nub. The release workflows for Zod and Standard Schema were not vulnerable against this. (Nub was, however, a release run was triggered, and npm's malware detector did flag it and prevent publication.)
It seemed shady to scrub the commits from history, and it still isn't obvious that doing so is better from a security standpoint. But since there are concerns around git bisect, etc, I've done so anyway. v4.6.6 will lose provenance, v4.6.7 is being released.
Since I don't know exactly what else what compromised, I've also done a fresh OS re-install and rotated all creds present on the old machine at the time of the compromise. All my packages have been switched over to staged publishing, which requires 2FA for any release.
Ironically this likely happened due to some work on an OS-level sandbox for Nub's package manager, designed to limit the blast radius of malicious lifecycle scripts. The attack is consistent with an more primitive precursor to the modern Shai-Hulud-style worms. While working on the sandbox, an ersatz agent likely executed a compromised version of some package on npm in a test run. I had safeguards against this (filtering out any OSV-flagged packages, etc) but perhaps there's an undiscovered malicious package. Future work on this feature will happen on an isolated VM.
Instead or alongside this, how about making notifications good? There's some concrete simple improvements that would help triaging in general.
1. Provide ways to filter notifications of a specific state (merged, shipped release, closed) so these can be handled in bulk easily
2. Filter by type (issue / pr / release)
3. Provide access to the done state as a filter and via the api, so we can use non github website tooling to manage the notifications
4. Filter by author (e.g. let me filter dependabot notifications so I can handle them in one pass)
5. Show and allow filters on PR check status so I can look at PRs that are ready for a quick next step rather than ones that require digging into failures etc.
6. Make this all available properly via the API so I can let my clanker interact with this stuff based on rules that it has to help me triage stuff. Right now there are enough missing fields from the notification APIs that it makes it impossible to work around the shortcomings of the notifications with tooling (without screen scraping /notifications).
All of these things would be better for interacting with work to be done.
A general rule on this is if the information would make it easier to understand what work is to be done, to choose it, to act on it in bulk or in batches of similar actions, then that info belongs in the UI and the API.
---
Also. Please make it possible to subscribe to a discussion comment, but unsubscribe from a discussion. I want to read replies to this comment, but don't care to get a notification on every reply to this entire discussion. Unsubscribing. Tag me if you want me to read a reply here.
It's great to add new features, but couldn't GitHub fix the essential ones first?
Just this week, I encountered the following problems:
- a diff showing "0 files changed" while there are many [1];
- suggested changes in a PR not rendering the original line [2];
- bug trackers not showing more than the 40th page [3].
Might seem nitpicky but it was just over the last week... I have a whole bunch of other bugs on my mind, and unfortunately, it's only gotten worse over the years. To the point where I almost don't care anymore.
Now that is crazy considering the language isn't publicly released and doesn't even have a release date; ostensibly, acceptance by Linguist includes evidence that the language is actually being used [1]. I didn't think an interminable private beta counted, seems a stretch of the word "actually".
Why would anyone ever need ACP? I'm not trying to be an asshole. I just seriously don't understand the value proposition.
Edit: lol, I don't think ACP is even actively developed anymore. It seems to have been merged into another seemingly pointless standard with an even worse name, A2A. [0]
Firstly, it's awesome that you are using @sqlite.org/sqlite-wasm for your client-side SQLite database. We really like wa-sqlite ourselves.
We're currently implementing this proposal https://github.com/orgs/powersync-ja/discussions/376, which will speedup the sync throughput a lot - this was a natural next step for us as we have users with massive datasets (syncing a million plus rows).
Sidebar: What has your experience with OPFS+SQLite been like on sqlite-wasm? We have seen our fair share of issues on Safari/web kit.
I've encountered a few soundness holes in rust-lang in practice, but they've all been fixed before I managed to shoot myself in the foot with any of them:
• `std::mem::uninitialized()`. It's now deprecated in favor of `MaybeUninit`.
• `#[no_mangle]`. It's now `#[unsafe(no_mangle)]`.
I don't believe I've constructed cvs-rs's hole by accident. cve-rs's code links to https://github.com/rust-lang/rust/issues/25860 , which is admittedly still open after a decade. Progress appears to still be ongoing though! Related:
> Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: [...]
Thanks for sharing a concrete example of Fil-C's limitations! Disappointing - but not unexpected - to see it underperforming existing sanitizers. I was hoping for better.
> Can you share any example prompts where Chinese models aren't good enough?
Nobody is prompting any more, it's more planning, automation, guardrails and reviews. For example, if your tests report that there's a 40% slow down in a particular type of analysis, you have to review possible causes, and approve a plan involving multiple agents to find solutions that won't break 50k tests. And that solution itself is a small part of the work that gets planned in a day.
Codex and Claude are the only tools that work for me, inspite of testing almost everything out there to save costs.
[1]: https://github.com/orgs/tsoniclang/repositories