AFAIK there is no Rust compiler for Plan 9 or 9front. The project is using a dialect of C and its own C compiler(s). I doubt adding Rust to the mix will help. For a research OS, C is a nice clean language and the Plan 9 dialect has a some niceties not found in standard C.

If you really want Rust, check this https://github.com/r9os/r9 it is Plan 9 reimplemented in Rust (no idea about the project quality):

R9 is a reimplementation of the plan9 kernel in Rust. It is not only inspired by but in many ways derived from the original Plan 9 source code.

There isn't, though you can run it over wasm on it. I tried it a while back with a port of the w2c2 transpiler (https://github.com/euclaise/w2c9/), but something like wazero is a more obvious choice

It is kind of interesting that C inventors, contrary to the folks that worship C, not only did not care about ANSI/ISO compatibility, they ended up exploring Aleph, Limbo and Go.

While Bell Labs eventually started Cyclone, which ended up influencing Rust.

Many years ago I've used Editra under Linux, it was crashing and losing my unsaved changes at least once a day.

Sure, these days you could (and should) use source control, but still I would be concerned about using a non vetted editor for my code.

I appreciate that the author clearly states that he wrote the book with various LLMs. This way people that don't want to read LLM generated text (like me) can skip it and LLM enthusiasts can enjoy it.

this book was written with significant assistance from Artificial Intelligence (AI) tools. In the current era of technical publishing, deliberately avoiding AI would be highly inefficient and likely counterproductive, potentially even resulting in a lower-quality final product compared to what can be achieved with AI augmentation. Virtually all high-quality manufactured goods we use daily are produced with the aid of sophisticated tools and automation; applying similar principles to the creation of a programming book seems logical.

Using chatbots tells a lot about author's abilities. It is OK to use chatbots to adapt your book to some 9yo students, it is OK to generate images for a computer game to be permitted publishing it in someone's software market, it is OK to use advanced spell checking.

But it is not OK to make your tool thinking instead of you. If chatbot can generate the book for you about some random topic that means the book is already existing. What a sucker your reader should be if he chooses to read a byproduct handbook written by the entity who does not have an ability to learn at all.

IMHO, it is a terrible idea. Why would I feel offended by a cemetery ? Death is a part of life.

It sounds like you are trying to transform cemeteries in find a pokemon like game, which some people will find way more offensive.

Why should you impose your philosophy of death on other people?

Nobody is imposing anything, feel free to ignore my philosophy of death which I like to call reality.

Google removes some of its AI summaries after users’ health put at risk. Not all AI health related summaries were removed.

The honest answer is that nobody really knows.

The real answer that everybody can see that didn’t happen and can’t happen with current llms

Your CTO is right, reviewing code is harder than writing it. Any experienced programmer will confirm that.

If the human is the bottleneck the logical step is to use a different AI to review the code produced by the original AI. You can even use two different AIs to review the code generated by the first one and accept the code if both agree it does not have bugs. I doubt this will guarantee a high quality product, but it is the solution to doing all your code with AI.

The prudent choice would be to push any generated code to production only after it was tested and reviewed by an experienced human programmer.

On lulu.com you can get a really good idea of how much it will cost to publish a physical book.

I guess the idea is that if the code does not crash at this line:

    DEBUGASSERT(slen < dsize);

it means it succeeded. Although some compilers will remove the assertions in release builds.

I would have preferred an explicit error code though.

assert() is always only compiled if NDEBUG is not defined. I hope DEBUGASSERT is just that too because it really sounds like it, even more so than assert does.

But regardless of whether the assert is compiled or not, its presence strongly signals that "in a C program strcpy should only be used when we have full control of both" is true for this new function as well.

If you want to see the full documentary search for "Hackers: Wizards of the Electronic Age".

This was a great watch with my family - thank you!