> 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?
JJ can save conflict related state with the change so that you don't need to resolve a conflict in the middle of a stack of changes for rebasing to continue for the remaining changes. Concretely, it uses a "conflict algebra" where it can track the impact of a conflict as it propagates through the stack of rebased changes: https://docs.jj-vcs.dev/latest/technical/conflicts/
Not really very similar at all for the scenario discussed here. Rerere remembers how you have resolved a conflict before. It doesn't let you rebase a stack of commits that result in different conflicts. You will have to stop and resolve each conflict and then `git rebase --continue`.
Avoiding manual conflict resolution isn't really a good thing though - conflicts are an indication that multiple different changes affect some code and you really should think hard about what the combination of them should be. Even what git does automatically already can be dangerous.
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.
The jobs filled via H-1B are not “specialty” positions, everyone knows this. I know that’s what the visa is ostensibly supposed to be used for, but it’s a very silly thing to pretend at this stage. I agree that many are uninformed on this, and my friends who don’t work in tech think someone on an H-1B visa is like a “particle physics PhD” or something, and not “database administrator” or “backend engineer”.
Well, it doesn't matter what your friends think about what a "speciality occupation" is. What matters is what USCIS and DOL consider a speciality occupation - the "speciality" is that it requires specialized knowledge and training which jobs in software development and even database administration would most certainly qualify for. From https://www.uscis.gov/working-in-the-united-states/h-1b-spec...:
> The occupation requires:
> Theoretical and practical application of a body of highly specialized knowledge; and
> Attainment of a bachelor's or higher degree in a directly related* specific specialty (or its equivalent) as a minimum for entry into the occupation in the United States.
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.
what I keep wondering is what kind of laws will be rendered useless with the precedent they'll cause. Can this be beginning of the end of copyright and intellectual property?
Copyright, possibly. Intellectual property more broadly, no. AI has 0 impact on trademark law, quite clearly (which is anchored in consumer protection, in principle). Patent law is perhaps more related, but it's still pretty far.
Doubt it. I'm sure it will have an exclusion where for example using genAI to train on or replicate leaked or reverse-engineered Windows code will constitute copyright infringement, but doing the same for copyleft will be allowed. Always in favor of corporate interests.
Why are you wondering? Any law that limits the ability of capital owners to extract wealth will be overturned, and not just from AI, that's global in every industry everywhere there are humans.
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.
Uhm... the second sentence of the original comment does contain "x isn't Y, it's Z". You missed this... just like an LLM will miss things sometimes, making me wonder if you're one of them, too.
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.
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.
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?
reply