Farmadupe

I'm totally feeling you here as well. Fable is definitely quicker to first output token on `claude.ai` (ie less internal reasoning tokens being generated), and given how much more expensive decode is than prefill, I'm sure that must pay for itself pretty nicely, on top of any architectural changes that they must have made since the opus 4 architecture was locked in.

Yes this is an extremely well known result for exactly the reason you guessed. It's not just abcktracking, asking an LLM to present a conclusion and then justify is also an excellent way to provoke hallucination as the model con concts "any justification that plausibly justifies the words it's already said".

This is the actual reason why openai _invented_ reasoning models, to give them time/space to work out a solution, rather than having to magic a correct solution out of thin air from token 1.

It's less important now that all models do reasoning, but it's still almost always better to make the output come out last rather than first.

Is it too cynical to read the first quote as "when openai catch up, we will restore fable 5 to subscription plans"?

In other words, they're saying "We know have a monopoloy and we will take all of your money until someone offers a cheaper competing product"?

And "We intend to do this as quickly as we can" read as a non-promise then as much as it does now?

---

Well, I am assuming that this is all based on the fact that Anthropic have enough compute capacity to serve fable 5 now and in the future, and they're "only" limiting it in the coming week to get richer quicker. Since compute hardware is presumably relatively un-fungible, I'm assuming Anthropic isn't offering a week of fable-5 for everyone on rented hardware that they're paying exporbitant fees for?

In other words, my cynical read is "if they can serve it under the terms of subscription plans for a week", then they could serve it under the same terms for a month?

2 and 3 bit quants are often closer to gibberish than hallucination, and that'll happen regardless of context.

I shouldn't claim too much, I haven't tried GLM5.2 at 2/3 bit quantization, but if I were a betting man I'd put money on "useless even as a chatbot"

It's amazingly vacuous isn't it? I think the most interesting read was the fact that they were surprised llama.cpp crashed when they used a bad set of commandline arguments.

Although in the section immediately above the observation they claimed that they ran 10 whole completions with 100% success rate. So who knows.

I have to admit I slightly miss the flood of AI-psychosis research papers that seemed to be popping up a couple of months ago. Good to know there's still one or two new ones floating around.

I'm not sure there's a one-stop shop for this at the moment. I think the process is:

* Have a box with sufficient spare (V)RAM -- probably 8G for simple categorization with qwen3.5-4b, and 24G or more for more intelligent categorization with qwen3.6-27b or gemma4-31b.

* Download or compile llama.cpp. Choose a model, then choose one of the "quantized" builds that will actually fit on your hardware. There are literally hundreds to thousands of these per model on Hugging Face.

* Spend half a day tuning command-line parameters until llama.cpp doesn't crash.

* Watch llama.cpp regularly OOM itself, then put it in a systemd service with a memory limit so it doesn't take the entire machine down when it dies.

* Download all your photos to a folder.

* Start vibing a Python script to categorize your images by repeatedly prompting the LLM with each image in turn.

* Spend days tweaking/refining the prompt to try to get the LLM to actually do what you want.

The endgame is one of:

* The local model categorizes your images. Yay.

* The local model is too slow and you give up. Boo.

* The local model is too slow, so you spend $1k-$10k on hardware. Your image categorization task becomes a cover story for buying new gear. Yay.

* The local model can't understand your categorization metric, so you give up. Boo.

* You eagerly await news of the next open model being released. Yay?

* You consider replacing your local model with a frontier model, but then you realize you'd be spending $500 to categorize your photos. Boo.

* You refuse to allow Google/Gemini/Anthropic to train on your nudes. Boo.

Yup, especially when for a lot of us, the price of the frontier subscription has become a cost of doing business over the last 6 months.

If you're already doing big boy stuff with big boy models, then... just carry on trucking!

Only place I'd differ is for vision/OCR tasks. Small/medium open weights models are as good as SoTa, and token prices for prefill are kinda very not worth it for larger batch tasks.

Other thing that people forget is, if you want to have even a smallish LLM as a reliable personal service, you've got to carve out 16-24 of (V)RAM and leave it permanently running.

The latest rounds of open weights vision language models are incredibly good. Like, massively good. Open weights vision capabilities trade blows with frontier models. Over the last few months I'd roughly rank capabilities as Gemini -> {chatgpt and SoTa open weights models} -> Claude.

qwen3.5-2b and qwen3.5-4b are great at document parsing. They can run on CPU

qwen3.6-27b and gemma4-31b are borderline better than the human eye in some cases. Their OCR isn't perfect, but they're seriously good. They can still run on the CPU but you'll be waiting minutes per document.

