tpetry

Honestly, if the database is not able to be run with a variety of queries other than the one used by ClickBench then don't submit it to the benchmark. Every other database in their list can run anything you throw at it. Hiding behind messaging that it was an early 0.4 build that can't do everything is ... weird! Just don't submit it to ClickBench if it is not usable by the world yet.

I hope they don't allow pgrust in again until the project matured. Otherwise the benchmark will be useless as it gets flooded by many projects that can run ClickBench fast but have questionable support for everything else.

The article says that other models are better at performance or cost. But whaz is not mentioned? Models that are _better_. From my testing, most models are much worse. And if you do an analysis on quality/performance/cost no one is beating Jev. Heck, no one is beating it at performance and cost at the same time.

There‘s a lot of hype with many releasing their decision models the past weeks. But all are worse. So maybe the years they spent in stealth is something you cant replicate in two weeks?

And the 'better' ones are slower and cost more for a tiny bit more accuracy. Its hard to sell that as being better when speed and price have been JEVs main selling points.

Oh I dont disagree that it does replace some jobs. Why use junior developers when AI generates the same quality?

Just that comparing LLM to a compiler is nonsense. Because one is deterministic and the more using it, the better the quality will get.

Its a false premise so often repeated. I am really tired. Compilers are ruleset: If you pass it one statement it'll produce the same output all the time. Its easy to verify it works. And if enough people have used it before and found no problems, there probably aren't many. Spoiler: People always find niche bugs.

But an LLM will generate you two completely different things today and tomorrow. Heck, even if you stash its changes and redo the same prompt.

They are NOT comparable at all.

Did you even read the article? They show that a perfect index for their query didnt help because Skip Scan is currently not used for DISTINCT queries.

Its running for 15 minutes and then must shut down for a long time to cool down. Thats exactly why those "science-fluencers" said its a dumb idea. This is far away from proving that its a viable idea.

Sam is always shitting on others. For years he has been screaming how bad PostgreSQL is compared to MySQL. Until getting silent about this topic for a few months and then launching PostgreSQL support. Seems he had to realize than the market for PostgreSQL is too big to ignore.

And there is no single company developing. Its a healthy mix of engineers from many companies. A perfect model to prevent this issue here of being aquihired.

The article suggested using TimescaleDB which has its own concept of IVM: continuos aggregates. And compared to the approach by ClickHouse it can also update the materialized views when you update/delete old raw data

https://sqlfordevs.com/books+courses/timescale/05-continuous...

You‘re not the only one interested in this. But seems its a big change that would have to change many parts within DuckdB:

https://github.com/duckdb/duckdb/discussions/8444

The question is more what this really solves. They said they built all this because DNS propagation was too slow. But secondary dns servers by e.g. your isp will still have old records when you change something. So what did they earn? Every is correct within their network pretty fast. But for a normal user there isnt any difference because 8.8.8.8 or 1.1.1.1 still cache old records?

Sometimes similar articles are merged into one. Including the comments.

You immply that a testcase exists for every weird edge case. Especially filesystem and concurrency is things you can barely build test cases for.

Even a 100% test coversge is far away from verifying all behaviour.

These are for type-checking. Transpiling takes barely any time.

And Planetscale (who is the current primary maintainer of vitess) is developing a Vitess for PostgreSQL.

There will be a couple of production-grade PG vitess solutions the next months.

This exists, its called a user. You just use different database users for this.

Yes. You‘re getting charged. But a dollar for your entire bunny account (not for every service or domain) is not that much to ask for.

I wish for the sme. Right now I‘ve created specialized edge functions to e.g. make a deployment which has the global access key.

So, my scripts on my servers dont have the bunny api key. Its only saved within those edge functions and I authenticate against the edge functions.

A little bit more effort than scoped keys but it works

Can you clarify why the node permission system is broken but the deno one works? For an outsider like me both look like the same.

That has also been implemented recently. With staged publishing the author must verify a new release with 2FA so automated attacks dont work anymore. Some human in the loop must verify a release.

SolarCity pretty much failed. Wasnt there an article recently that their projects per year is super low?

I am wondering about the last part of glibc malloc. Isnt that exactly the problem reported for the last 10+ years with glibc? And the common solution is to use tcmalloc or jemalloc which hasnt these problems?

I do understand why all of those bot scores are so high. But netherlands? Are there big datacenter providers I dont know of that are used by bots?

You can still update to new versions even if the new release is still in cooldown phase. You just have to be explicit that you want the new release.

pnpm audit —fix for example will whitelist releases in cooldown phase when theres a known security issue for a version you currently use.

And a bug in a dependency you can fix easily. One in the runtime is much harder to fix and you then must compile new versions.

When you disable that, its also disabled for sudo operations when unlocked. it basically disables TouchID completely.

I would love to have a mode that I must use my long password to unlock my mac for security purposes. But when unlocked, use touchid as an alternative to my password for convenience.

So just the normal TouchID mode but not for unlocking the mac.

Oh there will be a lot of issues in the future because Germany says thst your company is in Germany because you work from there. So you have to do taxes in Estonia and in Germany. And prepare for a lot of tax issues if you dont have a good tax advisor.

I do understand why all these steps are required. And they are good. But how should zero-trust architecture solve that? You‘re still authenticated what the core problem is.