*BSD as a "main driver" for average users

Apple built a lot on the FreeBSD codebase. JKH moved from the FBSD core team to Apple, IIRC. Likely enticed for that purpose.

You really only need manufacturer support if:

- your machine is out-facing

- there are "features" that are broken beyond the point where you can make use of them (and, presumably, NEED them)

I have several W7 machines that have been gleefully supporting a variety of applications for more than a decade. I tolerate the bugs in those applications (instead of TRADING them for a set of UNKNOWN bugs).

But, that network isn't routed so the threat to the machines on that network is minimal. The greater risk would be a power supply failing or a disk sled breaking and replacements being difficult to find.

If "others" were using my machines, I might have more concern as I couldn't stop them from installing crap on them.

Its not just the UI/UX but, also, their support for evolving protocol standards. I built the W10 machine when the (ancient) browser running on its W7 predecessor could no longer render many (commercial) web sites.

In hindsight, I could have installed a more current version of the browser on a *BSD box and avoided MS entirely (which is the route I have now taken)

We don't print much. A case of paper (10 reams) will last us a few years. Any "high quality" printing we do at the service bureau down the street (let THEM maintain the printers!). Any high

Most of our printing is along the lines of:

- "I've got a list of things that I want to examine with pen/pencil"

- "I have a recipe that I want to make, tonight"

- "I want to make a label for a box and a magic marker would be tacky"

We have a pair of HP LJ5p's (or maybe 6p?) -- low temperature lasers. I think we get about 5000 pp out of a toner cartridge.

Its called an "externality" -- shifting the cost onto someone else.

The only "apps" of substance I really run on the OS these days are like KiCad, LTSpice, and Studio One/Fender Studio for audio/video. And Microsoft is only needed for the last one.

Parts/inventory management is in the cloud, email is in the cloud, accounting is in the cloud, document editing is in the could (though I use R Studio and LibreOFfice sometimes, but MS is not necessary), Github is in the cloud, VS Code is _basically_ in the cloud. With regular multipoint local backups of all the important stuff of course.

Oh, I use Mathematica sometimes on Windows, though it's not really necessary.

This is probably my last Windows laptop, I'm only still using it because it's a pain to get a new laptop and transfer everything all over and I'm kinda busy lately.

I have a 16 y/o iMac in the "technology museum" which is still surprisingly usable, running Snow Leopard or Lion or something, though I don't think I'd want to connect it to the Internet.

I have original machines in working condition back to Win Vista for support and certain ancient hardware custom IO, SCSI slide scanner for which no modern support exists. They are totally unsafe if connected to the outside world. Likewise many blue chip companies and universities have multimillion pound machines hung off a geriatric PC (with a spare in a cupboard somewhere). Typical lifecycle of really big science kit is around 20-25 years (ie Windows ME kit still running in places).

Such antiques have to be very carefully firewalled from the corporate network.

The threat to all of us is that if MickeySoft pulls support for Win10 and some really nasty malware gets into such a widely used OS the firestorm will do an enormous amount of damage. UK NHS has an incredible amount of vulnerable kit and underpaid inadequate IT staff for instance.

If they do pull the plug I expect an explosion of ransomeware attacks.

On MS Windows the preview rendering engine of emails in Outlook is sufficiently risky that I wouldn't ever want to use it.

W11 is slightly better. I skipped Win10 apart from one machine that I upgraded to be able to test and support code in that environment.

Of the ones currently available with third party toner the Xerox Phaser

Before that I had a Dell 1230c which I had from new and bought a second one from a junk dealer just to get the OEM toners. I got a working print engine too which extended heavy use life to 12 years before it finally expired. That was about the first half decent photoreal laser.

The print engines on those are almost indestructible. Our VH has one since about 2006 (it gets nothing like the hammer that mine do).

Martin Brown <'''newspam'''@Nonad.co.UK> wrote: |------------------------------------------------------------------------| |"I have original machines in working condition back to Win Vista for | |support and certain ancient hardware custom IO, SCSI slide scanner for | |which no modern support exists. They are totally unsafe if connected to | |the outside world. [. . .]" | |------------------------------------------------------------------------|

I use Windows Vista. No one cracks into this Windows-Vista computer, but maybe I am not near the front of the queue.

