Apollo-11 VS linux

I often like to think about https://github.com/chrislgarry/Apollo-11 as an analogy. It's public domain with available source, in the assembly language in which it was written... so it fills all the definitions of OSS!

But the process by which that code arose, the ability to modify any line and understand its impact (heh) on a real execution environment, is dependent on a massive process that required billions of dollars and thousands of the smartest people on the planet. For all intents and purposes, without that environment, it is as reliably modifiable as an executable binary in any other context - or a set of weights, in this one!

My more positive take on this: our runtime environments are bloated because we have ways to enable trust, stability, and iteration speeds that people wouldn't have dreamed of in years past.

Your Notion desktop app and Google Chrome both support embedding & displaying multimedia content that's controlled by people that you may not trust, but they can draw on decades of engineering to sandbox that content. They can independently be updated without worrying about a centralized `flexbox.dll` that may or may not be the right version. They do not require building a new executable to make the vast majority of UI changes. And the cost is simply storage space and initial download bandwidth.

We can look with rose-colored glasses at an era of "every byte of assembly has been hand-crafted." I, too, look in awe at what was achieved with such things as https://github.com/chrislgarry/Apollo-11/tree/master/Luminar... . But that software, per https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw..., took 1400 person-years of work.

We have to compare apples to apples - the abstractions we have today would not prevent such a piece of software from being built, and indeed would allow us to build that exact software, even bit-for-bit the same, much more easily due to abstractions on our tooling itself. We have not departed a world where, given a nation-state budget, one could pay for 1400 person-years of work and create the AGC (though one might make arguments about the distraction levels of modern society, but that's a different thing entirely).

But we also exist in a world where I can build and ship a cross-platform video chat application in an afternoon (well, not counting app store approvals) and be reasonably confident that my app will be compatible with, and secure on, practically any computer or mobile device sold in the past half decade, regardless of how many other apps may have been installed on each device. I'd venture to say that Apollo engineers would, and do, find this aspect of our world fascinating, too.

Extension pack for picking up Matt Damon

We didn't destroy the technology. A lot of the original documentation still exists. For example, all the code for the Apollo Guidance Computer is available on GitHub if you're interested.

Can we get networking on the Apollo-11 so we can browse the DT?

It's not "just fixing typos", as this code was generated through OCR - and the publisher specifically ask to proof-read and fix typos (https://github.com/chrislgarry/Apollo-11/blob/master/CONTRIBUTING.md)

> the code for the space shuttle should be written carefully

Couldn't help but remember the comments in the Apollo-11 source code saying "TEMPORARY, I HOPE HOPE HOPE".

https://github.com/chrislgarry/Apollo-11/blob/a13539c7c5c482...

Correct. And the combined work needs to carry the MIT license text and copyright attributions for the MIT software authors. With binary distribution it must also be overt, not hidden in some source code drop, but directly accompanying the binary.

Many people who talk about relicensing never credit the MIT developers or distribute the MIT license text. "Because it's GPL now."

I don't think that you believe that, but many developers do.

Some don't see the need for source code scans for Open Source compliance, because the license.txt says GPL, so it's GPL. Prime example is the Linux kernel. There is code under different licenses in there, but people don't even read https://github.com/torvalds/linux/blob/master/COPYING till the end ("In addition, other licenses may also apply.") and conclude it's simply GPL 2 and nothing else.

Also be aware that sublicensing is not the same as relicensing.

So If we would only count code and not comments, it is only 9489 LoC Rust. Which would be about 0.03% and if we take all lines and not only LoC it would be around 0.05%

[0] https://github.com/XAMPPRocky/tokei

[1] https://github.com/torvalds/linux/commit/b401b621758e46812da...

AIUI fsync is built on futex_waitv which has been upstreamed. So this has to be more than that.

https://github.com/torvalds/linux/commit/a0eb2da92b715d0c97b...

git clone --no-checkout --depth 1 https://github.com/torvalds/linux.git $dir

Device trees are what you get if you don't implement ACPI.

While there are alternatives, you generally seem to get "device trees and a barebones bootloader" on ARM and "UEFI + ACPI" on amd64.

ACPI will list hardware and necessary hardware properties based on some basic API calls to the system interface. UEFI initialises the ACPI data structure and exposes it to the bootloader so the appropriate drivers can be loaded and configured.

With device trees, you basically configure and build the drivers and configuration into the kernel/OS you're trying to load. That's why compiling Linux on amd64 is generally easy and produces a single image, while for many other devices (smartphones, some SBCs) you need to compile a kernel per device. The device trees only need to be imported/written once per device (or device type, depending on how nice the manufacturers are), but that's how you get stuff like this: https://github.com/torvalds/linux/tree/master/arch/arm64/boo...

On ARM there are actually a few devices that implement UEFI, but most of them have Secure Boot locked in and configured to only boot Windows.

ACPI is not perfect and it's not technically required to have UEFI to implement something better than device trees, but I'm not sure if reinventing the wheel here is necessary or even preferable. UEFI already has open source implementations ready to go, with kernels and other tools already containing code to interact with those APIs, whereas a custom ACPI replacement protocol would need more implementation work,

The Linux Kernel Driver Interface

(all of your questions answered and then some)

https://github.com/torvalds/linux/blob/master/Documentation/...

A bit later another commit [1] was merged that makes reads from /dev/urandom opportunistically initialize the RNG. In practice this has the same result as the reverted commit on non-obsolete architectures, which do have a cycle counter and thus jitter entropy.

[1] https://github.com/torvalds/linux/commit/48bff1053c172e6c7f3...

The commit [1] was eventually reverted [2]

[1] https://github.com/torvalds/linux/commit/6f98a4bfee72c22f50a...