You can demand JSON, YAML, MD, or freeform text just by varying the prompt. Even if you have a custom template, you can just put that in the prompt and they'll do an OK-ish job.

There's also models that aren't in the r/locallama zeitgeist. IBM released a new 4b parameter model for structured text extraction last week, and there's a sea of recent chinese OCR models too.

IMO the open wights models are so good that in a lot of cases it's not worth paying frontier labs for OCR purposes. The only barrier to entry is the effort to set up a pipeline, and havin the spare CPU/GPU capacity.

If it helps, I mean it in a really literal sense. qwen3.6 27b is currently $3.20 per million tokens on openrouter right now which is way overpriced. As good as the 27b is, kimi k2.5 $3.00 and it's just in another league in terms of capability. There's no reason to spend money on it.

And even alibaba's own qwen3.6-plus is $1.95, so it's kinda easy to come to a conclusion that alibaba (nor anyone else) is really interested in hosting that model.

And don't get me wrong, I fully agree with you, qwen3.6 27b is an amazing model. I run it on my own hardware and every day I'm constantly surprised with what it can zero shot.

I wonder if for a model that small with a permissive license it might not be worth their time to host a commercial grade inference stack?

Might be easier to chuck it over the fence and let other providers handle it as it'll run in almost any commercial grade card?

Also speculating, but I wonder if it might also create a bit of a pricing problem relative to Gemini flashlight depending on serving cost and quality of outputs?

As a comparison, despite being SotA for their size, the smallest qwen models on openrouter (27b and 35b) are not at all worth using, as there are way bigger and better models for less oricemon a per token basis

Using protobuf is practical enough in embedded. This person isn't the first and won't be the last. Way faster than JSON, way slower than C structs.

However protobuf is ridiculously interchangeable and there are serializers for every language. So you can get your interfaces fleshed out early in a project without having to worry that someone will have a hard time ingesting it later on.

Yes it's a pain how an empty array is a valid instance of every message type, but at least the fields that you remember to send are strongly typed. And field optionality gives you a fighting chance that your software can still speak to the unit that hasn't been updated in the field for the last five years.

On the embedded side, nanopb has worked well for us. I'm not missing having to hand maintain ad-hoc command parsers on the embedded side, nor working around quirks and bugs of those parsers on the desktop side

I feel like there's a semi-philosophical question somehwere here. Recursion is clearly a core computer science concept (see: many university courses, or even the low level implementation of many data structures), but it's surprisingly rare to see it in "day to day" code (i.e I probably don't write recursive code in a typical week, but I know it's in library code I depend on...)

But why do you think we live in a world that likes to hide recursion? Why is it common for tree data structure APIs to expose visitors, rather than expecting you write your own recursive depth/breadth-first tree traversal?

Is there something innate in human nature that makes recursion less comprehensible than looping? In my career I've met many programmers who don't 'do' recursion, but none who are scared of loops.

And to me the weird thing about it is, looping is just a specialized form of recursion, so if you can wrap your head around a for loop it means you already understand tail call recursion.

The author is making a deliberate point about undefined behaviour in the article. Hence them not executing worked examples.

In fact, by not doing so they are making a subtle implicit statement that it is uninteresting to consider actually attempting to execute these snippets.

The third paragraph of the "P.S" of the article (you have to press submit to see it) is the one that really gives the game away.

FWIW, 85k 4-input luts is huge by the standards of any softcore with "micro" in the name.

It comfortably surpasses the capacity of most of the Actel aerospace FPGAs that I tend to work with.

And I think it's so "micro" that the majority of all of Lattice's FPGAs wouldn't fit it either.

And the Lattice ECP5 is advertised with 85k LUTs, which would seemingly limit its use to edification as instantiating this softcore would consume the entire chip. For any other purpose if you wanted a chip that was only a CPU, you would buy a CPU.

...could be named for how much space is left after that soft core has been instantiated.

Steppers are super optimized for being super precise and easy to controle while being (relatively) cheap to build.

They have weird "trick" geometry that means you can move the rotor to many different angles (tens, hundreds) with far fewer stator windings.

The cost of this is really low power and efficincy if you just want to spin them.

Out of interest, what could make such a design better than a traditional inductive motor? Such motors already suffer inductive losses, and do not need slip rings or brushes, and presumably do not an additional set of windings to transfer power to excite the stator?

Just could the two sets of coils be optimized for their own purposes?

I know press releases never describe anything that's actually novel, but it looks like they're just describing an asynchronous induction motor? I'm wondering if this release is implicitly pretending that some "low slip ratio" motor is "basically" synchronous

