Recent iOS versions allow you to share only a small subset of contacts, which is really useful for apps like these

As does GrapheneOS with its Contact Scopes permission.

Seems to be HackerNews effect. It's typically instant

I wonder how on earth stuff like x86->ARM translation works so well if games break even after switching from x87 registers to SSE preserving all the logic otherwise...

I think x87 fpu is the only 'weird' floating point units left. I think if you stick with 64-bit double precision floats or 32-bit single precision floats, where the registers are also 64 or 32 bits, all the modern stuff behaves the same. x87 is just weird because registers are 80-bits ... the idea was to have more accurate results from more precision, but it ends up weird because if you run out of registers and have to spill to memory, you typically lose precision.

Edit: since this post was second chanced, I can add on that some of the pre-PC consoles have weird floats too. If they had floats at all. Lots of fun for emulation developers. Even fun for contemporaneous game developers... PilotWings on the SNES comes with different revision accelerator chips and the demo only works properly on the early revision chips (but I think? the later revision chips have more accurate math). The PS2 FPU has weirdness around NaN, Infinity, very large numbers, and denormalized numbers. Etc.

What about arm, with software floats its compiler depending?

It's probably because you have to have weird precision issues where the numbers are calculated ever so slightly differently, and some other effect like a guard being slightly too close and getting clipped by a door where that difference matters.

I debugged some software synthesizer code a while back (like 20 years or so now I think of it) where a build of it on one platform failed because of a precision bug. I can't remember the details, but there was a lot of "works fine on my machine" type discussion around it. Anyway it relied on a crude simulation of an RC circuit reaching very close to 0 asymptotically to trigger a state change, but on something like 64-bit Intel with a specific processor it never quite made it low enough to trip the comparison because of something to do with not flushing denormals.

From an electronic standpoint, making it simulate "it's high enough" as being about 0.7 and " it's low enough" being about 0.01 was far closer to the instrument they were trying to simulate, and making it massively imprecise like that got it going on everything.

Is funny because the only code I have read that flushed denormals was in synth code.

Denormals in audio code are kind of the "perfect storm", because they take ages to deal with - you're suddenly back into softfloat land - and because you have to deal with many thousands of them in a few hundred microseconds.

We take how fast hardware floating point is for granted. I suspect it would be interesting to compare something compiled with softfloat with a normal benchmark and see just how bad it is.

It's a great reason to do your DSP code in fixed-point, which is just integer with a couple of steps you have to write down on paper to keep straight until you get to the end. Or, I do, because I suck at arithmetic. Just do it all in machine-length signed ints, and forget all the mystical world of tiny tiny floating point values ;-)

Fixed floating point has been a mistery to me, and to be fair floting point is too. I know digital synths like Virus or Waldorf all used 24 bit fixed point math DSP.

I remember this dps site with lost of c and delphi code, there is where I found what denormals are.

Nowdays I dont see DPS code dealing with denormals. Maybe the CPU does not have to do it in software anymore? I don't really know.

> I remember this dps site with lost of c and delphi code, there is where I found what denormals are.

musicdsp.org?

> Fixed floating point has been a mistery to me, and to be fair floting point is too. I know digital synths like Virus or Waldorf all used 24 bit fixed point math DSP.

If you imagine scaling a 16-bit value for like a volume control from 0 to 1, then you'd have maybe 32767 for maximum positive, and -32768 for maximum negative. You could convert those to floats, multiply, and convert back to a 16-bit integer.

But you don't want to use floats, you want to keep it all integer. So you make the volume range be from 0 to 255, and multiply your 16-bit value by that. Now you've got a 24-bit value, with a "binary point" between bits 7 and 8. Now the output is way off scale for the 16-bit DAC but if we chop off the fractional part by just shifting the result of the multiply left 8 bits, you've now got your volume control.

Some DSPs will actually do a 16 bit by 16 bit multiply which just discards the lower 16 bits of the result, with the assumption being that both 16-bit values mean "-1 to 1".

