Really? I'm daily driving JetBrains IDEs on Apple M3 and don't recognize any if this. Just give it a bunch of extra heap memory (eg 4g instead if 1gb) and it's fast!

I have given it up to 30GB of heap and i tried many different GC configs, i even ran it and my project on ramdisk.

The issue is related to using a monorepo with lots of code in different languages - openening single folders is fine. Ut i want to be able to work on dozens of services in a single window, all other editors manage just fine

I have a similar problem, large monorepo, things have become really bad lately to the point that the cursor is unresponsive. The only workaround I have found is opening each folder of the monorepo in its own IDE instance

Feel this so hard. The opposite is also true where you have a micro-service architecture and cursor faceplants in workspaces with multiple repos. We ended up building cortex.build partly because of this exact pain. Our context engine builds a git-aware dependency/provenance graph so it can stay local and only pull the relevant slice across a massive repo or dozens of smaller ones.

Well the docs say the old way (no Kafka) is on its way out:

"However, this architecture is set to be deprecated in a future release."

So it doesn't stay optional unfortunately. It quite a heavy dependency to include...

Well it only needs to be Kafka-compatible, so personally I hope that things like RedPanda will turn out to be easier to run for this use case than actual Kafka.

Having an S3-compatible store was already a fairly heavy dependency in terms of something to run correctly in production, it's just that most people don't even consider running their own object store at any real scale, they just go to cloud. Whereas running your own Kafka is something more platform teams are already attempting.

Couple of years ago us-east was considered the least stable region here on HN due to its age. Is that still a thing?

When I was there at aws (left about a decade ago), us-east-1 was considered least stable, because it was the biggest.

I.e. some bottle-necks in new code appearing only _after_ you've deployed there, which is of course too late.

It didn't help that some services had their deploy trains (pipelines in amazon lingo) of ~3 weeks, with us-east-1 being the last one.

I bet the situation hasn't changed much since.

>It didn't help that some services had their deploy trains (pipelines in amazon lingo) of ~3 weeks, with us-east-1 being the last one.

oof, so you're saying this outage could be cause by a change merged 3 weeks ago?

Couple of weeks or months ago the front page was saying how us-east-1 instability was a thing of the past due to <whatever chang of architecture>.

Yup, never add anything new to us-east-1. There is never a good reason to willingly use that region.

Yes

Adobe Flex with Adobe Catalyst. Design a GUI in Photoshop, export it to Flex/Flash to add interactivity.

Looked cool during demos. Got killed when Flash died.

Exactly, also requires authentication. How can this be 10/10?

Only available for Google Workspace: Enterprise Plus with the Assured Controls add-on.

Any idea what those are exactly? Does it only work for recipients on teams with SSO? Or is this just gating who can start these supposedly e2e encrypted email threads?

Looks like recipients can be anyone but would be forced to create a guest account if they don't have one. Which sounds like Google meditating key exchange? Which isn't really e2e encryption at least for the initial message.

Only the higher/highest tier Google Workspace users can send these kind of emails. Anyone can read them.

Those option allows storing private key on smart card.

I think this is just to compete with stuff like Mimecast.

Pretty sure admins can still audit emails even if they're E2EE.

There's a clear text password in one of your GitHub Action workflows: https://github.com/dbos-inc/dbos-transact-golang/blob/main/....

That password is only used by the GHA to start a local Postgres Docker container (https://github.com/dbos-inc/dbos-transact-golang/blob/main/c...), which is not accessible from outside.

JetBrains native AI assistant supports Ollama out of the box. No need for a 3rd party plugin anymore.

See https://www.jetbrains.com/help/ai-assistant/use-custom-model...

https://github.com/authelia/authelia?

I've seen this, and the fact that it's written in Go is kind of irrelevant if I have to manage an external service. I just want it to be simple like what other languages have.

Shindig https://shindig.apache.org/ was the reference implementation of this spec. Was pretty novel at the time.