I really constantly have to fight the urge to NOT say/write something because it might be obvious or someone might have said it before.
Just say it.
I recently gave a talk about lessons learned in the past, and it felt really awkward, like, "who am I to tell people what to do?". A few days later, a student walked up to me and thanked me for it, because he adopted a practice I had suggested and thought it was useful. And I had troubles sleeping before the talk because I kept thinking about how plainly obvious it was going to be.
I started blogging again when I discovered that indeed, even if it's only me who finds this useful, it makes sense to write about it. As an exercise in writing, or in case there's at least ONE person on the internet who finds it useful.
> Two small fixes, in order. First, each cut endpoint is allowed to slide a tiny bit (up to 60ms) to land in the quietest spot nearby. If there’s a momentary lull in the audio just before or after the original cut point, slide there. The slide is bounded so it can’t cross into a neighboring word, otherwise you’d chew off real speech. Second, from that quiet spot, the endpoint snaps to the nearest moment when the waveform is exactly crossing zero.
Huh, I think the author might be deliberately ignoring how MCP works?
- "CLIs need to be published, managed, and installed" -- same for MCP servers which you have to define in your config, and they frequently use some kind of "npx mcp-whatever" call.
- "Where do you put the API tokens required to authenticate?" -- where does an MCP server put them? In your home folder? Some .env file? The keychain? Same like CLI tools.
- "Some tools support installing skills via npx skills, but that only works in Codex and Claude Code, not Claude Cowork or standard Claude" -- sure, but you also can't universally define MCP servers for all those tools. You have to go ahead and edit the config anyway.
- "Using a skill often requires loading the entire SKILL.md into the LLM’s context window, rather than just exposing the single tool signature it needs" -- yeah, but it's on-demand rather than exposing ALL MCP servers' tool signatures. Have you ever tried to use playwright MCP?
I just don't buy the "without any setup" argument.
Except that when its system prompt is full of instructions, caveats, design principles, gotchas, architecture notes, memories from the past, and personal preferences, at some point it's going to just ignore them outright. Heck, Claude Code won't even use critical instructions from a 100-line CLAUDE.md file sometimes. So you still have to be extremely vigilant about noncompliance.
That is really a bit of an oversimplification IMO. Please check, for example, the Netflix tech blog and read about what has changed in the past 10 years or so when it comes to architecting video processing and video delivery systems. There's a tremendous amount of engineering work there which advances the entire industry. For instance, it's not trivial to add live events to a VoD infrastructure at that scale — it's not like you just add a few more nodes and buy faster encoders.
It's just plain Ubuntu actually! I would provide a fix, since getting a PTY is not enough. I can't open a PR because it's not possible with the way you hosted it.
These LLM-generated blogs aren't going away – they're everywhere. And the best part? You can now instantly push out garbage content at no cost. Traditional writing is not just dead. It's legacy. The real marketer doesn't care. He just slops.
Yeah it's a weird comparison to be making. It all depends on how they selected the quality (VMAF) target during encoding. You couple easily end up with other results had they, say, decided to keep the bandwidth but improve quality using AV1.
This VMAF comparison is to be taken with a grain of salt. Netflix' primary goal was to reduce the bitrate consumption, as can be seen, while roughly keeping the same nominal quality of the stream. This means that, ignoring all other factors and limitations of H.264 with higher resolutions, VMAF scores for all their streaming sessions should roughly be the same, or in a comparable range, because that's what they're optimizing for. (See the Dynamic Optimizer Framework they have publicly posted a few years ago.)
Same experience here – it seems I have to specifically tell it to use the "X skill" to trigger it reliably. I guess with all the different rules set up for Claude to follow, it needs that particular word to draw its attention to the required skill.
Totally agree with you - the dermal exposure is a different pathway, and that could be more clearly mentioned. The fact that these materials are present are not automatically hazards (but they do state that!). I also wouldn't automatically assume that the products marked as red are not safe to use. For me it's just interesting to see that some manufacturers can do without, or less of those components.
The Austrian consumer protection association has just released results on tests of headphones: https://vki.at/Presse/PA-Kopfhoerer-2025 (German article), and found that 40% contained possibly harmful chemicals, including the parts that touch your body.
It's wild. I have children, and I spent a great time researching foods, bottles, toys, etc., but I would've never thought much about doubting the (big brand) consumer electronics that we all use every day.
Just say it.
I recently gave a talk about lessons learned in the past, and it felt really awkward, like, "who am I to tell people what to do?". A few days later, a student walked up to me and thanked me for it, because he adopted a practice I had suggested and thought it was useful. And I had troubles sleeping before the talk because I kept thinking about how plainly obvious it was going to be.
I started blogging again when I discovered that indeed, even if it's only me who finds this useful, it makes sense to write about it. As an exercise in writing, or in case there's at least ONE person on the internet who finds it useful.