I remember there was a huge scandal where Intel's compiler, icc (considered to be the fastest for quite a while back when) defaulted to x87 when it detected an AMD CPU instead of SSE, giving AMD cpu's a handicap (incidentally, that's the reason why x87 used to be much faster on AMD for a while).

A lot of games were shipped with icc, so my guess is they'd work just fine as they were tested with both.

Rosetta uses software emulation for x87 floating point. That's slow, but in practice that doesn't matter much. Mac software never had a reason to use x87 FP, every Intel Mac had at least SSE3 support.

There was at least one reason...

    long double x87me(long double a, long double b) {
        return a+b;
    }

    pushq %rbp
    movq %rsp, %rbp
    fldt 32(%rbp)
    fldt 16(%rbp)
    faddp %st(1)
    popq %rbp
    retq

what is this?

Looks like a demonstration that using `long double` math requires dipping into x87 instructions, specifically the `fldt` instruction: "floating point load ten bytes".

- A new "AI" IDE announced

- It's VS Code

Like clockwork!

This is why I have much respect for the Zed team as they are chasing originality, not just slap something onto VS Code and call it a new IDE.

If both work equally well then why does it matter whether Zed or VSCode is under the hood?

I think the point is that they don’t both work equally well.

Then maybe they shoulda elaborated on that? /shrug

I love Zed code. Sad that Sublime Text is not keeping up.

Once the UI soup around AI dev use has settled (and it's getting closer) I bet you we will see native apps with c/c++/zig/rust backends that render so much faster on all the junctions that aren't roundtrip limited (and yes, that will still matter to many people).

Why would you bet that? It hadn't happened before AI so not sure why it would now. In fact this is why VSCode was even created, because it was easier hacking on a browser renderer than making something from scratch.

These are two of the fastest editors, and I use both, but I don't think they're for the same thing: Zed is for multi-file projects with moderate IDE abstractions (Worse than Jetbrains; better than most others); Sublime is for editing one-off files with syntax highlighting.

On the contrary, I am glad that the Sublime team did not fall for the trends and avoided adding AI slop into the editor

I would bet in time they are vindicated. Then Google et al will release something with much advertising hype about "returning to basics" or something in a couple of years.

Is the extension system in VSCode not powerful enough to make these just normal extensions for a vanilla VSCode executable? Or is everyone just going for lock in, since if you download MyFork, you can't start using some other extension that uses OtherGuysModel?

Back when Cursor was new (before literally everything was AI hype) they explicitly called out that they wanted to do more in-depth integration with the editor than was possible with just the extension APIs.

Presumably that hasn't changed much. If you want to do any large-scale edits of the UI you need to spin up a fork.

I don't know, does Cursor offer anything substantial beyond an extension like kilocode? (I've only used vanilla VSCodium branch with various extensions but they all seem to integrate everything from tab-completion to complete UI agentic take-over very well)

Correct. One could say the same thing for browsers. I suppose on the one hand it's good that it's relatively easy to spin up a new project like this, on the other hand one must swear allegiance to their large software company of choice.

> VSCode

You mean Chromium wrapper?

Chromium? You mean OS wrapper?

OS? You mean HAL wrapper?

HAL? You mean hardware wrapper?

It's also an absolutely basic fork. They haven't even bothered with a custom theme, or custom UI, it's just vscode with an agents window slapped on top.

Weirdly, out of all the vscode forks the best UI is probably bytedance's TRAE

How many forks of VS Code am I supposed to have installed at this point?

My YC2026 startups are an AI agent that automatically manages your VSCode forks, and a public safety computer vision app for smart glasses that predicts whether someone can afford a lawyer based on their skin color

They'll have to compete with these other pending funded companies:

- ai therapist for your ai agents

- genetic ai agent container orchestration; only the best results survive so they have to fight for their virtual lives

- prompt engineering as a service

- social media post generator so you can post "what if ai fundamentally changes everything about how people interact with software" think pieces even faster

- vector db but actually json for some reason

(Edit: formatting)

> genetic ai agent container orchestration; only the best results survive so they have to fight for their virtual lives

AI Agent Orchestration Battle Bots. Old school VMs are the brute tanks just slowly ramming everybody off the field. A swarm of erratically behaving lightweight K8s Pods madly slicing and dicing everything coming on their way. Winner takes control of the host capacity.

I might need this in my life.

Don't forget there's 2 or 3 of each in YC2026.

You'll need a Chromium based app to count the installs for you.

yes

As they (I) say, writing a concurrent Go program is easy, writing a correct one is a different story :)

I think one other major part is that, compared to e.g. make the build process is more-or-less the same for all Go projects. There is some variation, and some (newcomers I want to think) still like to wrap go commands into Makefile, but it's still generally very easy to understand and very uniform across different Go projects

Well, some games like Civ V still manage to work! But they actually had to port it to 64-bit, otherwise it'd have the fate of all other 32-bit macOS games unfortunately...

Well, at least it's beautiful on macOS! (Not really, but that's beyond the point :))

And all this to build a website that can be run on a single server, and even not a beefy one :). SQLite + Go is arguably even easier to start with and it can get you surprisingly far

You can buy a raspberry pi with 16GB RAM and 128GB of SD storage for $150, and point it at a VPS with a static IP for $5/mo. For personal projects (on top of the massive cost savings) it’s much more satisfying to own your own whole server rather than just figure out how to configure something like aws and risk the costs of misconfiguration.

What's the VPS for? Just for a IP that's not your own personal one?

Usually your ISP gives you a dynamic IP address if your on a domestic internet plan, so you can’t map your home to a DNS record. Reverse proxying into a VPS is generally cheaper than adding a static IP address onto your internet plan.

Surprisingly, not at all. Seems to be on par with regular top, despite showing much more information