virtualritz

You can wash the print in an ultrasonic bath [1] in isopropyl alcohol (IPA).

Then cure using a UV LED strip (5m w USB plug ~2 EUR) inside an empty can (another 2-5 EUR) and a solar-powered rotating base [2].

The light from the LEDs is cures as well as powers the base. All four will set you back less than 50 EUR.

[1] https://aliexpress.com/item/1005010131053964.html [2] https://aliexpress.com/item/1005012796313088.html

That part we can argue about; the upsetting part, if you bothered to actually read the article, is this:

The WaNPRC says the monkey studies have contributed to an understanding how prenatal domoic acid exposure may affect learning and memory: “These findings remain relevant to public health.”

However, there is no clear evidence that the experiments led to changes in public health recommendations.

TL;DR: whatever your agent told you it wrote and you then "confirmed" experimentally: there is a disconnect with reality ... somewhere.

I wasted more time on this, literally and figuratively.

InlinkeKey microbench results below.

Each row is one pass over n keys with three variants interleaved in one process:

  ┌──────────────────────┬────────┬────────┬─────────┐
  │     n = 65536,       │  std   │ bbtree │ bbtree  │
  │    VertexId(u32)     │ BTree- │  Auto  │ Inline- │
  │                      │  Map   │        │   Key   │
  ├──────────────────────┼────────┼────────┼─────────┤
  │ insert               │ 18.3ms │ 12.3ms │ 20.8ms  │
  ├──────────────────────┼────────┼────────┼─────────┤
  │ get                  │ 14.0ms │  9.2ms │ 16.6ms  │
  ├──────────────────────┼────────┼────────┼─────────┤
  │ iterate              │ 0.74ms │ 0.05ms │ 0.10 ms │
  ├──────────────────────┼────────┼────────┼─────────┤
  │ entry().or_default() │ 52ms   │ 47ms   │ 54 ms   │
  │ .push                │        │        │         │
  └──────────────────────┴────────┴────────┴─────────┘

The same pattern shows at 4k and 1M entries and for the (u32,u32) pair and a (u8,usize) tuple my crate uses. Adding InlineKey makes the narrow keys slower than bbtree without inline keys.

It only beats the trait-less version on the 24-byte edge key. But there it still trails std!

Your post's proven (?) u64 impl is possibly the ceiling for this mechanism on my CPU (Rhyzen 6800H, 8 cores/16 threads). It is at parity with std at 4k to 65k on this CPU and about 10 percent ahead at 1M.

Iteration is where bbtree genuinely wins, 5-15x, but my kernel's time is not in iteration. And I guess that is true for most applications.

You eventually need to add and/or get/read data.

Your mileage may vary.

I tested this on a 3D boolean mesh kernel I am working on (this is swapping out std::BTreeMap, no other code changes):

  ┌────────────────────────────────────┬──────────────────────┐
  │       bench 96..1536 faces         │        change        │
  ├────────────────────────────────────┼──────────────────────┤
  │ union/difference,                  │ +11% to +21% slower  │
  ├────────────────────────────────────┼──────────────────────┤
  │ intersection stage,                │ +16% to +34% slower  │
  └────────────────────────────────────┴──────────────────────┘

Then I thought, maybe this shines when you use big maps. I.e. more dense/complext meshes.

So I used one of my test fixtures, a Nefretiti bust scan with a million vertex IDs:

  ┌──────────────────────────────────────┬───────┬────────┐
  │     cage op (seconds, best of 3)     │  std  │ bbtree │
  ├──────────────────────────────────────┼───────┼────────┤
  │ difference                           │ 84.2  │ 83.0   │
  ├──────────────────────────────────────┼───────┼────────┤
  │ union                                │ 83.2  │ 85.6   │
  ├──────────────────────────────────────┼───────┼────────┤
  │ intersection                         │ 61.3  │ 67.1   │
  ├──────────────────────────────────────┼───────┼────────┤
  │ limit-surface difference (best of 2) │ 123.9 │ 147.2  │
  └──────────────────────────────────────┴───────┴────────┘