I do not compile on it, but as I do support Windows 10, then maybe it would be convenient to choose a version of link.exe from MS SDK or Visual Studio which is compatible with Windows Vista. If I may dare to ask, what version or versions - if any - do you use? (S.

I've moved most of my legacy *software* into VMs (I run VMware and a pair of ESXi servers with ~100T of VMs).

For legacy hardware, I keep a Compaq Portable 386 w/ expansion chassis (gives me two ISA slots!).

I also have several Neoware SBCs (X terminals in their original use) that give me a single PCI slot which I can use for a SCSI/SAS HBA to interface to old slide/film scanners (predate USB), ICEs, etc.

Undoubtedly. *NON* of my kit talks to the outside world besides

A colleague used to buy up old Sun "big iron" as his employer's enterprise was built on their products. His office looked like a computer museum -- all that kit "on hand" for the day when it would be needed to replace something that was already in service.

Hospitals and many manufacturing entities (think CNC machines) are similarly reliant on ancient hardware (a firm using Apple ]['s to host their embedded process control systems -- like my Sun friend, they were always on the hunt for obsolete kit from yard sales, etc. That's what happens when engineers design stuff for their own convenience without thinking past the "design" stage)

This has forever been a problem. Recall XP's retirement?

Aside from the OS, we use nothing of MS's, here. SWMBO is under strict orders not to open attachments, even if (apparently) from "friends". We browse and read PDFs in a sandbox, etc.

And, every 6 months, I pull the disk out of the outfacing machines, set them aside and reinstall the original image. Then, run a malware scan of the disk pulled 6 months before that (hoping that the scanners have matured to detect anything that may have been 0 day at the time THAT disk was pulled, 6 months earlier). Just provides some belated reassurance that we've not been used as a CnC for some botnet.

As I haven't bought any Windows-hosted tools in ages, I can skip entire release cycles -- save for WWW/SMTP use.

I used to have several (solid ink) Phasers with duplexers. *Delightful* results. But, the house would smell like burnt crayons whenever I used them. I would build a queue of materials that I needed "quality" prints and spend a day printing them.

The ink was outrageously expensive and the printer's startup cycle wastes a lot of it.

And, they are BIG printers -- like stack a pair of full sized lasers to get one Phaser!

I now have a pair of KRMs where one had resided; an SB2000 for the other. Much better uses of space.

They are nice because they don't eat a lot of power keeping their fusers "hot" when not in use. So, I can just leave them running (on single-port print servers) to access when needed -- one on the exposed network and the other on the airgapped network)

I've taken to using larger (18") tablets as "ePaper" for the times I just want to carry some information away from a computer.

My next goal is to set up a ("no service") phone to replace the countless "little slips of paper" (3"x3") on which we leave brief, inconsequential notes (grocery lists, reminders to call people, addresses, etc.) that never seem to find their way into the trash...

And, finish scanning the rest of my textbooks! Toner cartridges are the bigger hassle as they are long out of production. And, support in mainstream OSs (you could still get support for them under W7 but W10 seems to deny their existence)

The variety and quality of MS-hosted apps tends to be much better than their FOSS counterparts. One has (historically) had access to capabilities/tools, there, long before the FOSS community gets around to developing something comparable. E.g., I was doing 3D CAD (under a DOS extender) back in ~1990; schematic capture in the early 80's, PCB layout in the same timeframe, etc.

I don't let anything outside of my direct physical control. I don't want to have to rely on connectivity for anything but those things that require it (email/WWW). Its easier for me to just set up a server to address a specific need (e.g., my repository lets me archive ANY binary, not just my own sources; similarly for VMs, etc.)

There's just WAY too much content to be moving copies of it into/out of the house!

I only use a laptop when traveling (something I have been trying to avoid, as I get older). There, an email and http client -- plus a copy of FrameMaker (as I am *always* busy preparing documents and it is a relatively portable task)

My oldest "PC" is a Compaq Portable 386, kept for the ISA card support it provides me. I keep a Sun Voyager and SB2000 for access to SPARC hardware (and the tools that let me verify my code on it).

I have a LOT of tools. I've made an effort to keep everything that I've accumulated, over the years, operational. (This because I could, in theory, be tasked with supporting a past project at any time.)

Many of them are Windows based. Some SOLARIS, some BSD, etc. All of my UN*X boxen run headless; they are accessed via RDP, VNC or X servers running on the Windows machines. This so I can blend the use of each type of tool at a single display station. E.g., cut and paste snippets of code developed on a UN*X box into a document I am preparing under Windows.

They are grouped into 4 broad categories:

- Document preparation

- CAD/EDA

- Software Design

- Multimedia authoring each served by a different (identical) machine.

Of my "work" time, about 40-60% is spent doing document prep. Generating text, illustrations, charts, etc. Recording results of tests, etc. This usually calls on tools from each of the other groups (e.g., pasting a portion of a schematic or layout into a document; creating an animation to illustrate some process or concept; preparing audio snippets where prose would not be an effective way of describing what something sounds like, etc.)

I *live* in FrameMaker and rely heavily on the Adobe suite for photo editing, illustration, etc. Other tools to let me create typefaces ("fonts") for documents that don't rely solely on ASCII glyphs (e.g., my speech synthesizer required a commingling of IPA and dingbat symbols along with regular text). I keep all of the typefaces I've acquired over the years -- a few hundred MB -- "on line" as browsing OFF-LINE typefaces is a colossally impractical waste of time: much easier to just LOOK at them "live". Ditto clipart.

The same applies to EDA/CAD with the various symbol and footprint libraries, datasheets/manuals, 3D models, etc. I've tried to make EVERYTHING accessible just by opening a network connection (NFS, SMB, etc.) instead of digging through physical media.

I use Windows-based GUI tools to maintain my [sic] "databases" (which are hosted on BSD boxen). Data entry is just so much more convenient in that environment. And, ERDs are so much simpler to create in a WYSIWYG environment. Ditto MathCAD, MatLAB, Mathematica, Octave, etc.

I have scores of Windows/DOS-hosted asssemblers/compilers/debuggers for the various processors I've used or evaluated for projects, over the years. Ditto, source libraries. But, do most of my 9-to-5 software development under NetBSD with some special validation tools (e.g., certified compilers, symbolic execution, analysis tools) hosted under FreeBSD as it's "cheaper" to run a different OS than it would be to port those toold over to NetBSD. And, periodic jaunts over to Slowaris /et ilk/ to make sure my code isn't relying on aspects of one particular hardware architecture -- in case I decide to deploy on different hardware)

My VCSs run on separate servers with Windows and UN*X clients so I can check in/out from whichever environment is most convenient. Note that I can "afford" to use lower performing "servers" as there's only *one* human client!

I build animations and videos to illustrate certain issues in a more intuitive manner (e.g., how the geometry of your vocal tract changes when you make certain utterances or how a process is migrated from one host to another, while running) where prose and static illustrations are inadequate. If the goal is to ensure the reader understands the material, then find the most intuitive way to convey it!

I have a "digital audio synthesizer" in my current project that I can profile with certain windows tools to verify I've configured the synthesizer in a particular way.

I even have production video capabilities (e.g., television studio kit) so I can do things like superimpose one live video stream onto another, in real time, and add computer graphics to the mix (though I recently retired the video cameras as they were very large in their shipping/travel cases -- about twice the size of a little "dorm" refrigerator!)

Most of my networking tools are NetBSD hosted - though I have a couple that are Windows related (i.e., know all about Windows specifics) that run on Windows hosts.

I.e., it would be *beyond* PAINFULLY expensive to move all of these tools to another (Windows) OS -- esp when that move doesn't BUY me anything (and likely will cause some tools to stop working and others to require relicensing). I still lament the loss of After Dark (but don't have the time to develop a shim for it)! :<

