Just to humor you, I have a variable frequency power supply and have plugged various Apple power supplies into it (magsafe bricks and USB supplies). They all seem to work fine and aren't any warmer than usual. I've done 400Hz 90V and 240V, to test on both extremes of the input voltage range. 90V is the worst case for rectifier heating from the average current, 240V is the worst case for rectifier heating form switching losses.

You'd need big-ass selenium rectifier plates for this to matter. 400Hz will make the diodes run a bit hotter from switching losses, but I can't imagine any scenario where this would liberate so much heat as to cause a fire. More likely, the diodes would fail open and the device would stop working and that's that.

Yep. In fact, with proper overcurrent protection, most any modern switching power supply will work just fine from DC, too.

How the fuck does anyone offer NAND storage without error correction? WTF?!

As a rule, I buy decent 6 year old used cars for $6-$7.5k total, including travel to the place where I pick up the car, and the return drive, and the state tax. We've got 5 cars over 16 years so far that way, and most middle class people wouldn't need anything more than that. $36k is like 5 cars...

Where on Earth do you think Intel's low-end embedded microcontroller offerings come from? It's just the "management" silicon sans the main CPU around it. Intel's Edison and Galileo are just management silicon monetized again.

It'd probably be worth it to reverse engineer the hardware and write a modern Linux driver for the scanners, and then expose them as network services to clients written whatever your heart desires.

Multi-processing is only exploited when you design your system to exploit it. There was no wide-spread auto-parallelization of algorithms on these systems, at least not in the 80s. Certain database operations could be parallelized if you wanted to pay for it. The support on the application end was scant IIRC.

Decimal operations on modern ia32, ia64 and arm are implemented using 64-bit integers and not slow at all.

Yep. There was a time in Sweden where quite a few businesses ran on ABC machines from DIAB, networked using DNET cards running X.25 on a RS-422 token ring. Record processing was done using ISAM instructions in the excellent structured Basic that ran on those machines. It performed very well and was much easier to use than COBOL. And that was mid-80s! For business continuity, the DNET cards were made available with ISA interface, and the Basic interpreter was ported to PCs. That particular dialect of BASIC was a decent general-purpose language, and fast enough to implement decent interactive business applications running in text mode. There were serious accounting and ERP systems built on that.

Never mind the clunkiness of the old programming languages themselves, the entire build system and tooling support on these platforms is abysmal, as you've hinted. Modern containerized develop - test - deploy cycle is miles ahead in terms of productivity and robustness vs. these legacy systems. I'm pretty damn sure that the actual performance of the old monolithic single-threaded code is not exactly stellar either, and a lot of compiled COBOL could be easily replaced with much lighter SQL and Python running on its default bytecode VM, just to give one example. Those can then be easily scaled according to demand, using modern management tools. Scaling on big iron is nice on paper, but in practice - at least to me - it feels like going back to IT trade shows in the 80s. You'll pry Docker out of my dead hands, but only after rigor mortis subsides :)

And this point of view doesn't come from someone with no background. I used to play on CP/CMS and MVS systems as a kid. Had a DG Eclipse in my bedroom growing up. VAX already was a breath of fresh air compared to those. I had machines running CP/M, PC-DOS, some Swedish systems from DIAB running DNET (I still use embeedded X.25 at work - it's cheap). About the only thing I remember fondly about IBM infrastructure was the Rexx scriptability. I missed Rexx on DOS and CP/M. Then early Linux came to be and I promptly forgot about the DOS nonsense :)

I have no idea what you mean by "poorly optimized drivers". The only things that an X server is expected to do and do well today as far as screen drivers go is to composite pixmaps generated by the painting backends in Chromium, Qt, GTK, etc. An X driver is not meant to do any drawing anymore - yes, the X servers still leave the old code paths around so that some obsolete app might use the X server to actually draw other primitives on screen. Nothing of note uses an X server that way anymore.

Given this, there's really no sense to X. Wayland with a VNC backend is all you need for remote work.

X is largely irrelevant. Today, X is used to do three things:

1. Push pixmaps from the application to the screen. Notice that nowhere does X get involved in doing any rendering of those pixmaps.

2. Push UI events from the user to the application, and poorly participate in window management.

3. Allow applications to open a windowed OpenGl context.

It's a lot of cruft that does nothing much, only so that some obsolete pure X11 application will still keep on working. Architecturally speaking, it's nonsense. For modern apps you'll get much better performance if you attach a VNC backend to your application and access it that way (Qt allows it, I'd presume GTK should too somehow).

Of course, but that's just stupid. You'd need to flood that much because there's so little head available in most places. 700m head when you go underwater is nothing to scoff at. 10MWh per sphere is quite decent.

In absence of specialized instructions, a lookup table might work best on an 8/16-bit microcontroller with no cache. On anything more advanced than that, not doing memory accesses might save you enough time to do more computations and less look-ups. Another thing people routinely forget is that basic big-O notation by design only tackles computations, not memory access. A multi-layered memory system you'll find in any modern CPU that can easily give you lots of computations at a low cost if you can only feed the compute units with data, and be able to stream out their output. When these I/O paths are blocking, the computational efficiency of the platform can drop by multiple orders of magnitude - if you've only got a thousand elements, an O(n^2) algorithm that has a slowly evolving working set may perform better than O(n log n) where you're reliably forced to do log n page fetches from disk each time.

It's so dope :)