willbeddow

This is a real shame. I love DuckDB, and we've adopted/extended it and ducklake very heavily at Krea for our research.

I know the projects will remain open, and ostensibly still contributed to in the same direction, but surely AWS thinks of this as another piece of a product suite to compete with Databricks.

Nontheless, I think the open embedded query engine approach DuckDB is spearheading is larger than one project, and I remain excited about the broader ecosystem (especially datafusion).

Seems good. I'm a big Waymo user (344 rides) and love it, but I think they violate both traffic laws and common-sense courtesies of traffic in ways not captured by safety / crash statistics. Tickets probably are a great signal for ways the model needs to be improved.

For example, every time a Waymo picks me up from my apartment, it blocks a full lane of traffic on an extremely busy street, rather than pulling into a much quieter side street that an Uber driver will always use. I suspect (but have no idea), a lot of these low-level annoyances might be invisible to someone only looking at aggregated crash statistics, ride times, etc.

In many ways, I suspect the AI future might be better in many of the ways we can measure, but worse in those which aren't legible to statistics.

Increasingly, I'd like the code to live alongside a journal and research log. My workflow right now is spending most of my time in Obsidian writing design docs for features, and then manually managing claude sessions that I paste them back and forth into. I have a page in obsidian for each ongoing session, and I record my prompts, forked paths, thoughts on future directions, etc. It seems natural that at some point this (code, journal, LLM context) will all be unified.

Juice is cool, but tradeoffs around which metadata store you choose end up being very important. It also writes files in it's own uninterpretable format to object storage, so if you lose the metadata store, you lose your data.

When we tried it at Krea we ended up moving on because we couldn't get sufficient performance to train on, and having to choose which datacenter to deploy our metadata store on essentially forced us to only use it one location at a time.

Cool project! How does this compare to something like the OpenBCI cyton?

weka seems to Just Work from our tests so far, even under pretty extreme load with hundreds of mounts on different machines, lots of small files, etc... Unfortunately it's ungodly expensive.

have not used longhorn, but we are currently in the process of migrating off of ceph after an extremely painful relationship with it. Ceph has fundamental design flaws (like the way it handles subtree pinning) that, IMO, make more modern distributed filesystems very useful. SeaweedFS is also cool, and for high performance use cases, weka is expensive but good.

Hmm idk about the focus on aesthetics. GPT image is your top image model, a model which is famously poor on aesthetics (though excellent on prompt adherence). I admit it's a difficult thing to eval, though, as in most side by side comparisons users will always pick the image with better prompt adherence regardless of instructions.

I'm sure this is very nice, but the article reads as if written by AI. The first thing I'd want to see is an example workflow (both code and configuration) in a realistic use case. Instead, there's a lot of "powerful and flexible" language, but the example workflow doesn't come until halfway down, and then it's just foobar