HN user

slhck

234 karma

slhck.info superuser.com/users/48078/slhck

Posts0
Comments92
View on HN
No posts found.

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.

Oh, Claudish striking again.

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.

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.)

Still impressive numbers, of course.

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.

While that would be nicer from an end-user perspective, it's something hard to maintain for FFmpeg itself. Consider the velocity of the whisper-cpp project. I'm sure that – just like with filters such as vmaf, which also require building a dependency and downloading a model – precompiled versions will become available for novice users to directly download. Especially considering whisper-cpp is MIT-licensed.

Some thoughts based on my anecdotal experience — but it depends on the price you are willing to pay.

You can get quite good webcams for $100–300 (from Insta360, Obsbot, Logitech maybe …) which work out of the box with USB-C and have mostly okayish software that supports changing things like brightness, white balance, etc. These however still have small sensors and cannot achieve a good shallow depth-of-field (bokeh). Running them at higher sensitivity (ISO), e.g. in darker environments, inevitably causes noise. But if you just want to participate in meetings, it does not matter. I had a Logitech StreamCam and upgraded to an Insta360 Link 2C, which is definitely much better but still not on-par with a proper camera. You should at least get a good keylight or ring light.

The next step up would be mirrorless cameras with built-in or interchangeable lenses made for vlogging, which also can be used like a webcam. They have much bigger sensors and better image quality at a pricing point of $400-1000, e.g. Sony ZV-E10 II, Fuji X-M5, Canon EOS M50 Mark II, … most of them claim webcam support with the provided software. Fuji's software is bad though, so I wouldn't recommend it on a Mac. I can't talk about the other ones. The benefit is that they also have a flip screen that you can use for better framing. They all support webcam modes.

If you have a camera that has an HDMI output and that outputs a clean HDMI signal (without any overlays), you can also buy an HDMI USB capture device and feed that into OBS, which allows you to set up a virtual webcam. There are cheap no-name USB capture cards that produce mediocre images, and more top-of-the line ones like the Elgato Cam Link. This should be the most device-independent variant where you're also not dependent on any vendor's proprietary software.

Since when is the WordPress ecosystem this … bad? I built WP websites 10-15 years ago and it was a quite straightforward experience back then. These days, there seems to be no around themes and plugins that all have very limited free versions, and constantly nag you about upgrading to the pro version, in a million different styles of banners and popups. Hosting providers have made it easier to deploy WordPress in a one-click manner, but anything beyond a basic page (sending email, backups, contact forms) already turns into a nightmare. No thanks!

Gave it a bunch of technical papers and standards, and while it's making up stuff that just isn't true, this is to be expected from the underlying system. This can be fixed, e.g., with another internal round of fact-checking or manual annotations.

What really stands out, I think, is how it could allow researchers who have troubles communicating publicly to find new ways to express themselves. I listened to the podcast about a topic I've been researching (and publishing/speaking about) for more than 10 years, and it still gave me some new talking points or illustrative examples that'd be really helpful in conversations with people unfamiliar with the research.

And while that could probably also be done in a purely text-based manner with all of the SOTA LLMs, it's much more engaging to listen to it embedded within a conversation.

The error occurred right after granting permissions from my Google account. The permissions were granted but I could never access your application page. I just tried again, now I got an "Error handling OAuth callback" after granting permissions. Signing in again does not work either. (I did remove all of the app's permissions in my Google security settings before, so to Google it looked like the application was requesting all of its permissions again.)

Yes, I mean cold sales emails – marketers reaching out to CEOs or other decision makers, selling them staff augmentation services, growth hacking, marketing support, lead generation, design services, etc. They'd claim legitimate interest by "personalizing" the email and claiming that it is relevant for you in a business sense. (Anyway, I don't think that these are fully compliant with GDPR either, because most often, they will have scraped your email address from somewhere, and do not provide a way to unsubscribe.)

Unfortunately, not in a business context, where marketers can claim "legitimate interest" in various ways. Also, in which way would it matter that they are illegal? Random companies keep sending them anyway; there are virtually no legal repercussions here.

Just saw this, and as a small business owner in the B2B market, this sounds very useful. Gmail's existing spam filters do not reliably detect this type of marketing.

I wish your landing page had a simple "how it works" explanation with a screen shot or diagram, rather than forcing me to sign in directly, and also allowing the app to read *and* send emails. Also, I don't see any pricing?

Finally, signing up, I got an error:

Error 1101 Ray ID: 89d4e0957c2f5a44 • 2024-07-03 06:39:15 UTC - Worker threw exception

I agree it would be good to clarify this. I have a product that does some background job processing using Sidekiq and Redis, and it seems that this would not constitute "making the software available", in particular where it says:

Making the functionality of the Software or Modified version available to third parties includes (...) offering a product or service, the value of which entirely or primarily derives from the value of the Software or Modified version (...).

Since the value is not _primarily_ derived from using Redis, I guess it's fine. I am sure the majority of projects using Redis in some way do not derive their main value from Redis.

Sure, the whole point of CRF is to set a quality target and forget about it, or, with ABR, to be as good as you can with an average bitrate target (under constraints). But you can't do that across resolutions, e.g. do you pick the higher bitrate 360p version, or the lower bitrate 480p one, considering both coding artifacts and upscaling degradation?

This is overrated - of course that's how you do it, what else would you do?

That's not what has been done previously for adaptive streaming. I guess you are referring to what encoding modes like CRF do for an individual, entire file? Or where else has this kind of approach been shown before?

In the early days of streaming you would've done constant bitrate for MPEG-TS, even adding zero bytes to pad "easy" scenes. Later you'd have selected 2-pass ABR with some VBV bitrate constraints to not mess up the decoding buffer. At the time, YouTube did something where they tried to predict the CRF they'd need to achieve a certain (average) bitrate target (can't find the reference anymore). With per-title encoding (which was also popularized by Netflix) you could change the target bitrates for an entire title based on a previous complexity analysis. It took quite some time for other players in the field to also hop on the per-title encoding train.

Going to a per-scene/per-shot level is the novely here, and exhaustively finding the best possible combination of QP/resolution pairs for an entire encoding ladder that also optimizes subjective quality – and not just MSE.