Just the idea of having to feed (literally) hundreds of CDs/DVDs of fonts, clipart, 3D models, libraries, etc. into another machine (having already done so) to "install" them is daunting. (though I have been copying *ISOs* of those media to a server to make such a task a bit easier to script)

The Compaq lets me host an Opus PM (and the tools I have that run under it) and the SB2000 lets me host a Chimera II (for the novelty as well as *hardware* hosting of REALLY old MS stuff -- I think it is currently configured with W95 tools from a really old project)

I chuckle wondering how well I'll be able to juggle all the subtleties of *using* these different platforms as I age!

There should be a LTS fee for dinosaur storage, lots of technology is best left in the past.

It's annoying not having a particular tool when you need it, but gosh ISA is long ago.

OSBot makes some great compact cameras that do a lot of pan/zoom/track editing automatically with neural networks:

Can't you just emulate a lot of that old hardware if someone wants an update after 30 years, or whatever? Or not even necessarily emulate, many old x86 OSes like Windows 98 etc. run fine on a Ryzen with some CPU flag patches.

I don't know about ISA support for modern motherboards but this PCIe to PCI adapter card works fine with every legacy card I've tried:

Some folks really like IT management and mucking around with PCs and servers and stuff, I guess some get off on the feeling of power of bend some piece of junk to their will by learning all its cryptic commands inside and out.