Just guessing, does ZF mostly put out induction motors, and they need to make them look less unfashionable so that people choose them for new designs?

Download counts don't mean very much here as I'm fairly sure both crates are common transitive dependencies. Or in other words, millions of programmers aren't individually choosing Anyhow or Thiserror on a monthly basis -- they're just dependencies of other rust crates or apps.

And agreeing with the other reply, nobody jumps up and down with joy when choosing an error handling crate. You pick the right poison for the job and try not to shed a tear for code beauty as you add in error handling.

Im assuming the "halt and catch fire" thing is only really possible on pre-microprocessor machines built of discrete components, where the individual parts are small enough to overheat by themselves if driven wrong.

I'd guess the physical CPU package of an i386 would cope just fine with the few (hundreds?) of gates toggling in that small loop.

I wonder if it might be possible to do on a modern FPGA, if you artifically create some unstable circuit and pack deliberately it in a corner of the die?

There's probably some AVX512 concoction that would be the closest equivalent on a modern X64. There's probably an easy experiment -- if that concoction makes CPU freq drop and also makes whole-package thermals drop, it /could/ be due to localized die heating.

just a few drive-by comments:

First and most important, the title claims these are safety-critical rules, but the conclusion says that they are only being used on mission-critical projects. I get the feeling that there might have been some late-change copyediting done here, as the content is far too generalizing to be taken seriously in any specific safety critical context, and hopefully the author would have known that.

* Agree that many safety-critical coding standards are a grab-bag of sometimes dubiously-valuable rules.

* Agree with the implication that stylistic guidelines are almost totally worthless, and may distract reviews from their core task of finding functional errors.

* The document states that manual review of large cases may be infeasible, but I have never worked on a project that didn't mandate it. Drudgery goes hand-in-hand with safety-critical, and mindnumbing close review is an accepted element of this.

* Agree that less rules is good, but the author doesn't justify why 10 rules is the best. Unfortunately this is a field where correctness trumps easiness or simplicity, and any class of error with unacceptable risk to life/limb must be prevented. Thus any ruleset cannot justify itself simply because it is small.

* In fact, there are many wordings in this document that are generally-unacceptable because they are admitting incompleteness in the general case (and therefore unsuitability for any safety-critical purpose), such as "Although such a small set of rules cannot be all-encompassing" or "In return, it should be possible to demonstrate more convincingly that critical software will work as intended"

commentaries on specific rules:

* rule 4: "No function should be longer than what can be printed on a single sheet of paper". In my experience, readability is not always improved by limiting function length. The main goal of safety-critical be correct (and hopefully be obviously so). Sometimes splitting up code is harmful to this. (also this is actually a stylistic rule of the kind rejected in the 2nd paragraph of the document.)

* rule 5: In the safety-critical domain, defensive checks and "assertions" are usually considered at low-level-design. It's generally unacceptable for a coder to "just" insert defensive behaviours into the implementation, because all such behaviours must be analyzed for correctness. I don't disagree with the idea behind this rules, but a coding standard is the wrong place for it.

Considering it's allocation-free, maybe it's an ultralight/ simulator for checking large quantities of compiler output? (i.e no VM to create and destroy for every testcase)

Or the same but for testing some verilog/vhdl CPU implemetation in a simulator?

Or since it's only 500SLOC, maybe it's just for fun!

Honestly I think your observation is mostly right... if you don't have a hard performance requirement, then rust probably isn't the best language to write your code in...

GP might have been referring to undefined/invalid behaviour (whether in the language or in some OS syscall or whatever). After the demons came out of your nose you can never fix the problem, so there is no point trying to handle the error.

Otherwise I agree with you, that library code should not fail/crash/exit(1) just because of some judgement about recoverability, and out to clean up after itself before passing control back to the caller. If the user wants to fix some ENOSPC deep in my library by shelling out to "rm -rf /" and then trying again, that's fine by me, and this should be reflected in the API.

Aerospace still uses traditional waterfall processes (usually called the 'V' lifecycle in the industry because if you put a 90 degree bend in the waterfall it looks like a V).

The flow of responsibilities is strictly hierarchical. If Boeing specified to to their outsourcers that the software should have read from two sensors, then the outsourcer would be 'in the wrong' if they didn't implement that. With a strict interpretation of the rules Boeing doesn't necessarily have to check their outsourcer's work (In Safety-Critical the outsourcer has not just a commercial but also a moral obligation to perform all actions with competence)... But at the same time, because Boeing retains overall responsibility for its products no matter who it subcontracts to, it would be a mistake to not double check the work.

So to at least some extent (at least with moral-tinted glasses), it doesn't actually matter whether or not the fault was introduced by the subcontractor or not. Boeing is responsibility either way, Answering your question only tells us if the subcontractor is also at fault.

