For the benefit of future readers who don't get it, if nothing else: the "salmon problem" (in German Lachsargument) is an old argument that the origin of the Indo-European language family should be in the Baltic region, because the word for "salmon" is found in both the Germanic and Balto-Slavic branches. Later research in the Caucasus found that the reflexes of the word referred to trout, which is found in rivers on the Eurasian steppe. (They're both species in the genus Salmo, so it makes sense that semantic drift would occur in populations moving to a new area.)
> It has always existed. When men collected food and survived they shared. If there is an surplus of something you do not need, what do you do with it? Eventually, I guess, they started bartering. Bartering is a primitive way of trading. That trading is possible accumulating enough, otherwise you would need it all for yourself.
This is Adam Smith's just-so story, but he was wrong - no society has ever been shown to survive on a barter economy. Anthropologists have shown that what existed before trade was the same as what exists today when trade collapses: informally held debt. Alice knows how to work leather, Bob knows how to work wood; Bob needs a pair of shoes; Alice gives Bob a pair of shoes to satisfy his need and both Alice and Bob remember that; later, when Alice's house needs repairs she knows whose shoulder to tap on.
This is "barter" in the sense that Alice's and Bob's services have been transacted through time, but you'd be moving the goalposts since you just defined barter as Alice and Bob sitting down and determining precisely how much wood-labour equates to a fixed quantity of leather-labour at the point of purchase.
If you'd like to learn more, then David Graeber's book Debt: The First 5,000 Years, is something of a standard reference on the subject. It's on the Internet Archive.
> Using a faster linker by default, e.g. Mold. Although I don't know whether there are portability or other issues here.
mold supports precisely one platform: x86_64 Linux. It also doesn't support linker scripts beyond what is necessary to link libc, and given the creator honestly suggested the suckless practice of editing and recompiling the source code as a possible replacement for them I have my doubts that it'll have a satisfactory replacement for, say, the things I'm currently doing. (Admittedly those things are in ARMv4T rather than x86_64, but still.)
As I understand it the amount of time we were tossing radio into space was quite brief, and more modern radio traffic is directed at the ground (since after all if you're leaking signals into space you're wasting power).
One of the papers cited in the OP argues that a good indicator that there's something interesting about a planet is the combination of molecular oxygen and methane in its atmosphere - the former is a strong oxidiser, while the latter is a reducing gas, so there's some dynamic system producing free methane in the atmosphere.
They could do what Apple did and provide a Windows compatibility layer which gets progressively more buried as old software gets replaced until it's just kept around for the weird stuff that never gets properly updated because it's maintained by a rotating set of undergrads.
Much like the majority of the Latin-speaking world, Italian underwent a sound change where [k] softened before a front vowel. The original [k] can be found in Sardinian and the now-extinct African Romance.
The pronunciation used in schools for didactic purposes has only a modest relationship to authentic historical pronunciation. Pronouncing eta as [i] is an influence from modern Greek - in ancient times it was [ɛː], as described by the author (and as used in my secondary school Ancient Greek class - when we switched teacher to one who pronounced it [i], he conformed to our standard rather than vice versa). The bLogicarian has an article [1] which goes into more detail with some recordings, or you can pick up a copy of Vox Graeca by W. Sidney Allen.
You make it sound like there's a machine you can put a Game Boy ROM into and get out a disassembly, which is kinda true (https://github.com/mattcurrie/mgbdis) but it doesn't automatically split out data blocks or anything like that - it just tries to crawl the ROM and disassemble any code it can find. It's certainly not "effectively no additional work" than making targeted alterations to the binary and documenting your work.
And that's before you get to platforms where most if not all games are written in C - I question whether a mere disassembly of a game like Pokemon Emerald would even be useful to anyone, whereas the pokeemerald decompilation (https://github.com/pret/pokeemerald) is clearly useful but was a heck of a lot more work to produce.
> That's a hurdle, but not an insurmountable one... unless the system didn't even support banking. (Are there any systems that didn't?)
Depends what you mean by "support". I don't think any system has a built-in mapper - they just assign a chunk of memory space to the cartridge bus, and if your game is larger than that chunk of memory space you include a mapper on the cartridge. Nintendo provided standard mappers for machines like the NES and Game Boy because it's very hard to include a substantial game in the wedge of memory space you get on the processors in those machines, whereas only one game on the Genesis/Megadrive needed one.
Personally, as a fan of retro games consoles (which are broadly in the same boat as retrocomputing hardware) I'm as interested in new independently-produced software as I am in the software released during the hardware's commercial lifespan. Original games aren't getting any cheaper as copies disappear into private collections, and the economic incentives don't exist for copyright holders to make new authentic cartridges.
As such, the vibrancy of these systems relies on writing new software being a pleasant experience, and there's a limit to how pleasant that experience can be when your only choice of non-assembly language is C.
This is probably a hot take, but I don't think standard libraries should contain a random number generator.
There is no globally correct choice of PRNG algorithm. If you need randomness, you should ask what kind of randomness - cryptography wants secure, Monte Carlo methods want fast, games can often benefit from N-dimensional equidistribution, etc. - and find a library specialised for that use case. A standard library function that nobody uses because there's always a better alternative elsewhere is a bad standard library function.