Never got big into it, always seemed like the opposite of creativity to me. Aside from a NAS/backup server I have three work PCs these days which feels like two too many from a support/clutter point of view. I hate being a digital janitor.

Note that it wasn't "the past" when I was using it. And, the cost of recreating a toolchain (configured in exactly the way it was when you developed a product) is outrageous. Vendors have no real need to preserve older versions of their products so trying to locate a compiler version from a year ago may require cajoling a principal at the compiler vendor and HOPING he is understanding. Much easier to just KEEP it, *as* you had it installed, along with every other tool that you used for that project.

I didn't think the "lifetime bug fixes" notion through, completely. I hadn't realized how many projects would follow. Nor had I thought about the fact that each would likely use different tools -- and different configurations, etc.

Once I realized this, I started developing ways to preserve entire environments (which is primarily the disk image).

I tried dumping disk images onto 9-track tape and keeping

I tried installing multiple disks in a big tower and switching power to them so only the drive that I was interested in would respond.

I tried moving the disks out of the machine onto a SCSI bus (which, if quiescent, you can effectively hotplug and then rescan).

I tried big disk arrays (up to 48 disks at a time).

I tried using DLTs to store disks in a smaller space (than a physical disk required)

I finally settled on VMs. And, having the "original" disks available meant I just had to repackage the physical media into virtual media and find media on which to store it. As modern disks are so much larger, you can store multiple "original" disks on far fewer physical disks in their virtualized forms.

Of course, each successive project had me working in a "flusher" environment with more accumulated tools. So, each successive VM got bigger (it wasn't practical to figure out which *parts* of the environment were important to preserve as a failure to preserve some component that you had relied upon but didn't recollect could screw you, down the road)

But, that still leaves you reliant on other aspects of the machine's hardware. E.g., if an ICE requires a parallel port to communicate with the debugger running on the PC (before USB came along, serial was too slow for such interfaces). So, now you need a "genuine" LPT port (as the printer interface hadn't been virtualized, the debuggers would often talk to specific I/O ports expecting a traditional LPT port to reside there.) My Unisite requires 3.5" floppies and a way to duplicate them as well as move files on/off, easily. (I keep a laptop with floppy drive for this purpose)

Hardware (peripherals) evolution is just a nuisance.

There is value (to clients) in someone ELSE maintaining this legacy development environment. (I can recall a client trying to make a modification to a board I'd laid out in OrCAD 7 only to discover that their OrCAD *9* wouldn't read the files! "Ah, but Don can do this!")

It's primary support, for me, is the Opus PMs. This gives me access to GENIX, those compilers and some EDA tools that were hosted under GNX.

Nowadays, CPUs (and GPUs) are fast enough that one can do the sort of things that I was doing with LIVE video (and special hardware) in post. E.g., thre's enough horsepower available that a machine could do the chromakey processing to isolate key parts of one video stream and mix it on top of another.

They run fine in VMs. And, a VM just takes disk space (which I have in abundance).

The catch is any specific hardware that is required in addition to the software (stored in the VM). E.g., I have film scanners, slide scanners, B-size scanners and even a *40* inch scanner that can process *K* size drawings. But, the software almost certainly doesn't run under Windows 11, 10, 8, 7, etc. So, you need the OS and not just the application, then any other hardware.

I don't want to invest any more time than I had to, originally. Making an image (any of the ways I had attempted) is relatively low effort.

