virtualritz

I have architect friends. They can't draw, they can't sculpt, they have no clue about art history. Or color theory, if you want to go that far. Usually golden ratio/Fibonacci is kinda where it ends. One of them is a professor of architecture, no less.

That said, I'm sure there are architects today for which some or all of this is not true.

Most of the above are subjects an architect student would have had to learn about and demonstrate profienciency in, to earn their degree, a 100 years ago.

I'm sure the change in architecture's priorities played a role in this too. Industrial materials, construction efficiency. The need to mass produce housing, costs and new social ideals, yadayadayada.

And ofc the modernist rejection of any ornament; even that which is there historically, on existing architecture.

My hope is that in a future where we 3D-print buildings or construct them with robots we will see a renaissance of non-functional[1] beauty/sculpture/texture/color in architecture because the cost difference will be marginal/nonexistend.

But then, architecture is also always a mirror of the period. And from that pov it's not looking so great for beauty making it back any time soon.

[1] Yet functional because how can the happiness/joy of the perceiver of architecture be removed from what should count as functional, in architecture?

Any sufficiently advanced stochastic parrot is indistinguishable from sentience.

I think you're contradicting yourself here.

What they will do remains to be seen. The document at hand is what they're saying.

I.e. less important if we follow your own assessment.

I assumed a basic level of abstract thinking since this is HN.

For the point I illustrated it does not matter. Everything is needed. The record somewhere will not be sufficient to get you your flat back when you return from holidays. Nor will a the police w/o a judge. Or the judge w/o having the the record to look at.

And re. "always a computer": trust me, in Germany where I live, it will not be a computer for years to come. Everything is paper here. :D

Yeah, you do not need an oracle for USDC.

But I don't see USDC being mentioned in my reply or the comment I replied to.

And calling the need for oracles a "hard problem" is a neat euphemism the point of which escapes me. It's not solveable.

As someone else wrote: when something goes sideways with their assets the crypto posse call for law enforcement. Or they bent their own rules (DAO/ETH hard fork, 2016 e.g.).

No, you can set the temp on the one I have. Just let it turned off.

Also the bath is covered with a lid.

Exactly.

It's called the oracle problem. It's the Achilles heel of the whole idea.

And it's unsolvable. As soon as you want to trade some coin for something real, you need an oracle.

Wanna buy a flat in a world where (for argument's sake) even the ownership of that asset is tracked on a blockchain?

Let's say I come home from holidays and someone else lives there.

How do I then prove it's mine? Because it says so in some computer?

Someone has to believe that is true and let me enforce that ownership tie.

Those persons (a judge, the police, even if robots by then) are the oracle.

And a more common scenario than theft is btw legal ownership transfer.

What if I die somehow before giving the blockchain keys needed for that to someone?

How will my brother inherit the flat?

Oracle.

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/