I accidentally made soap once but haven't been able to repeat it. Lye plus oil or butter doesn't seem to work at least :/ Also, haven't been able to make lye – at least ashes plus water doesn't work.

Things that I have made:

* Bronze from copper and tin

* Brass from copper and zinc

* Rose gold from copper and gold

* Electrum from gold and silver

* Solder from tin and lead (while trying to make pewter)

* Thermite from rust and ground aluminum (or directly from scrap metal)

* Reduced iron from thermite, ignited with magnesium and a fuse

* Reduced iron from rust

* Steel from rust and charcoal

* Batter and dough from flour, water, etc

* Caramel from sugar and butter

* Mayo from oil, vinegar, and egg yolk

no offense, but in settings you can use the unhide all feature to show every element rather than having to manually create them

But that’s not the point, obviously! The entire fun is about figuring out what you can do by combining stuff.

My geology classes certainly did not mention sedimentary layers consisting of glass, quicklime, ash, salt, gingerbread, melted butter, and toast, from bottom to top.

that's a grad student topic

Some road designs are risky because they encourage risky behavior. And "risky" is relative. A good driver should recognize risky road segments and drive even more defensively than normally.

This is true - but it’s hard even for “good” drivers to always understand especially on roads they might not be familiar with.

Example: open space on either side of the road, tends to encourage people to drive faster.

Closing that space (whether by buildings, shrubbery, etc ) will slow the speed.

But I will say there are also “obvious” bad designs - the rare far to short on ramp to merge, where drivers don’t understand how to adjust.

Or the one I most frequently encounter are “blind spots” created by the speed of an intersecting road, where a mirror may be attached to a pole / tree, or a sign reminding people to look left right left, or even instructing where cars should be beyond for a safe pull out.

I know of one intersection near me that both has markers on the road(don’t pull out if cars are at or beyond this marker), and a reminder about looking, but still has a high frequency of accidents.

There's some that are purely due to space constraints, favourite pet-peeve example is a highway with an overpass crossing it.

In the rural case, the offramp will branch off first and the on ramp will be after the overpass and the drivers taking each never meet.

In the space constrained case, theres one extra lane that serves both, where the drivers taking the on-ramp cross paths with those taking the off ramp. This configuration is absolutely cursed!

I mean, the strengths of LLMs were always a much better match for the management than for technical work:

* writing endless reports and executive summaries

* pretending to know things that they don't

* not complaining if you present their ideas as yours

* sycophancy and fawning behavior towards superiors

HN is in fact quite receptive to humorous comments. The bar on what's considered humorous is just higher than on Reddit. It's about the signal/noise ratio.

I’ll keep a close eye out for it.

Not just butterflies, birds too! But what selection pressure drove the evolution of these structural colors? Presumably signaling, the opposite of muted, camouflaging colors.

Also, as many might know, blue eyes are the result of a lack of pigment (eumelanin). The iris is translucent, but Rayleigh scattering preferentially backscatters blue photons. Green eyes have some pigment, making them a mix of brown and blue.

Also the blood veins that you see as bluish through the skin are blue for the same reason, due to light scattered in their walls.

I thought they are green.

Definitely more blue/purple.

`spriteframe_t` is defined as

  typedef struct
  {
    // If false use 0 for any position.
    // Note: as eight entries are available,
    //  we might as well insert the same name eight times.
    boolean rotate;

    // Lump to use for view angles 0-7.
    short lump[8];

    // Flip bit (1 = flip) to use for view angles 0-7.
    byte flip[8];
    
  } spriteframe_t;

which is okay to splat with all-ones as long as `boolean` is either a typedef for a fundamental type(*) or an enum – because C enums are just ints in a trenchcoat and have no forbidden bit patterns! The C99 `bool`/`_Bool` is, AFAICS, the first type in C that has fewer values than possible bit patterns.

So yeah, on C99 and C++ this always had UB and could've broken at any time – though I presume compiler devs were not particularly eager to make it ill-behaved just because. But in pre-C99 it's entirely fine, and `rotate == true || rotate == false` could easily be false without UB.

---

(*) other than `char` for which setting the MSB is… not UB but also not the best idea in general.

And, indeed, if you look at the author's writeup, you see exactly that the generated code satisifes `(rotate == true || rotate == false) == false`, since rotate is checked explicitly against 0 and 1. The essence of the difference is:

> When boolean is an enum, the compiler does exactly what I expected – the == false condition checks if the value is equal to 0, and the == true condition checks if the value is equal to 1.

> However, when boolean is actually _Bool, the == false check is transformed into != 1, and the == true check is transformed into != 0 – which makes perfect sense in the realm of boolean logic. But it also means that for a value of 255, hilarity ensures: since 255 is neither 0 nor 1, both conditions pass!

So a value of 255 also makes both checks fail for the enum, but because of the ordering of the code, it was expected to evaluate as != false.

Had the check: ``` if (sprtemp[frame].rotate == false) ```

been written as: ``` if (sprtemp[frame].rotate != true) ```

then it would work for the `bool` type, but not the `enum` type, at least in C23 mode. Assumedly the C++ mode (effectively) treated the boolean as an enum, or possibly as `false == 0`, `true != 0`.

Maybe changing the type of the variable to int was the better solution?

The "Making it work" section seems to abruptly end at the following?

  By modifying the instruction operand!

  2A      ld a, [hl+]
  D6 08   sub a, 8

Aah you're right. That was from my vomit draft and forgot to tidy it up. I'll update the post soon

Thanks!

Unlike in image/video gen, at least with LLMs the "best" solution available isn’t a graph/node-based interface with an ecosystem of hundreds of hacky undocumented custom nodes that break every few days and way too complex workflows made up of a spaghetti of two dozen nodes with numerous parameters each, half of which have no discernible effect on output quality and tweaking the rest is entirely trial and error.

That's not the best solution for image or video (or audio, or 3D) any more than it is for LLMs (which it also supports.)

OTOH, its the most flexible and likely to have some support for what you are doing for a lot of those, and especially if yoj are combining multiple of them in the same process.

Yes, "best" is subjective and that’s why I put it in quotes. But in the community it’s definitely seen as something users should and do "upgrade" to from less intimidating but less flexible tools if they want the most power, and most importantly, support for bleeding-edge models. I rarely use Comfy myself, FWIW.

That’s probably true only as long as subscription prices are kept artificially low. Once the $20 becomes $200 (or the fast-mode inference quotas for cheap subs become unusably small), the equation may change.

This field is highly competitive. Much more than I expected it to. I thought the barrier to entry was so high, only big tech could seriously join the race, because of costs, or training data etc.

But there's fierce competition by new or small players (deepseek, Mistral etc), many even open source. And Icm convinced they'll keep the prices low.

A company like openai can only increase subscriptions x10 when they've locked in enough clients, have a monopoly or oligopoly, or their switching costs are multitudes of that.

So currently the irony seems to be that the larger the AI company, the more loss they're running at. Size seems to have a negative impact on business. But the smaller operators also prevent companies from raising prices to levels at which they make money.

There's no way around the cost of electricity, at least in the short term. Nobody has come up with a way to meaningfully scale capacity without scaling parameter count (≈energy use). Everybody seems to agree that the newest Claudes are the only coding models capable of some actually semi-challenging tasks, and even those are prone to all the usual failure modes and require huge amounts of handholding. No smaller models seem to get even close.