But, I want the tools that I *had* used to work as they did, originally. I don't want to have to learn how to use some other tool to perform a task that I was able to do, previously. Or remember some "trick" I had to use to get applications to cooperate with each other.

I just want to wait while a VMDK is created from a physical disk, move that onto a file server and forget about it.

"Digital janitor" is a good term for it. I'd rather keep things "clean" than let them deteriorate to a point where recovery becomes a real task.

Back-end development eventually also largely went to interpreted and JIT-compiled languages I think in large part for this reason, recreating tool chains sucks.

My impression is embedded developers still struggle more with this, because while I've thankfully not experienced the problem myself, cross-compilation is still not a perfect science and I've heard of cases where strange results occur compiling the same code for the same target with the same compiler version but on different platforms like e.g. Linux vs. Mac.

For either 8 bit or 32 bit development I use a constrained but modern dialect of C++ and most stuff can be mocked up on a desktop platform where it's easier to debug.

For 32 bit platforms there's JTT and for in-circuit debugging on 8 bit my favorite tool is still the serial port.

This all seems fairly platform-independent for the foreseeable future.

Ages ago, CPUs (rarely MCUs) were sorely resource constrained. My first product had 12KB of TEXT and 128 bytes of RAM. Not much room for anything beyond the working code.

Even compiled languages produced relatively bland code -- folks are spoiled by modern optimizers; old toolchains would create binaries that one could 'decompile' in their predictability!

But, you typically couldn't change to a different toolchain (same target) as many of the "undefined behaviors" and "implementation specific" aspects weren't portable. E.g., there was no ".asm" so all helper functions and hardware interfaces had to be created in whatever form the vendor supported. Likely not the same as some OTHER vendor.

If, for example, you had written a multitasking executive that needed to access the internals of the CPU/etc., this would typically require a considerable rewrite if you moved to another toolchain.

Or, pulling characters out of a UART.

Or, interfacing to bank-switching hardware.

This, IMO, is essential. Sadly, many developers feel uncomfortable without target hardware available -- even though most of their code doesn't interact with that hardware beyond instruction fetches, etc.

This makes it considerably easier to instrument the code and build test scaffolding to "prove" its functionality. Otherwise, you need hardware probes to extract "results" from a target. Doing this on a development host gives your tools access to anything you can imagine (albeit not in real-time -- which is often preferable as it gives your meatware time to understand what is ACTUALLY happening AS it happens).

Legacy processors didn't have internal support for debugging. The serial port was external to the processor so relied on more than just the CPU being operational (addr/data busses, decoder, control logic, memory, UART, etc.). Bringing up new hardware meant you couldn't count on ANYTHING to work.

But, the ICE would let you execute code out of *its* RAM (which means you can patch that code without having to rebuild the entire binary), set breakpoints using *its* breakpoint logic, capture execution traces using *its* capture buffer, etc.

And, interact reliably with the debugger running on/in the *host* regardless of how confused the CPU/target happened to be.

Imagine trying to bring up an MMU when you can't be assured the address and data busses (and decoder) are even operational, let alone your "programming" of the TLBs, etc.!

But, ICEs are expensive -- the least costly one I recall at about $1K

Supporting multiple processors (as a client may have a preference) gets expensive pretty quick! CPU manufacturers typically didn't provide tools as willingly they do now.