I.e. a lot of the claims the post makes probably only hold under a specific and possibly narrow set of use cases the author tested agains.

std::BTreeMap must hold ideally hold up well under any use case for such a map. That always means compromises must be made.

Surprise!!!

That reminds me, my hometown, the city of Hamburg, bought back the public utilities it had privatized in the 90's, following a public referendum, in 2014.

I recall that one reason was prices for electricity and gas going up after the privatization.

Go figure.

Companies that violate GPL & Co don't have to be sued any more.

Someone can reverse engineer the binary, soon for pennies, and publish the source.

The setup misses everything that you could do to let me experience his work in a setting reflecting his time.

An Italian Renaissance palazzo, the house of a nobleman of that time, maybe Leonardo's re-imagined studio etc.

Instead I see a museum that one of my architect friends might get excited (or offended) about but which completely removes all context from the works that the format you choose would otherwise naturally enable.

On that note: getting the colors of the paintings right is also tricky.

When you source these paintings you need to feed their color to a linearization process (as they likely will be in some non-linear color space like sRGB) before applying any scene lighting. And then finally do the display transform. Otherwise horrible things will happen (do happen in your current setup) to the colors and Leonardo will turn once in his grave every time someone opens the website. ;)

That is because rustc really maxes out the cores.

Ask your agent to build a simple bash/zsh/whatever cargo wrapper that maintains a machine build lock.

It should exclude cargo check, tree etc. ofc.

CPU contention from parallel cargo runs absolutely kills (build) performance.

Also my setup has instructions that agents keep working if they have open items while the lock is taken; i.e. launch a subagent or a shell with a watcher to run the build and don't block on it.

This makes all the difference when you have multiple agents on multiple workstreams on the same machine and they target Rust.

The agents are only blocked by this when the features they implement are extremely simple.

The average feature I spec and have an agent implement takes an hour or two (Either Opus 5.5 or DeepSeek 4.1 Flash, both at high and using subagents).

In-between the agents do not build that often because that is instructed in my setup.

They build maybe every 20mins when the target is Rust.

Ofc the models do not work like this by default. In fact they want to build all the time.

But as always, you need to tune the harness/setup for what you're using.

IMHO: if you use these models with Rust w/o those constraints/instructions "you're holding it wrong".

Compile times are really only an issue of you need to iterate extremely fast.

One of my spare time projects is a "prompted" 3D modeling app that is now (incl sub-crates I maintain) about 500k lines of Rust.

The link stage is the longest. An incremental build (w. sccache+mold) where I changed a few source files is done and runs after maybe 20s max on my 2022 Rhyzen 6800H-powered laptop.

I think this is acceptable when working on that kind of project.

For games where this matters I usually prototype in some other language first, TS, Python, Lua, whatever then translate to Rust when game mechanics and magic numbers are settled.

Or you simply put those into a config file that gets watched by the game.

At work we have an image manipulation crate that takes like 30mins to 'dev' and about an hour to 'release' build.

The WASM version takes even longer, about 2h, and needs like 55GB RAM during build.

But that crate has only to be built once a month.

And if it mattered we could split it because it's a metacrate made of ~20 sub-crates.

Yeah, it would be nice if Rust were even faster (I remember compile times almost a decade ago, when I started using it)!

But I think for the typical use cases where you would (should!) reach for it, it's quite ok already.

And if not you can work around it quite painlessly.

It froze my laptop after I clicked once.

Couldn't even SSH into it any more even though Tailscale showed it as alife. Had to reboot.

So this website definitely left an impression.

Did you ever sit in an original MINI? Your ass is so low that you think any bump will bring a bloody visit to the proctologist with it. Literally and figuraitvely.

Or an original Fiat 500? Or a Citroen 2CV?

The charm of them was not least that these cars were small. Very small by today's standards.

A MINI is about (LxW) 3m x 1.4m. A contemporary "MINI" is almost 3.8m x 2m.

