Absolutely. An example of a malicious collision would be to request the file with the SHA-1 of 38762cf7f55934b34d179ae6a4c80cadccbb7f0a. But… there’s two of them here.

MD5 is so broken that its former status as a cryptographic hash function has been stripped. And efforts are underway to replace SHA-1 where it’s used, since although it takes some prerequisites to intentionally create a SHA-1 collision today, it’s worth remembering that “attacks always get better, they never get worse”.

provide the hash of an arbitrarily large file and retrieve it from the network

I sense an XY Problem scenario. Can you explain what you’re seeking to ultimately build and what requirements you have?

Does the solution need to be distributed? Does the retrieval need to complete ASAP or can wait until data becomes available? What sort of reliability/availability does this need? If only certain hash algorithms can be supported, which ones do you need and why?

I ask this because the answer will be drastically different if you’re building the content distribution system for a small video game versus building the successor to Kim Dotcom’s Mega file-sharing service.

I am always deeply enthralled when math and comp-sci unite to yield an elegant result, where my definition of elegance is: efficient + minimal.

To start, it might be worth reviewing the recommended antenna traces for wireless ICs, since vendors often provide precomputed and validated reference designs in their data sheets. These are often what are made into breakout boards, and there’s a lot which can be learned by what these reference designs take into consideration.

I’ve not specifically done PCB designs with antennas, but I have done my own designs for high-speed differential signals, where the impedance of two traces have to be consistent along their length, whether side-by-side or on opposite sides of the PCB. As you observed, KiCAD can do a lot of this computation but good antenna design means even the pads that attach to the IC also need to be impedance-matched. And that requires both an understanding of where problems arise (eg when traces turn a corner), how to compute the effects (using KiCAD’s features), and whether the issue might not even make a big difference in overall performance.

I had the bright idea

Haha, I enjoyed that. Although you’re pursuing using parts from a flashlight, I wish to point out that LEDs are now fairly straightforward to put together into a full lighting solution. Generally, it would be an LED module, an optic, and the driver circuit. Maybe a heatsink too. Ok, maybe this is somewhat complicated lol

I’m not affiliated with that supplier, but I’ve bought from them before to build a custom headlight for a bicycle.

Can’t Python be translated into machine code

Yes, and that’s basically what the CPython interpreter does when you call a Python script. It sometimes even leaves the result laying in your filesystem, with the extension .pyc . This is the byte code (aka machine code) for CPython’s implementation of the Python Virtual Machine (PVM).

and packaged into a binary?

Almost. The .pyc file is meant to run with the appropriate PVM, not for x86 or ARM64, for example. But if you did copy that .pyc to another computer that has a CPython PVM, then you can run that byte code and the Python code should work.

To create an actual x86 or ARM64 binary, you might use a Python compiler like cython, which compiles to x86 or ARM64 by first translating to C, and then compiling that. The result is a very inefficient and slow binary, but it is functional. You probably shouldn’t do this though.

While I get your point that Python is often not the most appropriate language to write certain parts of an OS, I have to object to the supposed necessity of C. In particular, the bolded claim that an OS not written in C is still going to have C involved.

Such an OS could instead have written its non-native parts using assembly. And while C was intentionally designed to be similar to assembly, it is not synonymous with assembly. OS authors can and do write assembly when even the C language cannot do what they need, and I gave an example of this in my comment.

The primacy of C is not universal, and has a strong dependency on the CPU architecture. Indeed, there’s a history of building machines which are intended for a specific high-level language, with Lisp Machines being one of the most complex – since Lisp still has to be compiled down to some sort of hardware instructions. A modern example would be Java, which defines the programming language as well as the ISA and byte code: embedded Java processors were built, and thus there would have been zero need for C apart from legacy convenience.

As it happens, this is strikingly similar to an interview question I sometimes ask: what parts of a multitasking OS cannot be written wholly in C. As one might expect, the question is intentionally open-ended so as to query a candidate’s understanding of the capabilities and limitations of the C language. Your question asks about Python, but I posit that some OS requirement which a low-level language like C cannot accomplish would be equally intractable for Python.

Cutting straight to the chase, C is insufficient for initializing the stack pointer. Sure, C itself might not technically require a working stack, but a multitasking operating system written in C must have a stack by the time it starts running user code. So most will do that initialization much earlier, so that the OS’s startup functions can utilize the stack.

Thjs is normally done by the bootloader code, which is typically written in assembly and runs when the CPU is taken out of reset, and then will jump into the OS’s C code. The C functions will allocate local variables on the stack, and everything will work just fine, even rewriting the stack pointer using intrinsics to cause a context switch (although this code is often – but not always – written in assembly too).

The crux of the issue is that the initial value of the stack pointer cannot be set using C code. Some hardware like the Cortex M0 family will initialize the stack pointer register by copying the value from 0x00 in program memory, but that doesn’t change the fact that C cannot set the stack pointer on its own, because invoking a C function may require a working stack in the first place.

In Python, I think it would be much the same: how could Python itself initialize the stack pointer necessary to start running Python code? You would need a hardware mechanism like with the Cortex M0 to overcome this same problem.

The reason the Cortex M0 added that feature is precisely to enable developers to never be forced to write assembly for that architecture. They can if they want to, but the architecture was designed to be developed with C exclusively, including interrupt handlers.

If you have hardware that natively executes Python bytecode, then your OS could work. But for x86 platforms or most other targets, I don’t think an all-Python, no-assembly OS is possible.