Early in my career, I would design such capabilities as add-on tools for specific processors (the design needing to be tweaked for the peculiarities of each processor). As you were only paying for components (not someone else's markup/profit), you could afford to get extravagant with the features you'd implement. So, instead of a single breakpoint with limited constraints (addr range, data range, bus cycle type, etc.) you could have multiple breakpoints, arrange for them to be enabled sequentially (wait for THIS, then watch for THAT, then break on WHATEVER).

There was considerable debate as to whether an ICE or logic analyzer was the tool-of-choice. The fact that an ICE would let you exercise the hardware despite its operational state was the clincher, IMO.

I could monitor memory locations in real time (by integrating the in-target debugger code with your MTOS to interact with a HARDWARE display/keypad) and get "inside" the product. And, could design the hardware so this capability remained present in production code -- by having the code dynamically probe for the debug hardware and link in the debug *software* located on it. This is a great win when you are deploying first articles and wondering why things aren't working!

Yes, but this assumes the processor -- and code/hardware within it -- are operational. And, that you can devote those resources to that function, "hereafter". An ICE doesn't *rely* on your hardware at all but just interfaces to it.

The serial port may be deprecated in favor of USB I/O. And, as more migrates into MCUs, getting access to that internal state (e.g., tracing execution or profiling it) becomes more problematic.

Well, it has been *way* easier for me! And, she's managing to adapt -- tbird and ffox being the primary apps so she's not required to learn much.

Not being able to multiplex the UI is a bit of a problem but I can just set up a second machine and use each of them as "single accounts" instead of sorting out that issue.

Don Y snipped-for-privacy@foo.invalid wrote: |------------------------------------------------------| |"[She was amazed at how much "snappier" the machine is| |without MS dragging it down...]" | |------------------------------------------------------|

SPEC insists on Windows but "June 20, 2017: Due to a known issue in Microsoft Windows Server 2016 memory management, the SERT® suite will not be supported on that operating system until a fix is made available.

June 20, 2017: SPEC cannot provide support on the SPECpower_ssj® 2008 benchmark for test failures using Microsoft Windows Server 2016 due to an issue with large pages and memory management in the operating system. Please contact Microsoft technical support for assistance. Completed runs on Windows Server 2016 will be processed for review as usual." says

(S.

In some sense, you've gotta feel sorry for MS as they are stuck supporting all this legacy stuff (even though it's THEIR legacy!). Ditto POSIX and all the other implementations that cling to the past (despite the fact that people aren't always using them to support EXISTING codebases but, rather, NEW designs!)

"Starting from scratch" lets you come up with cleaner and more robust designs and implementations instead of yet-another-bolt-on set of features (with their hidden assumptions and latent bugs)

Even if you assume only *1* defect per KSLOC, it's not hard to envision (tens of?) thousands of bugs just waiting to surface in some of these "products of evolution".

I do not consider COBOL 2023 to be clinging to the past.

COBOL has often been decreed a dead language by pundits and the media. However, I find only a few vague hints that COBOL might be in danger of dying or being replaced:

From a recruiting site:

The current version is COBOL 2023, which includes updates and improvements.

One can also run COBOL programs on Linux:

or on the cloud:

I don't see websites written in COBOL. Nor credit card terminals. Each present in "business transactions".

Nor are BASIC programmers likely "to be fully replaced by AI in the near future".

But, folks developing new systems think long and hard about how those will be supported in the future. You're likely to see COBOL-to-<whatever> converters nibbling away at existing codebases as *real* COBOL developers are hard to come by (not the job listing I posted a few days back for someone to maintain a COBOL codebase for the SSA).

Adam by all measures, is a much more efficient development "medium" than C yet you don't find many Ada developers or C/C++ developers rushing to embrace it -- despite it being a 50 year old language.

And the foreground was some "cash register" or "credit card reader" almost certainly NOT running COBOL.

Exactly. There's no DEMAND for new approaches; accounting is still accounting. And, security is likely enforced at the edge with the business software not directly exposed to adversaries.

You're not going to build a surveillance camera using such outdated technology. Or, a navigation system. Or, the AIs in a self-driving car.

Imagine how much code runs in mice and keyboards. And, disk controllers. NIC slushware. All things that run on/in every desktop machine, even if it never "does any business". What a huge market COBOL is missing out on, eh? <grin>

The bigger evolutionary problem is for (increasingly interconnected) "devices" that "run the world" without any reliance on business software. Does the traffic light controller need to perform any business/financial transactions? Or, the smart cameras that adjust its scheduling to adapt to the presence of local patrols? Thermostats, nannycams, garage door openers, VFDs, TVs/DVRs, cellphones, appliances that increasingly rely on electronics to replace old "mechanisms", etc.

These are the places where legacy ideas have opportunities to avoid the models that have led to buggy implementations. But, developers are loathe to think in new ways (even if those "new ways" are actually decades old!)

s/patrol/platoon/

Other typos can likely be resolved by context.

How can you tell?

They appear to interface with the browser in HTML but the underlying code that generates the HTML could be PHP, Basic, Algol, COBOL or almost anything.