studmuffin650

The photos didn't even load for me.

I think the issue isn’t a lack of want for fixing these issues, but the inertia and friction of getting them fixed.

The issues around the transaction ids and process per connection are well known, but the changes to the codebase to fix them would either constitute a backwards incompatible change that would change storage needs or an incredibly large rewrite of the codebase that breaks with decades of assumptions.

The json issue is a lot less of a problem as that’s net new. But some of these changes have been debated for years with no movement (and no lack of willing developers to tackle it) and at some point a fork or rewrite like this will happen. In my mind, all LLMs have done is made this work easier to do. If you have reservations about LLM’s doing this kind of work, no one is forcing you to use it, and I think it shows the utility of LLMs in that these kinds of things now can exist.

I’ve hit limitations of M1 Max pros all the time (generally memory and cpu speeds while compiling large c++ projects)

Airs are good for the general use case but some development (rust, C++) really eat cores and memory like nothing else.

Also important to remember that Google is years ahead of most other AI shops in that they're running on custom silicon. This makes their inference (and maybe training) cheaper then almost any other company. People don't realize this when compared to OpenAI/Anthropic where most folks are utilizing NVIDIA GPUs, Google is completely different in that aspect with their custom TPU platform.

Where I work, we primarily use Ceph for the a K8s Native Filesystem. Though we still use OpenEBS for block store and are actively watching OpenEBS mayastor

Interesting to me that this doesn’t directly integrate with Bedrock. Seems like an easy way to slowly onboard folks to that platform.

This is a feature that’s required in Government environments. You need a check at runtime to ensure that FIPS is set or you run the risk of breaking compliance. Which leads to inevitable audits and endless meetings. I would much prefer a panic causing an issue for 30 minutes vs. endless days of meetings to set up new controls and validations that will make your life more miserable.

As someone who works for a company that’s transitioning out of the cloud into their own data centers, the supply chain factor is difficult. You have to be really good at forecasting and planning with a large upfront cost. But the savings are substantial (up to 70%)

Also eBPF is still in beta for windows and is nowhere near parity with Linux.

I think that’s just the nature of kernel programming. Once you’re running in kernel space, there are essentially no safety guards, which is why kernel programming is so difficult. Any faults that occur in user space causing a seg fault + core dump do not exist in kernel space. Especially since kernel code generally has to be written in C, it can be quite difficult even for the best engineers to get everything right.

Sounds more like a off by 1 bug that was hidden by regexs if I'm reading correctly

What you would be looking for is actually the forks of redis that came about after the license change. This has existed for awhile as a redis alternative, but not a step-in replacement.

The 2 main ones are:

Valkey - run by most of the large corporations (AWS, Google, Microsoft, Alibaba, etc.) that used to have developers assigned to the Redis project doing Open source work and they just run this fork now

Redict - Another fork that seems to have quite a bit of engineers behind it

AWS is putting up good fight

As a follow-on question, is there plans to integrate the AWS CRT under the hood or does the existence of Tokio and async/await negate the need for it?

When I was looking at a security system (and new WiFi mesh system), this is why I went with Ring and Eero. Amazon is many things, but they rarely shut down products AND they have a proven track record of iterating and making things better over time. Ring and Eero have proven to be resilient, work well, and be slowly improved.