![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
terminal adds upon package install sound like a great idea to me! we should allow them, unlike npm:
https://www.zdnet.com/article/npm-bans-terminal-ads/
---
[1] lists 4 kinds of docs:
tutorial explanatory how-to/recipe reference
[2] adds
README
i would also add
things like Python's tutorial, or the Ruby book,
which are mixtures of tutorial and explanatory, while also being comprehensive (to a point)
--- license
" I have talked to GCC developers about integrating a Rust frontend and they said, the main blocker is the fact that the language specification isn't stable and a fast moving target. ... I think the instability the GCC devs are concerned about is the release schedule. Rust has 9 releases per year while GCC has 4-5 releases. Unless you update your compiler quickly, you won't be able to use much of the crates.io ecosystem as crates are quick at requiring a new compiler version. Often the implementation of a new language feature is still getting last-minute fixes up to 6 weeks before the release, and sometimes even after that beta period. ... GCC can't miss out releases. The rustc 1.36.0 frontend needs at least a 1.35.0 frontend to compile itself. And most Rust programs in the ecosystem work with rustcs compiled with older LLVM releases, but most Rust programs that have dependencies do need newer rustc releases.
... As for stability of MIR: currently I think MIR is serialized to disk in a glorified mmap way. Basically following the Rust memory representation. It's great if both the creator of the MIR as well as the part that reads the MIR are written in Rust. Furthermore, there are libraries about how memory layout should look like that are provided to codegen backends. Those libraries are written in Rust and not really usable outside of Rust. So currently unless someone serializes MIR using e.g. bincode and provides C bindings for those layout libraries, there are good reasons to write the codegen backend in Rust itself, at least the part that translates MIR to the next stage. "
---
There's an organization called Blue Oak Council in which 3 FOSS lawyers work on licensing-ish stuff:
https://heathermeeker.com/2019/03/07/blue-oak-council-and-the-permissive-license-list/
Kyle Mitchell (executive director), Heather Meeker, Luis Villa. Kyle authors a zillion new licenses, so i'd like to see that this stuff was actually supported by the others, and it seems it was. According to that post by Heather all actively participated in the license list project and in the creation of the Blue Oak license.
Luis also publicly supports this work: " Luis Villa argues that the list of OSI-approved licenses isn't a comprehensive list of usable open source licenses. It should therefore be avoided in contracts or license clauses. But if not that, what is the purpose of the list? Would it make sense to create a smaller list of useful licenses? Villa points to his Blue Oak project as a list of useful permissive licenses. " -- [3]