Being "technology" doesn’t make something interesting. A writeup of the author about their work would have been interesting, but they haven’t even published the code nor written anything about it.
> There's not even any real political message here.
Of course there is, it’s right there in the title of the website. Even making a website to remember these deaths and not other ones is a political choice.
I don’t know if I would say I don’t “care” about the license. I want to respect the FFmpeg license, and considering that my project is a straight ripoff, it would be dishonest to not have the same license. Whether AI-generated code can even be legally licensed or copyrighted is a separate question that hasn’t been decided by courts. I’ll happily comply with whatever experts recommend.
Good answer. Asking an AI coding agent to port a C codebase to Rust is clearly and obviously creating a derivative work. You need to follow the terms of the LGPL license, and your Rust fork of FFMPEG must be licensed as LGPL. Videolan holds the copyright to FFMPEG, and that includes derivative works. LGPL allows you to do exactly what you're doing.
Note that if you convert x264, x265 or any of the other GPL v2 libraries, your Rust version of those libraries will be GPL v2. When builds of FFMPEG are created with GPL v2 libraries, the entire build becomes GPL v2 (which has a more restrictive copyleft provision than LGPL).
Good to know! I have licensed as LGPL so I think that covers it. Rewriting x264 and x265 are in scope so I’ll keep that in mind. I will design the application as well so that those can easily be excluded from compilation to get a pure LGPL build.
These things may not be true in the future. I just meant to describe the current state of the project. With Rust being a modern language and the repository being AI-optimized, I wouldn't be surprised if it grew to have more features. And I hope that Rust can close the gap on performance, it would be a great testament to Rust's usefulness for high performance software.
I suppose “review” is misleading, since I’m not actually reading the code, I’m simply asking Claude to explain what the code is doing. I’ll change that so it’s expressly clear that none of this code is actually human-reviewed.
This is also a great way to ensure the documentation is up to date. It’s easier to fix the comment while you’re in the code just below it than to remember “ah yes I have to update docs/something.md because I modified src/foo/bar.ts”.
People moving docs out of code are absolutely foolish because no one is going to remember to update it consistently but the agent always updates comments in the line of sight consistently.
Agent is not going to know to look for a file to update unless instructed. Now your file is out of sync. Code comments keeping everything line of sight makes it easy and foolproof.
It’s biaised to show this without the dates at which features were introduced. A lot of the downtimes in the breakdown are GitHub Actions, which launched in August 2019; so yeah what a surprise there was no Actions downtime before because Actions didn’t exist.
This is the real questionable part of the graphic. It seems that no-data pre 2018 was just considered 100% uptime (which is hardly historically accurate).
I've checked, current Claude Code 2.1.87 uses Axios version is 1.14.0, just one before the compromised 1.14.1
To stop Claude Code from auto-updating, add `export DISABLE_AUTOUPDATER=1` to your global environment variables (~/.bashrc, ~/.zshrc, or such), restart all sessions and check that it works with `claude doctor`, it should show `Auto-updates: disabled (DISABLE_AUTOUPDATER set)`
This is good info, thanks. Can I ask how you detected that version of axios? I checked the source (from another comment) and the package.json dependencies are empty....
The source repo doesn't have a package.json, so I extracted the version directly from the binary (~/.local/share/claude/versions/2.1.87)
Axios sets a VERSION constant that it uses in user-agent headers, boundaries and errors. I scanned the binary for all references like axios, isAxiosError and AxiosError - the code references the same variable namespace (X1H, Tj, eq), suggesting a single bundled copy. In the minified bundle, that VERSION constant was stored in a variable called X1H. Searching the binary for all references to X1H confirms it's only used in axios contexts:
The bundled version is 1.13.6 - well before the compromised 1.14.1. I also checked that "1.14.1", "plain-crypto", and "sfrclak.com" are all absent from the binary.
Wait what?
reply