Green_Penguin wrote: ↑Sat Feb 08, 2025 8:20 pm
But there can only be one switch at the junction, that controls whether the system goes down the windows track or the Linux track, even if those systems are on separate drives. The junction is the bootloader, and that's what the systems fight over
This is a
perfect analogy. Your operating system controls your machine and that control while the OS is running is absolute. That means that whichever given train you happen to be riding has the power to erase the other train and its tracks out of existence if you want it to do that. But the junction point is by far the most contentious piece of a dual-boot system. It's not hard to fix, but you need to be prepared to fix it if and when either of the trains decides the track was made for it and it alone.
Green_Penguin wrote: ↑Sat Feb 08, 2025 8:20 pm
My big fear is actually the big reconfigure. Even on windows getting a system from stock to what I would consider accessible entails an annoying amount of setup. On Linux that's extra true. as long as it doesn't break to the point where I have to nuke and pave or reconfigure a bunch of stuff, that's fine. MXs iso snapshot tool is really helpful in that regard.
You might also find virtual machines useful. You can build a Windows VM in Linux, or you can build a Linux VM in Windows, or both. You're running one OS on the machine, but you can start the VM and log into it pretty much the same as you'd remote into a real server with something like RDP or VNC. VMs aren't going to fight over their host's bootloader the way a full install on the hardware would. They're a good way to try before you buy, and in may case they're a good way to keep Windows around to run Progress Quest without needing dedicated hardware. Your two real challenges here are (a) figuring out a setup process you can rely on to give you the system look and feel you want and (b) finding the right way to compartmentalize your operating systems. That could mean using MX Snapshot, or having a library of Clonezilla images, or a thumb drive, or something else entirely.
Many years ago, you'll soon see how many it was, I was a Windows admin. I ended up responsible for a dozen old, unused Windows 95 machines in a computer lab. I'd found a Windows NT Workstation CD-ROM hidden in the back of the software shelf in the server room and spent a summer figuring out how to build an unattended network install process for NT4 that began with a magic floppy diskette I made to (a) boot the machine, (b) erase the partition table, (c) make a new FAT32 partition and copy some setup files to it, (d) restart the machine, and (e) run the setup files to erase and reformat the disk to NTFS and put Windows on it from a network share.
This wasn't a dual-booting scenario, but one where I had a floppy disk that needed to do two different things at two different times. This required booting off of a writable medium that could maintain enough state to know "Am I on stage 1 or am I on stage 2?" as well as being smart enough to reconfigure itself from stage 1 to stage 2, or from stage 2 back to stage 1, so that the disk could reset itself for the next use.
If anything went wrong, the worst that would happen is that the boot process would fail. Typically, the NT install would just loop back to stage 1 and start over again -- annoying, but not a major issue that required repair. And if the floppy disk failed entirely, I had backups of the disk image and could simply write it to a new disk and keep on reinstalling the OS. I got it down to a simple procedure: Grab a stack of the custom unattended install floppies and go to the lab. Insert floppies into machines. Reboot. Walk away. Come back once files were copying across the network and eject the floppies so the boot-erase-install stages wouldn't keep looping forever. Move onto the next machines.
It took nearly a year of research before I could get started, then followed by an entire summer of concerted effort at work: working on it when I had spare time in the office, evenings, on weekends. It took a long, long time to find a reliable, repeatable setup process but once I had it, I could customize it fairly easily (Here's a wallpaper with the company logo on it! Let's put NetTime on the lab machines so their clocks are synced!) and, most importantly, I could reinstall the entire lab -- 12 or 13 Pentium 100MHz IBM boxes -- in a few hours. And those hours were mostly just waiting for files to copy. As I said: insert floppy, reboot, walk away. It was a ton of work, angering and aggravating at times, but a satisfying project I consider important enough in my career to still have a backup of that floppy disk. You never know.
