sunnyps

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.

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/

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

The population of Taiwan is 23 million. The population of Florida Keys is 82000. Not the same.

Have you tried Costco pants? They're pretty good.

Yeah, it's a nation. A nation of immigrants. Where did your great-great-great grandfather come from? Did he spontaneously erupt from this common ancestry and heritage that you speak of?

Glad to see that there's support for CPU sample flamegraphs in Perfetto now that's on par with Google's internal pprof visualizer as alluded to in the talk. Using the internal visualizer to share Windows ETW traces with colleagues was the primary motivation for developing [EtwToPprof](https://github.com/google/EtwToPprof). Now that perfetto supports this natively, I might look into developing EtwToPerfetto :-)

That's just the nature of these tools though. For example, Windows has its own powerful ETW tracing framework, but using it for real profiling and debugging requires learning a lot about the tools: https://randomascii.wordpress.com/2015/09/24/etw-central/

Republicans can end the filibuster in the Senate with a simple majority after which they can pass the funding bill with a simple majority. But of course, they won't do that since it opens up other bills to be passed with a simple majority too in the future. So it's not factual.

edit: This is what they would need to do: https://en.wikipedia.org/wiki/Nuclear_option

Would the interface nil example be clearer if checking for `nil` didn't use the `==` operator? For example, with a hypothetical `is` operator:

    package main
    import "fmt"
    type I interface{}
    type S struct{}
    func main() {
        var i I
        var s *S
        fmt.Println(s, i) // nil nil
        fmt.Println(s is nil, i is nil, s == i) // t,t,f: Not confusing anymore?
        i = s
        fmt.Println(s, i) // nil nil
        fmt.Println(s is nil, i is nil, s == i) // t,f,t: Still not confusing?
    }

- `is` for interfaces checks both value and interface type.

- `==` for interfaces uses only the value and not the interface type.

- For structs/value, `is` and `==` are obvious since there's only a value to check.

Ever heard of subpixel rendering? You can have pretty sharp text at even 90 ppi if your OS supports it. MacOS doesn't, probably because they didn't want the complexity of supporting it throughout their compositing/graphics stack, and also likely because Apple doesn't sell any low ppi displays.

So you haven't used a 32 inch 4K monitor which is ~135 ppi? What do you get at that size, a 5K or 6K monitor? Not many of those available and they have specific requirements like higher display port or thunderbolt bandwidth.

There's also an entire world of users still on 720p and 1080p displays. They deserve better font rendering even if it doesn't affect us personally.

Is this basically like Valgrind, but using CPU counters?

Because money paid to the government contractor results in a person (persons?) getting paid along the way and then a large part of that flows into the real economy via consumption / spending.

In your $50 trillion poem example, no money can possibly flow into the real economy because you simply do not have $50 trillion to pay anyone - you're just describing a wash trade of a worthless $50 trillion IOU note not unlike a NFT or crypto memecoin. Best case is that the poem is worth something non-negative.

I think they mean that the code base is small enough to be audited thoroughly. Maybe they should reword it to be clearer.

However, using a transparent color significantly slowed down the number that can be drawn too which doesn't make as much sense to me. I'd imagine that with hardware today transparency should be somewhat free.

That's because transparency limits how you can batch draws on the GPU. With opaque draws, you can use the depth buffer and draw in any order you like e.g. maximizing batching. With transparency, you need to draw things in the right order for blending to work (painters order).

0.1 hours?

If I want to write a ray tracer, well... Good bye life for a week or two.

Lookup this book: Ray tracing in one weekend by Peter Shirley. You're in for a treat :-)

Except that chess is a perfect information game, but poker is not. Which means it's possible to tell if your opponent made a mistake in chess, but it might not be in poker.

Disclaimer: chess novice, don't know anything about poker.