It's very important to note that in the Aerospace world, the subcontractor's moral duty only requires them to do exactly what they're told to do (assuming that the subcontractor was only reponsible for software design and not systems design). If Boeing told them to use one sensor, then the subcontractor has done nothing wrong if they failed to notice that this was fundamentally unsafe.

Yes I agree such a system is definitely embedded.. I think I was deliberately constructing a straw man in a (bad) effort to poke fun at people such as myself who have 'opinions' on what embedded 'really is'... "640k is enough for anyone" "C compilers are for people who cant write good assembly" etc etc.. https://xkcd.com/378/

I think it's possible to accidentally use that straw man to justify fears when looking at embedded rust.. But as other people have pointed out in this thread, just because rusty interrupt handlers look weird doesn't work any better or worse than one written in C.

1. A huge chain of dependencies.

I think there is another side to this coin though. IMO there are too many embedded shops that overlook reliable 3rd-party code in favour of spending man-hours growing their own code from seed instead. Or if not that you spend days debugging some greybeard coworker's "Oh I think I wrote something like that 25 years ago for a PDP-11, I'll just email it to you.."

But to be honest I don't really disagree all that much -- As much as the embedded world needs to keep up with the times, there's no way that the level of audit required for a reliable embedded project just can keep up with how quickly crates are being changed.

2. A big departure from how things used to be done in this world.

Sometimes I cringe too when takes a massive server board with 9999GB of RAM and a 4g modem and calls it "embedded" just because they screwed it to the side of a helicopter... But if the root question is "will rust be viable on a puny AVR" I hope that the answer is definitely yes.

I'm not 100% sure, but I think the OP was talking about the overhead of lifetime management for objects that don't live for a very long time. Or maybe objects that don't have "interesting" lives.

One example in my head individual strings that need to be constructed dynamically but live for the lifetime of the application (better to leak it with Box::leak or lazy_static! than pollute all code with lifetimes)

Another is writing in lifetimes for single purpose objects that live on the stack and might only ever get passed by ref into a single function and then get destroyed soon after.

Lifetimes are super important in rust and are a core part of the language, but in such degenerate cases they take up a lot of programmer effort for little benefit. In my head a "automatic" solution such as GC /could/ have a home in the language. Perhaps this would make rust a slightly better fit for really complex monolithic GUI apps (word processing, spreadsheets, CAD) where full GC would be performance-onerous but data lifetimes would be too complex for rust's strictly ordered lifetime concept

One of the most thought-provoking aspects of information theory is that when someone says something interesting in a small amount of words, it's indistinguishable from line noise.

tldr; I've never read Overshoot either but I thought the post had an interesting perspective

For context I'm in the safety critical industry where everything is old and slow, and you're slightly more likely to see FPGAs for "traditional" non-signal-processing reasons (bundle of logic with deterministic timing, custom PHY when you can't use a COTS PHY for cert reasons, Heterogeneous backup for an MCU etc). So my own thoughts probably skew a bit old fashioned -- strangely that also means that none of the things that you listed are important in view of the world!

In short, what we see in our graduates' teaching is a wrong-assumption that VHDL/verilog design is a bit like designing for 74-series chips, where you work out that you need to splat down a load of and/or/not gates and individually wire them up to some flipflops. This is reflected in section 18 of the problems, where students are asked to design simplistic low-level entities (sregs, muxes, and a single transparent latch). This is wrong because the true building blocks in the bottom of an FPGA are not individual and/or/not gates so there's no use in designing as if they were.

This leads to a situation where people have done their VLSI/FPGA module at university but they arrive without knowledge of core fundamentals such as: * Not clocking flops with data * Design for even mild levels of concurrency (it's common for courses to never get students to make two FSMs talk to each other even in the same clock domain -- pretty sure this document doesn't do this in section 18) * Thus everyday problems such as race conditions and deadlock will never have been covered.

IMO the very-incomplete nature of such courses also which attempts to pile concepts on top of each other too quickly without adequate explanation means that people come out of courses without really understanding how little of the basics that they know.

I accept that universities only ahve so much time to teach their students, and there is little academic pedagogical value in spending time on specific technologies, but the general poor approach could definitely be a lot better.

tldr; I agree that there hasn't been any revolutionary development in HDLs, but most universities missed the mark on teaching the basics when they first wrote their FPGA courses in the 1990s, and they haven't got much better since.

(P.S. if anyone wants to create a HDL without the crippling expressiveness flaws of either VHDL or verilog, I will personally transmute myself into a solid gold toilet especially for them)