Or worse, the MINI Countryman the MINI that wants to be a SUV and a MINI and fails on both accounts.

I fear the new 2CV will just be another weird supersized version of a classic.

All these cars feels like when Hollywood does the n-th relaunch of Spiderman or Batman or whatever because ... capitalism.

Play it safe, don't risk innovating with a new car that could be original and cute and loved by a new generation for what it is, not what it tries to replicate. Because the success of that depends on many factors, only one of which is originality. Whereas the classic has already prooven itself in all of them.

That said, I think the new Fiat 500 is actually not that bad. It's still a car that feels like a proper relaunch of the original ... in some way.

The thing is: there are color spaces, correct filtering etc, etc.

Sure you can do a Photoshop clone as in "Ps in 1990" if you just ask an LLM because then (and for years after) Ps itself got all this stuff wrong and people used it, professionally nevertheless.

But getting these things right requires, as-always, in-depth understanding of the theory behind it or the LLMs will gladly omit those parts.

Not least because the majority of OSS code dealing with those things gets it subtly wrong. And they've been trained on that.

A good start is btw. to ask your agent of choice to copy all theory/basics from OpenImageIO.

How do I know? I'm maintaining a closed-source, heavily LLM-assisted Rust crate that is the backbone of all image processing we do at my employer (kringers fossed it will be OSS eventually).

The amount of subtly-wrong- bites-you-eventually bugs I fixed (or had an agent fix, rather), despite tight specs and good tests, over the last 10 months, is ... noteworthy.

That said, for a lot of users it probably doesn't matter if interpolating between red and green means getting a muddy brown or that you get subtely wrong colors when you downsample and some (or quite a bit ) of aliasing when you do so more than 2× etc.

But while a lot of people want to prompt a clone of app X and an unexpected many also seem to have the patience for it: few have the background to get sth. out of that endeavour that will be genuinely useful in the end.

The CAD/parametric 3D modeling segment is another category I'm watching closely where a lot of people have the same issue w/o (yet) realizing.

And ofc, there are always exceptions where seemingly someone is behind the project who actually do know what they're doing. :)

I recall my first live action blockbuster I got a vfx job on, "Charlotte's Web".

Rising Sun Pictures (RSP) in Australia had pitched for Templeton, the rat. But Templeton had already been given to Tippet.

So RSP got the option to either take Charlotte, the spider, or get no work on the show at all. A scary proposition for a company of 20 people at the time that only done hard-surface work and no creatures until then. They hired a lot of people in a short period and I was lucky to be one of them.

The work coming out of Tippet we saw in the first dailies of Templeton intercut with our work was jaw-dropping. [1]

I also remember feeling weirdly proud to work on a show that had Tippet involed because of Star Wars ofc. But more so because of Starship Troopers which I love. I can't think of any other movie that manages to be an in-your-face critique of facism while at the same time scoring as a "quality" popcorn flic.

I recall Tippet's test footage for the Arachnids being on the Softimage showreel years before that movie was released. [2]

[1] https://www.youtube.com/watch?v=DYFQ9vVqiMA

[2] https://youtu.be/IPcFGleYsgs?t=73

The idea that a fan is also a light is totally alien to me.

If you're into nice lighting, central light from the center/top of the ceiling is another no-no. I.e. the article's domain "mcmansionhell.com" kinda fits this.

I.e. one can read the critique on ceiling fans also as a critique on eye-cancer-causing central ceiling light fixtures. Rotating blades attached or not.

On that note, we installed a ceiling fan in our bedroom to aid with the constantly hotter European summmers.

All fans we looked at were either (a) also a lights and (mostly)/or (b) ugly as hell.

Finally we remembered seeing a beautiful art-deco fan in a retaurant in Italy, a year before, and photographing it at the time. Google image search found the product; boy was it expensive.

The blades are heat-pressed plywood using old/original molds, from the looks of it. [1]

Curiously the Spanish company behind it, Faro, were also among the few fans we had found browsing that we liked.

But they were all very minimalist and for that room we needed something a little bit 'more'; but w/o crossing the kitsch threshold.

