It's extremely common, even today, though probably not the processor I would pick (I think 68000 family, perhaps?), but it's probably a reasonable choice. You're going to be able to find it embedded in literally millions of devices and it's simple enough for one person to build a computer around it.
I suspect the argument against modern Intel chips is just their complexity. They need an incredibly complicated and somewhat fragile support infrastructure...you can't build a modern PC motherboard in your garage and you don't expect modern PCs to last decades. They're very common, though, and I suspect there will be plenty of PCs to scavenge, at least through our lifetimes. But, the next generation will probably have trouble keeping them going...I've got a 40 year old C64 still running with nearly all original parts, but I am nearly 100% certain my modern laptop will not last even a decade without repairs using parts that can't be manufactured without modern infrastructure.
The z80 is an 8-bit processor released in 1976. It's not an appropriate target for Linux for many reasons, including: no processor support for process isolation, massively divergent hardware setup in different applications, lack of processing power, lack of modern c compiler, etc. I don't think any of the mainstream Linux ports run on anything less than a 32-bit processor; although there are some fringe ports to 16-bit systems.
I'm somewhat surprised there's no Z80 support for GCC, I recall running a gcc for Motorola's 68HC11 which is a similar processor. That said, most general purpose C compilers are a bad fit for 8-bit processors; you really want to write assembly for these small systems to ensure your code is compact and fast; it's much too easy to write code in C that will be significantly slower than if well written in assembly because of limited memory indexing modes or lack of registers. It's probably possible to carefully constrain your C usage to encourage reasonable assembly output, but then you're not going to be able to use existing C code. You won't have that much code that fits in your roms anyway, so you may as well dig in and write assembly.
No 6502, either. There aren't many 8 bit CPUs that are considered a reasonable platform for any UNIX. Which is why I think I'd prefer 68000 family. It's "modern enough" to use with modern compilers and operating systems, but simple enough for a one man garage shop to build/maintain a computer that uses it. I guess earlier 80x86 chips could fit that bill, too, but 68000 has a better assembly language.
>I'm surprised that it doesn't have support for Z80 if it's so common.
That's because it's an 8 bit computer, my dude. Back in the old days, when "the internet" was still a military project, and you'd phone up your local BBS at 2400 baud on a POTS with suction cups; that's all the little people had access to as recently as the early 80s. And as other people said, there are apparently many of them around, and they run on shit power supplies.
It's a cool idea, but obviously it requires both cheap and dirty hardware implementations and a paper manual. Pretty sure "hacking" will be low on the hierarchy of needs in the event of apocalypse. Also pretty sure something like CP/M would be more useful. I know where there are CAMAC crates with Z80/CPM punched card/paper tape readers that would probably do great in a post apocalyptic environment.
The TI-83 and TI-86 series calculators were Z80 based.
Apparently they discontinued those in 2004. Huh.
Maybe the m68k would be a better target? Actually if the OP is serious about this project, I would write base kernels for Z80, m68k, armv7, and RV32i. The last one isn't widely available, but has the advantage of being both modern architecture and allowing open-source specs for how to construct one from scratch.
