Really impressive performance from the Moondream model, but looking at the results from the big 3 labs, it's absolutely wild how poorly Claude and OpenAI perform. Gemini isn't as good as Moondream, but it's clearly the only one that's even half way decent at these vision tasks. I didn't realize how big a performance gap there was.
Funnily enough, Gemini is also the only one able to read a D20. ChatGPT consistently gets it wrong, and Claude mostly argues it can't read the face of the die that's facing up because it's obstructed (it's not lol).
I'm not sure why they haven't been acquired yet by any of the big ones, since clearly Moondream is pretty good! Definitely seems like something Anthropic/OpenAI/whoever would want to fold into their platforms and such. Everyone involved in creating it should probably be swimming in money and visual use cases for LLMs should become far less useless with the reach of the big orgs.
Oh sure, a nice emailing experience (compared with SES) seems positive. But there are negative comments like Cloudflare shipping this is net negative, so just trying to understand the context.
Everyone asking why this exists when DuckDB or PostGIS or the JVM based Sedona already exists, clearly has not run into the painful experience of working on these large geospatial workloads when the legacy options are either not viable or not an option for other reasons, which happens more often than you might expect! And the CRS awareness!!! Incredible! This is such a huge source of error when you throw folks that are doing their best, but don't have a lot of experience with GIS workloads. Very expensive queries have had to be rerun with drastic changes to the results, because someone got their CRS mixed up.
I don't get to do geospatial work as much anymore, but I would have killed for this just a year ago.
I usually start with PostGIS for single-node workloads and then switch to Exasol when I get to truly massive datasets (Exasol has a more limited set of spatial operators, but scales effortlessly across multiple nodes).
It will be great with some more options in this space, especially if it makes a smooth transition from single-node/local interactions to multi-node scale-out.
I doubt this hypothesis, because duckdb written in c++ should be able to tolerate memory failure, while this written in rust has to deal with rusts memory allocation failures are panic's behavior.
That is to say that if the issue is duckdb running out of memory, it is most likely because the rust implementation is using memory more efficiently for whatever query is crashing duckdb, rather than graceful handling of memory allocation failure.
Where it is possible in c++ to gracefully handle memory allocation failure, it is not really a thing in rust I'm not even sure whether it is possible to catch_unwind it.
I say this as a rust person who doesn't fancy c++ in the slightest...
You cannot use the rust standard library in environments where arbitrary allocations may fail but neither can you use the STL. The difference is the rust standard library doesn't pretend that it has some reasonable way to deal with allocation failure. std::bad_alloc is mainly a parlor trick used to manufacture the idea that copy and move fallibility are reasonable things.
I wouldn't wager a nickel on someone's life if it depended on embedded STL usage.
I’ve never seen anyone try to catch allocation failures in C++ code and in many cases doing so correctly is very difficult, not least of which is that writing exception-safe code is the exception, not the rule.
This is cool, but if you're ever in need of a dope present, especially for someone like your father-in-law, Better Geiger[1] is awesome. My FIL was stoked. Loves checking the bananas at costco and other random stuff at costco.
The Fill function for interpolation is really nice, but there's so many different ways to perform interpolation I'd like a lot more detail on what methods are available and which is used by default.
Indeed. Previously, when computing latency histograms from sampled events, I've abused DuckDB SQL cross join/cartesian products to generate zero values for "empty buckets" within a single SQL statement [1]. But makes the SQL unnecessarily complex & slower too, so I quickly moved that empty bucket rendering functionality to the frontend...
Feature author here. The new FILL uses linear interpolation (and extrapolation at the ends). There were a bunch of other algorithms requested (e.g., cubic splines), but the syntax was not clear.
I think the real solution is to add support for non-aggregate window functions in the catalogue. Right now, they are all hard-coded, but if they were extensible, there are a number applications in addition to filling that could be supported.
I genuinely think book reading is the killer app for foldable devices. A bigger screen for a movie or TV is nice to have, but not a game changer. When you have that much screen real estate you can get a really enjoyable experience reading a novel or just easily read a textbook or research paper in a way that's simply not possible on even the largest of what you might consider a typical size phone.
Plus, you no longer need to deal with buying and maintaining a separate device like an iPad! This is why I suspect Apple is dragging its feet on the foldable category, besides letting the screen technology mature. It will probably cannibalize some sales from that market segment.
I find my phone much more comfortable to hold than a book. It fits my hand.
You only read one sentence at a time anyway. I rather scroll, keeping the current sentence in the middle of the screen than jump around with my eyes in an open book, and having to turn pages, or keeping them flat.
Am I missing something? (Real question. I read a lot!)
Reading PDFs is the biggest case. PDFs do not (typically) dynamically reflow in a way that's usable and generally suck to read on a small screen as a result. Source: read a lot of PDFs on mobile.
Not how I read when I read on paper & this bothers me on a phone a lot.
I'm not functionally dyslexic, but all the words pop out at the same time, you could say I read verbs, then tense, nouns after and then I read adjectives in a sentence.
But English is also my second language, so my first language's grammar probably fits closer.
Oddly enough when I first encountered lisp, the nested pile of map, fold and filter was easier because of the well trained habit of restructuring after reading verbs.
Your eyes can skip around and read a lot faster. Most things I read have me skipping around quite a bit. The only time I'm straight-linear with reading is in fiction, and for that I've moved to audiobooks.
Fair question and I read a lot on my phone too! I think the use cases that come to mind for me are comics/graphic novels and research papers. Both of these are kind of annoying to read on phones right now.
Though I agree with you that a larger reading screen would be very nice, I doubt such an experience on a device that offers endless digital distractions will reverse this downward trend - not that you said it would.
Kindles and their competitors have pretty much perfected the devices for this market. They are cheap, high quality, and last long. The few people who like to read do not mind carrying a dedicated reader. However a foldable eink reader would be interesting.
It could go both ways though. Phones get more heavy use, and foldables will probably always be more fragile than iPads, so they might wind up with more customers replacing a more expensive device more often. iPads last a really long time, which was talked about as a problem for Apple's revenue. Some day we might even get a foldable iPad.
Also I doubt that Apple's foldable phone will cost the same or less than Samsung's, as is suggested in the article...
Exactly. Apple is adding so much to iPadOS 26 (e.g. new windowing features) that it resembles the Mac. The next foldable iPhone will be like the iPadOS prior to version 26, so that Apple can make sure iPadOS remains more powerful than iOS.
For your second, I think you don’t understand why people buy/use iPads. First off, I don’t really know anyone who uses an iPad mini for anything productive (other than as a test device). A 7-9” screen is just not useful compared to a 13” iPad for things like Sidecar or reading sheet music in live performances. The 7-9” screen being an unfolded phone doesn’t change this.
A folding iPhone could eat the iPad mini, but that’s never been a cash cow for Apple or something power users cared about - it’s more of an “iPod touch” for kids. (And frankly, the Switch 2 kind of obsoletes it.) The thing that would eat 13” iPads’ lunch is something more like Apple Vision.
Weirdly enough, the iPad Mini is probably the iPad most used for work. The size & weight are perfect for many scenarios. Pilots, warehouses, and field work of all sorts.
For me personally, it's my travel machine. I've done all sorts of things with it on the road. From SSH to using Photoshop to make some last minute edits. It (barely) fits in my pockets so I don't even need a bag for it. Probably my favorite machine ever at least in terms of form factor.
Screen size does seem to be a personal choice. For me, I've always liked small screens for portability. I'm the weirdo who actually got work done on the first gen Asus EEE PC and didn't mind it. But I can understand that wouldn't be for everyone.
The iPad Mini form factor with cell connectivity is pretty great when you're travelling light.
My normal international travel load-out is a backup smart phone + an 8" LTE tablet with eSIM + bluetooth keyboard. It's about as minimal as I can get while still having a real keyboard and functional screen size to handle travel logistics.
Pilots use iPads for all of the charts and checklists. Even having two iPads (one as a backup) is much lighter and thinner (and easier to update) than the paper copies it replaces.
reply