Wouldn’t most of those old computers be 32 bit? I remember trying to throw arch on an old winxp netbook and running into that issue.

I think so, yeah.
Though Alpine would be probably easier to get going given the super tiny size.

Yes, you can install on one machine, move the drive to a different machine, and it should mostly just work (unless they are different architectures and the packages aren’t compatible). I’ve recently moved an old Arch install into a basically new computer and after changing the microcode it just works fine.

It should be possible. I’ve just recently created a virtual hard disk in virtual box and mapped it to a physical ssd and installed windows on it. just change the settings of the virtual machine to match the target hardware and it should be fine I think.

512 m ram dunno, but I had an old 10 yo+ dual core / 4 gb ram laptop on arch working well, except for gaming. Just replaced it with ghostbsd, also fluid.

I have a Thinkpad T400 with Arch on it. It came out in 2008 which I believe is the last year XP got a release. But I’m pretty sure it came with Vista.

It runs like shit with a full desktop environment but with i3, it’s decent. I haven’t used it in a little while because I upgraded to a luxurious T440 recently but I have Intellij and Docker running on it. I can do most of my programming things. It’s definitely good enough for browsing the internet or running Libre Office.

So. To answer you “hypothetical” question if we ignore all the factors making it complicated (like 32bit compatibility, drivers, etc.)

Yes it is “feasible” to Install an OS using a modern System and just pull out the HDD and shove it into an old system. Especially since the way BIOS/MBR (aka “Legacy Boot”) is the exact same on all systems you write the “what to start” code in the first few Bytes on the HDD (aka the MBR) and set a bootable flag on the device. Now you can pull it out and plug it into any other machine which will simply “look” for a bootable flag and then run the code in the MBR (usually a bootloader). This bootloader (usually grub for legacy systems) will then execute one of its boot entries and start a kernel. This is probably where a real world example fails because of the problems mentioned by everyone here.

I don’t know about Arch, because I’ve never used it, and I believe it only installs the drivers for the current hardware. I’ve done it with either Ubuntu or Mint though, and even with Windows XP and 7, though they were harder.

I haven’t done it as a deliberate choice during installation, but I have had a working OS on a drive that I’ve then transferred to another computer. In the Linux cases, I’ve just put an old drive into another computer to see what would happen, as the drive was due to be wiped anyway. It was several years ago, probably over ten years, but for the most part, they just worked. The first boot was slow, presumably while the drivers were sorted out, but I think the most work I had to do was reboot a few times, after it got to the desktop.

With Windows, I had to delete a drivers folder, I think under C:\Windows\System32, and delete a registry entry. It didn’t work every time, but it did work fairly regularly. It may have been down to the Windows version, home vs pro, but I can’t remember.

Hope this helps 👍

Way overcomplicating it, sure you could do that, or you could just Install arch using cdrom. it’s worked on Windows 98 PCs it’ll probably work on Windows XP PCs.

though you may need an older ISO to hit the 512mb limit

I used to have an USB stick with Ubundu on it, so I see no reason that it shouldn’t be possible. But idk how drivers would work.

Also I would check how much RAM is needed to boot the live ISO (not during the process). If it is low enough, you can use swap.