>>>What people forget is that it costs money to keep providing updates for an old OS, and that improvements in later OSes make them safer to use in the first place.
>
>True. And software doesn't "wear out" like a hard drive or flat-bed truck, so if it makes business sense to keep using it- people can. Just as your husband did. What happens though is that hardware and consumables need replacement and one day there's no driver available for the old OS, just as the manufacturer no longer offers K2C buffer seals for a '57 Chevvy. Maybe if new software drivers had a price tag, it would be different but people expect drivers for free and therefore need to expect to update their OS to get new drivers. It's true of Linux as well- older versions of Centos struggle with large WD disks and newer motherboards, because it's not viable to update obsolete stuff forever for free.

Speaking of obsolete... check your CV on this list: http://m.computerworld.com/s/article/9132061/Old_school_programming_techniques_you_probably_don_t_miss?pageNumber=1&mm_ref=http%3A%2F%2Ft.co%2F1yCSZRql33

My checklist:
sorting algorithms - yes, did that and wrote my own version of quicksort for a specific task (read: get around the memory limitations of CP/M)
my own GUIs - coded forms for VT100 terminals using escape sequences
GOTO - my first computer ran only Basic, and I did three years of Cobol, so...
manual multithreading, self-modifying code, memory management - no
punch cards - only in college
math and date conversions - hey, had to calculate interest in Cobol, so guess what
Hungarian notation - in VFP it's something else... and still do that
Making code run faster - still doing that, when I find a really slow part
Being patient - my compile/link times rarely went over ten minutes, perhaps on a PDP when it was loaded, running 16 terminals on just 2M RAM