> The real problem is that you can't use crates to improve incrementalism when you have a type in one logical part of the module hierarchy implement a trait from another logical part. Due to orphan rules and coherence, it is not possible to implement a foreign trait for a foreign type.

Well you can implement a trait for a type from another logical part either in the crate of the trait or the crate of the type.

What is the use-case for implementing a foreign trait for a foreign type if you have both under control?

> I wanted to separate the type, the trait and the implementation of the trait in different crates.

I usually put the traits in a separate crate, but keep concrete types and implementations for them in the same crate.

What is the use-case for splitting a type and it's implementation into separate crates? (except for cases where the trait or the type are out of your control, then one indeed needs to use the new-type escape hatch)

I had three different goals, one for the traits, one for something else where the types fit best, and the third which I achieved with the implementations of the traits.

The problem was that the trait implementations of the types was something like not a core task of the types themselves.

> (Plain Windows took ~26 seconds for some reason?)

Maybe the allocations were the reason?

I use Pelican (https://getpelican.com/) for my blog, which works decently for me. It is a static site generator written in Python.

But you probably won't learn much Python by using it (or Rust when using a generator written in it) since you probably won't need to change anything in it. The only Python code you need to write for Pelican is the configuration, which is just setting a few variables.

Pelican was one of the options I had in mind too; will consider it more seriously thanks to your recommmendation!

You know, I was wondering about that myself. I guess one of the selling points of these frameworks/products is their ease of configuration, which might mean very minimal hacking required, if any. So it's entirely possible I may not get to learn very much Python this way. Thanks for sharing your experience!

The build pipeline was already part of Linux 6.1. I played around with it on ArchLinux with the target to compile an out of tree hello world kernel module in Rust:

* https://blog.rnstlr.ch/building-an-out-of-tree-rust-kernel-m...

* https://blog.rnstlr.ch/building-an-out-of-tree-rust-kernel-m...

I'll probably make a follow up post with Linux 6.2

Nice to see that my blogposts about building a Linux kernel with Rust support on ArchLinux were useful for at least someone else :)

This post does a lot better job at describing the prerequisites to enable Rust in the Linux kernel, while I just referred to the AUR package I created.

MCUs with just 4MB of RAM may not even have IP based networking.

Unless you want really high performance networking, you don't need tons of RAM to implement it. ESP32-based MCUs are known to implement Wifi + TCP/IP + TLS [1] on 1-2MB of RAM. This is, of course, without a Linux-compatible kernel.

Much RAM is not needed if most of your code resides on the flash and runs directly from there.

[1]: https://github.com/espressif/esp-idf/tree/master/examples/pr...

2KB SRAM. ~1-2ms TCP setup + HTTP round trip, ~500-1000 requests/sec. Guess the MCU.

Atmega328P?

Knew someone would get it in one :)

If the slowness wasn't hint enough, the 2KB SRAM was a dead giveaway.

When I was your age, I sent 24 people to the actual moon with my software in 4K of RAM and here I am clicking your button and it takes ten seconds to load a 50 megabyte video ad and then it crashes. - @natecull, on Margaret Hamilton perspective

I work with a 2MB MCU, and run IP networking on it (in Python, no less). IP doesn't need very much RAM.

Sure, it's tilck that doesn't implement it. :)

You can run IP based networking on machines with well under 1MB (smallest I've personally a basic graphical web browser on would have been a 512KB Amiga)

We are doing IPv6 networking on MCUs with just 32k RAM.

on NXP K60 with FreeRTOS and lwIP IP based networking runs without problems with 256k Flash and 64k RAM. Of course it depends on the application, because the throughput is not high, but that is not the point here

When comparing Rust and C++ it makes sense to use Clang IMO, since both, the Rust compiler and Clang, are based on LLVM.

But nevertheless: I agree it would have been interesting to test with GCC as well.

There is an issue from 2019 on the pipenv tracker for this issue: https://github.com/pypa/pipenv/issues/3893

According to the last comment there it should be fixed:

> I don't think this should be an issue in the current 2022.4.8 release because of the requirement to use index restricted packages for locking. Please advise if you think this is still a concern and we can revisit it.

But apparently it is still an issue (assuming the author did use a recent enough pipenv version)

From the article:

> Overall this is pipenv working exactly as it should.

I don't agree, IMO pipenv should just install from the source package and ignore the newer wheel, maybe showing a warning about the new wheel.

Edit: Just noticed that the author agrees in the end:

> I suppose the behavior I’d like to see here is that if my Pipfile.lock has hashes in it for a distribution, then even if additional distributions are available, pipenv sync should be allowed to continue to install from the distribution corresponding to the “trusted” hash.

I prefer to use https://python-poetry.org/ instead of pipenv, since it has less issues in my experience. But I wonder how it would behave in this situation.

Not really, read the fine print :)

> When multiple moves have the top score, they are all top moves, even if visual markers (like move arrows) suggest the engine prefers one over the other.

This would be the case for two check mates.