Adrian Cochrane @alcinnz@floss.social

Don't get me wrong, computers can absolutely help us regain our environmental efficiency. They just *aren't*.

Not as long as we're:
* constantly syncing everything to the cloud,
* expecting same-hour delivery,
* funding our clickbait via surveillance advertising,
* buying a new phone every year,
* using AIs because they're cool rather than useful,
* running bloated software & webpages,
* buying into "big data"
* etc

Computing is environmentally cheap, but it rapidly adds up!

Maybe it's just because this is where my interest lies, but reading a few takes on how to Fix The Web yesterday I really think a major issue are the discovery hueristics we use. Their incomprehensibility and shallowness promotes the bad and buries the good.

There's PLENTY of good links! Otherwise I'd be wanting to tear The Web down rather than just JS...

I created Odysseus to explore some partial solutions, but I'm keen to see others address the problem from a different angle! Links? Advice?

Anyways my schedule is:

* GNU LibC bundled plugin modules & datafiles, focus on "elf".
* The modules with platform-dependant implementations, focus on "math".
* The POSIX & x86 implementation of those & other libraries. (Linux apparantly doesn't need dedicated support)
* LibC++
* Break to describe Solr as used by SearchMySite.Net
* Continue studying each component listed by Linux From Scratch, if the core logic of any of these is in Linux, I'll dig there. e.g. networking with inetutils.

2/2

Anyways I've been getting organized to describe the bundled plugin modules & data files for some of GNU LibC's sublibraries. For now I will say the ELF executable format is once again the main source of complexity (it's plugin module for the library which loads plugin modules!), don't really understand the need for it... Should take me another day or two!

I think tomorrow I'll study how WiFi works... We now have an opensource implementation "OpenWiFi"!

1/2

To implement timers I'd maintain an insertion-sorted list, and when the ALU increments it's time register I'd compare it against another register for the earliest timer to consider whether to enqueue some input into the rest of the processor, telling it to evaluate all expired timers & send the appropriate outputs.

Then there's again the importance of being able to pause the receiving application until more data comes in!

Don't think I'm knowledgable enough to discuss TLS...

6/6 Fin.

TCP adds reliability & UNIX-like streams upon the Internet Protocol. Beyond normal ports, header-length, & One's Complement checksum TCP adds sequence numbers & control flags.

The expected sequence number to send can be tracked in one of the adder's registers, though they should be initialized with random values. Not *entirely* sure what RNGs require.

Then we need timers for when a confirmation fails to arrive or we fail to find data to send with that confirmation...

5/6

To handle the caching in a pushdown automaton CPU architecture I'd (re)write tries to be ran as parsing bytecode, fallingback to the actual DNS implementation. Once I find one I'd check the current time to reconsider whether to use that fallback. Upon a low-memory event I'd prune timedout cache entries.

That time could be tracked by the ALU responding to a periodic interrupt.

And I'd need process-switching to enable callers to block on DNS & TCP. Insert into trie or lookuptable for parser?
4/6

Port Numbers in IP, UDP, TCP, TLS, etc would branch to the parser for the identified protocol, which incidentally is the main thing my hypothetical hardware pushdown automaton is designed to do! UDP also has a length field & a One's Complement Sum just like IP.

DNS requires a little bit more logic to handle & parse, containing sized arrays of arbitrary-sized queries, answers, name server records, & additional records. And necessitating caching with timeouts, redirection (offloadable), etc.
3/6?