Silphendio

It's a 3 bit quant of Llama3-8B. I'm sure there are use-cases for that, but it's useless when it comes to tool calls or coding and I wouldn't trust it's factual accuracy either.

From the flatpak docs:

> A given branch of the Freedesktop runtime has a 2 year support period after which they are declared EOL.

You're right, I must have gotten that mixed up. Sorry.

I guess floats are still mostly deterministic if you use the exact same machine code on every PC.

You don't need to tun the whole game at a fixed framerate, only the physics. That's actually common practice.

The bigger problem is that floating point math isn't deterministic. So replays need to save key frames to avoid drift.

Quake used fixed point math.

Nim compiles to C, and it has a compiler iotion that does this.

Both of those flavors are based on the CommonMark spec. There's just some extra features and some forbidden html.

Choosing names like `App`, `ok` or `get` in a language without namespaces is a bold choice.

JSON 5 is pretty good. It just needs to make the top-level brace and all commas optional, and add proper support for multi-line strings (writing '/n/' at the end of every line doesn't count).

Allowing only valid JavaScript identifiers to be unescaped keys is also a bit quirky (You have to quote reserved keywords).

But they will never change any of that because it would break JavaScript compatibility.

I think the problems with big network were diminishing gradients, which is why we now use the ReLU activation function, and training stability, which were solved with residual connections.

Overfitting is the problem of having too little training data for your network size.

It does work on mobile,but the instructions are cut off.

And it doesn't play like normal solitaire. You can move any card, no matter what's on top of it. That makes it much easier.

I find json5 much better than json, but it has still many of the same annoyances.

- instead of trailing commas, how about making them completely optional? It's not like they are needed in the first place.

- curly braces for top-level objects could be optional too.

- For a data exchange format, there should really be a standard size for numbers, like i32 for integers and f64 for floats.

- parsing an object with duplicate keys is still undefined behavior.

At the very least, division by zero should not be undefined for floats.