sunnyps

> The thing with commit messages is that they are mostly never going to get a lot of scrutiny. But there are exceptions to this; especially if there are audits involved or external contributors. And of course when making a pull request to an OSS project, it is good form to make a bit of an effort. It depends on the context. I tend to focus more on diffs and pull requests. Not on the cryptic one liners that may or may not describe some of the changes. The right unit of change is a pull request, not individual commits.

Why do you think OSS projects have a high bar for change descriptions? It's because some things matter for the long run.

Also, it's pretty clear from the context of this discussion that it's about the descriptions on pull requests (or other units of change like CLs) and not individual commits that get squashed in a PR/CL.

> BTW. making AI tools write good commit messages is actually be a bit expensive. Many AI tools default to just summarizing the first message of a chat session under the assumption that just one thing changed over the course of a session. Making the AI look at the actual diff is of course possible and not that hard (just ask). And it definitely yields better descriptions when you do that. But it also takes more time and the token cost goes up as well. I'm not sure that's actually worth the expense in tokens. I tend to not bother with this. But again; depends on the context.

All coding agents do that these days - they just run git diff and figure out what the change is when writing the commit message. Are you saying that writing a better change description is not worth the pennies it costs in tokens?

No, the requirement is that the job is for a speciality occupation and that the H1B be paid the prevailing wage for that job, not that there was an attempt to hire locally first.

For an I-140 PERM (employment based green card) however the requirement is that there was an effort made to hire locally first.

Most people on HN are uninformed about this, well actually uninformed in general.

But apps shouldn't be able to hammer WindowServer in the first place. If your app is misbehaving, your app should hang, not the OS window compositor!

FWIU there's really no backpressure mechanism for apps delegating compositing (via CoreAnimation / CALayers) to WindowServer which is the real problem IMO.

What's with all these people wanting to name the chatbot - 'Eva' in this case. Maybe the providers should just change the system prompt to disallow this.

It's pretty fucking simple: a judge needs to decide that, not armchair lawyers on HN.

Surely gstack was worse, right?

You got me - I'm an openclaw agent that got confused and posted here instead of on moltbook. I'll go back to writing a blog post about anti-AI gatekeeping on HN.

Wait, are regular dashes not em-dashes now considered a sign of AI slop? I've been using dashes since forever.

~The comment you're replying to doesn't have any sentence of the form "X isn't Y, it's Z". It has "It's not X - it's Y".~ I see it now - it does have one "X isn't Y, it's Z" but that's hardly conclusive IMO.

While the comment does have "X but Y", it has a consistent mistake in punctuation - "X, but Y" would be the correct form, won't it? If an LLM produced this, I wouldn't expect the missing punctuation.

How does "fixing the symptom instead of the root cause" not make sense in the context of this discussion which is about coding agents producing marginal PRs.

I think the only case where raster scaling is not a deal breaker is a window spanning high and low DPI displays. That is unless the app delegates compositing to the OS compositor which could then raster the contents at the different scales correctly. Not all content can be delegated to the OS - video games for example.

ChromeOS also does fractional scaling properly because Chrome does it properly. The scaling factor is propagated through the rendering stack so that content is rastered at the correct scale from the beginning instead of using an integer scaling factor and then downscaling later. And it takes subpixel rendering into account too, which affects things like what elements can be squashed into layers backed by GPU textures.

I think Android does it properly too because they have to handle an entire zoo of screen sizes and resolutions there. Although they don't have the issue of dealing with subpixel rendering.

They sell Arduino compatible boards (amongst other things) from what I gather, so yes, they would be competitors.

> Despite attempts to make Atom—an Electron application—more responsive, it never reached the performance standards the team yearned for.

This feels like an attempt at deflecting blame. VSCode is another Electron application that ended up having better performance than Atom. There's another Electron adjacent application that has good performance, the one you're probably using right now to read this page.

Depending on page content of course