Original author of smoltcp here! I couldn't have imagined how much of a cornerstone of the Rust ecosystem it would become. Very excited to see it get used like this, and yeah, #![no_std] use cases were the original and primary motivation to build the stack in the first place.
It uses completely different software (that I wrote together with a small team of volunteers: https://codeberg.org/git-pages/git-pages) which scales very well horizontally and works more like GitHub Pages than Codeberg Pages technically, but in concept you are basically correct.
122 MB of it is Wasm machine code of a MinSizeRel LTO build of LLVM; it is compressed to 23 MB by Zstandard when your HTTP client supports that. That is about as small as you can get an LLVM/Clang/LLD bundle to be, and I put a lot of effort into making it smaller.
248 MB of it is an OpenBSD sysroot; it is compressed to 45 MB by Zstandard when your HTTP client supports that. I have not used OpenBSD and have no particular insight into what's inside.
> he was a large contributing factor to the previous SolveSpace lead maintainer quitting
If you look at https://github.com/solvespace/solvespace/issues/714, it refers to "a few people [who] behave in a way that is unconstructive and directly leads to maintainer burnout [...] have not encountered this level of entitlement and persistence when working on any other OSS, of which I maintain plenty, and I do not wish to encounter it ever again.". That's this guy. At the time I chose not to name him publicly nor to ban him from the organization; the latter was clearly a mistake.
(The unfortunate incident with Aleksey was the proverbial straw. I regret that it happened, since Aleksey has done a lot of good work for the project; if memory serves, at the time I was looking for other ways to fund his work.)
> who near converted SolveSpace to doble-licensed open-source, far away from its inital GPLv3.[3]
This happened after I spent several months paying Aleksey Egorov (Evil-Spirit), who did some of the best and most important work on SolveSpace, a competitive salary out of my own pocket, and it has been done in coordination with Jonathan Westhues. (You'll see his name on the CLA.) SolveSpace had a commercial licensing option before the initial open-source release, which provided a (small, but useful) revenue stream, and that seemed like a good option to continue using.
Knowing this, you can also see why Aleksey's unfortunate statement about gender felt so painful. All I wanted was to keep developing a great FOSS CAD!
process_vm_read and its equivalents allow you to read data whose layout you already know. unfork allows you to read data whose layout you don't know or that is partially generated by calling the accessors that the application already has for that data instead of reverse-engineering them and doing the transformation yourself.
Also I got pinged by like a dozen different HN bots, because each time any of them tweets a link, Twitter thinks it's a quote-tweet and sends a notification. Annoying.
At the time when I started working on smoltcp, there were a few Rust libraries for working with TCP/IP on the wire level, and they heavily used metaprogramming. Unfortunately, the task of implementing a generic binary protocol serializer/deserializer that can handle TCP/IP is not small, and as far as I could tell, it overtook implementing anything beyond that.
So I made the decision to do the simplest possible thing: write the packet serializers/deserializers entirely by hand. It took very little time and adding any new features was easy and predictable. I believe it was the right decision as it allowed me to focus on the hard parts of a TCP/IP stack.
I designed smoltcp (and wrote most of the code currently in it). The original TCP/IP RFC (RFC 793) contains several ambiguous requirements, and as a result they do not specify a well-defined system. There are also some outright incorrect statements. There are a few follow up RFCs (e.g. RFC 1122) that clarify these issues, and there are more RFCs (e.g. RFC 7414) that describe the TCP features that you should avoid using.
By using this collection of TCP/IP RFCs that grew over the years, it is indeed possible to implement a stack from first principles and have it interoperate with other existing stacks without much trouble. (At least so long as you don't put the same bugs in your test suite as you do in your stack... which you will.)
However, being able to transmit some bytes reliably, and having a high-performance stack that works well in real world conditions are different. You might be able to do the former from RFCs, but the latter absolutely requires a nontrivial amount of tribal knowledge that you have to collect crumb by crumb, and often quite painfully, too.
Smoltcp is somewhere halfway between. It's pretty reliable, but I am sure there is much to be improved in its operation in adverse conditions, with obscure peers, and so on.
The "smol" in "smoltcp" is mostly talking about the internal architecture and exposed API. For example, it will never support true zero-copy sockets, because the API burden due to restricting itself to safe Rust is too high.
I don't think any TCP/IP implementation is going to be "haiku-like", the protocol stack is way too messy.
> MSVC compiler doesn't do SROA, as far as I know.
In the future, consider verifying your extraordinary claims. Of course it does, and it took me about two minutes to demonstrate that: https://godbolt.org/g/9kT1NP
Zoxc has repeatedly refused reasonable requests to alter the patch to fit the standards of upstream. Because of this (and because I am rather tired of not having stack probes, with my embedded system not having functional guard pages), I'll make a hostile fork of their patch soon and get it through the pipeline. Stay tuned.
SolveSpace is indeed similar to FreeCAD's Part Design module. One major difference is that SolveSpace uses the same solver for constraints in 2D and 3D, as well as for sketches and assemblies, whereas in FreeCAD the Assembly module is separate.
There are vague plans for integrating Lua in a way that lets people implement new constraints without touching the C++ code, but the current architecture makes it very hard. We're refactoring it but it will take a while until such scripting is viable.
I care a lot about reliability! In fact, FreeCAD's incessant crashing (and the fact that it corrupted the savefile when doing that) was the single biggest reason I put so much time into improving SolveSpace, although working assembly support is a close second.
Even in case that SolveSpace does crash, it has an autosave facility (with a five minute interval by default), and so you should never lose more than five minutes of work.
You should also use the 2.x branch and not the released version 2.1, as the branch has some important bugfixes. I will release 2.2 within a few of days though.