[1] https://faro.es/en/collection/cuba-old-gold-ceiling-fan/

Make a cargo wrapper (or ask your clanker) with a global build lock.

Cargo run/test/nextest/run only, check/fmt etc should be excluded.

This avoids contention/oversubscription of the CPU which makes builds up to 300% slower from what I measured.

But your clanker probaly did. ;)

Is this a rip of turtletoy[1] content?

[1] https://turtletoy.net/

See also from earlier today [1].

More or less the same content but parent is much more palpable, IMHO.

[1] https://news.ycombinator.com/item?id=49737985

"Architecture and product design" but no STEP/IGES/BRep output, just triangles?

AI is the subtrate the future runs on.

And so I think the idea is more to understand tomorrow ... from first principles.

In the late 80's, as a teenager, I learned x86 assembly and C because that was the only way to squeeze out enough juice from my shitty CGA (and later VGA) card to programm the games/graphics that interested me.

I haven't written assembly in years.

But whatever I did in my career: it helped me and gave me an edge over my peers to have a foundation that is very close to the metal.

Indeed, looks super uncomfy.

And yeah, I helped a friend who's a furniture designer [1] for a few years.

After a while, when you 'beta test' pieces in development a lot, you understand that looks are great but comfort always wins.

[1] https://www.saschaulber.com/works/

I seems to have the first part in common with Reticulum.

> Rust is comparatively worse, because LLMs don't make the same coding mistakes that humans do that justifies the existence of the borrow checker, [...]

That's a pile of bollocks, pardon my French. Source/proof?

And to the contrary:

I've been working on a TS codebase that calls into C++ native/wasm-compiled code for six months now. The code is mostly LLM written.

Over these last six months we had four use-after-free and two other ownership-related bugs in LLM-generated TS code.

Whereas we had zero issues of any such kind with LLM-generated Rust code that sits in another two native/wasm-compiled metacrates we use.

LLMs are not much better at ownership tracking than humans.

Especially if resource acquisition and release are far apart in code and/or somehow nested/stacked/non-straightforward.

the article opens with the fact that macOS uses 5 times less. The irony seems lost on the author.

I wouldn't find this post less ridicule-inciting than if the title was

"macOS's built-in weather app wastes more that 200 MB of RAM"

I build a tool like this with Claude in 2hs, uses Rust with OpenCV crate, egui GUI, PDF output.

Basically it steps through a folder with images, finds corners, user presses Space if ok, or adjusts corner if not (about 1 in 20 pages has a corner wrong). Undistort, contrast correct based on histogram, etc. happens automatically.

On the last page pressing Space creates a PDF.

My brother and I were digitizing medical bills for our mother and everything we tried to do this with out there was meh, cost money or both! It seems as soon as you need PDF anything it's $$$.

This is a throwaway tool as we're now more and more getting bills as digital files anyway.

My only input was specs, otherwise it's "vibe coded" if you want.

But consider that the Rust crate ecosystem is mature and my prof. background is computer graphics.

Oh, and I have an image manipulation crate that I wrote for work (closed source for now, unfortunately) that has corner pin with area filtering as a primitive.

I was just surprised how possible this is now.

This was earlier this year (Opus 4.8 was just out) and while we were photographing the pages with our smartphones Claude wrote the tool.

But Rust has editions.

That is a big lever language designers can use if they painted themselves into a corner.

Lety me reply to this bigoted trope with an apt Turkish proverb:

The dogs bark, but the caravan moves on.

The one thing I'd put in context is "don't waste time on commuting".

In Europe for sure and possibly many parts of Asia like Japan or bigger metropolises in China etc. most people will commute by public transport.

You can read. Whenever I had a job where I commuted at least an hour a day, the number of books I read, per month, went from 2–3 to 10 or more.

It couldn't possibly be that Blender simply has much more volunteer contributions?

Since hacking on a 3D DCC in your spare time may be more than three times as enticing to people than doing the same on an email client?

I'd wager Occam's razor favors this explanation.