Technician keeps computer made in 1959 still humming along
asahi.com
asahi.com
The market for laptops did shrink significantly due to phones, but I know a lot of people that still prefer to use a classic laptop for home use.
So while the market did shrink, the rest was almost entirely destroyed by bad design decisions.
I still don't know why people use devices like iPads, it is a complete mystery for me. They are as useful as tramp stamps.
I couldn't care less about weight or dimensions if that means I could get high quality parts. Not I don't get them and some models are still beyond 1000$...
I suspect it's gonna be there 'til the day he closes shop, or he runs out of parts for the computer.
It might well be a miserable buggy experience compared to just using the original hardware.
Somewhat recently, Intel released GVT-g mode, which effectively allows you to carve up an Intel graphics adapter into chunks that can be used by VMs. I tried it on my laptop and it indeed works as advertised. https://01.org/igvt-g
The traditional method, though, is just having a secondary GPU with VT-d passthrough. This will give you the raw performance of a dedicated GPU, and you can either connect it to an external display for no latency, or you can use something like LookingGlass to get a more traditional setup (SPICE input + KVMFR video.)
I used GPU passthrough for a while, only stopping because it occurred to me that modern Wine and Steam Proton had largely closed the gap for me in needing virtualization for graphical applications. libvirt + Qemu/KVM + virt-manager with Windows guest SPICE agent installed is my weapon of choice these days. Without a GPU passthrough configuration, dragging windows is a little laggy, and I can't imagine graphical programs will work well since there is no 3D acceleration, but the performance with a lot of other tools (like Visual Studio) seems fairly acceptable. I will note that they should really make an easier auto-install for the SPICE drivers and agent, because it was tricky enough that it took me a while to realize I didn't actually have the right agent installed.
VirtIO block and network devices also can offer some I/O benefit, though you will want to use the Load Drivers mechanism to load the viostor driver prior to installation; it's a little tricky to switch to VirtIO storage later, since the driver obviously needs to be available during early boot. You probably also want to avoid qcow2 storage, instead opting for raw image or even disk passthrough for better I/O performance.
I love the idea of a 2nd GPU, and I have a couple laying around that it's definitely worth trying. I already have three screens on my desk... what's one more?
I'm thoroughly impressed with the Wine project, and yet I'm generally hesitant to install it on my system. I think it may just be the massive install list I get when I try to `apt install` it. I've a similar aversion to installing KDE apps on a system that's not already running kde, which generally include about 150 other k* libs.
Steam Proton looks great. I'd played a few games once Steam started releasing them on linux and truly enjoyed how well some worked (and some _really_ didn't). I don't play as much lately, but this may change that.
It's going to take me some time to read about and further understand everything else you've posted here, which I appreciate.
Steam Proton is great since it doesn’t do that and is mostly automatic. I was surprised to see Direct3D 11 titles running just fine at 60 FPS and maxed out settings, very cool.
And yeah, GPU passthrough is kind of the holy grail for desktop VMs. It’s definitely a little tricky, but once you have a good setup going it’s hard to beat. There’s a lot of guides. NixOS really shines here because your entire configuration can be declaratively configured, making your setup easily reproducible and surfacing all of the configuration in one place, but it’s obviously not distro dependent in any way and will work fine on Debian or Ubuntu.
Some downsides:
- Not all machines can VT-d, some can but are not stable. This is better today than ever.
- Your VM GPU needs to be in its own IOMMU group. Modern motherboards tend to do this basically automatically it seems, though its not guaranteed and if not your only workaround is a patch that lets you “split” the groups in an unsafe way that breaks isolation.
- Audio is tricky. Looking Glass does not forward SPICE audio today, so most folks configure qemu to output directly to PulseAudio. If you are using a physical display this approach obviously still works. You can also attempt to forward a USB audio device, or use audio over HDMI/DisplayPort.
edit: I hopped on my desktop. Here's my former NixOS configuration for GPU passthrough, to give you an idea of what kinds of system level configuration is needed:
# IOMMU configuration
boot.kernelParams = [ "amd_iommu=on" "pcie_aspm=off" ];
boot.kernelModules = [ "kvm-amd" "vfio_virqfd" "vfio_pci" "vfio_iommu_type1" "vfio" ];
boot.extraModprobeConfig = ''
options vfio-pci ids=10de:13c2,10de:0fbb
options kvm ignore_msrs=1
'';
boot.postBootCommands = ''
# Enable VFIO on secondary GPU
for DEV in "0000:0a:00.0" "0000:0a:00.1"; do
echo "vfio-pci" > /sys/bus/pci/devices/$DEV/driver_override
done
modprobe -i vfio-pci
# Setup Looking Glass shared memory object
touch /dev/shm/looking-glass
chown john:kvm /dev/shm/looking-glass
chmod 660 /dev/shm/looking-glass
'';
virtualisation = {
libvirtd = {
qemuOvmf = true;
# To make the PULSE Qemu audio driver work.
qemuVerbatimConfig = ''
namespaces = []
nographics_allow_host_audio = 1
user = "john"
group = "kvm"
'';
};
};
Simple VT-d is supported in the form of DDA in Hyper-V - I have not attempted to use this for a GPU and I’m not sure what limitations it may have versus KVM’s PCI passthrough.
I think I also read somewhere that older Windows (and some other operating systems) don't handle modern TCP/IP very well. A TCP session start with window size 9 and ECN bits, for example. And I believe there's more timing problems with networking as well, because no one believed in gigabit Ethernet back in the day.
Every decade or so I boot an old DEC Alpha. Last time I dist-upgraded Debian (woody to etch?) and everything worked - if a tad slow.
The power of nostalgia.
I plan on flashing it with libreboot and want to give guixsd a try as a daily driver.
There's a similar analogy to this in the automotive world, where early cars were simple and one could easily service and maintain them, even fabricating new parts as necessary; at the same time, they're nowhere near as efficient as modern equivalents.
Yes. And even then, the relays can be repaired. The NYC subway system has a shop that refurbishes the relays of their signaling system.
I restore old Teletype machines. The ones from the 1920s and 1930s are the easiest to restore. They're mostly all steel and cast iron. Once you clean, oil, and adjust them, they usually work, unless the machine was seriously damaged. I have five running Teletype machines.
The post-WWII machines are harder, but still repairable. The ones from the 1960s and 1970s are really hard, and some of the plastic parts have to be fabricated. The last Teletype, the Teletype Model 40 (1979-1984) appears to be hopeless. The print chain deteriorates over time, and making a new print chain, with all the little character slugs, would be a huge job.
Restoring current electronics, with SOIC chips, will be hopeless after the ICs wear out.
Museums that keep old machines working need a large operating budget. The Smithsonian used to keep all their clocks wound and running, their piece of the ENIAC was powered on and counted up, and the Atlas Missile Guidance Computer was run regularly. None of those run any more.
Last visit I was able to play the original "SpaceWar!" on it and the demo was run by Steve Russell and Peter Samson. Great to see pivotal computer history that directly impacted my life as described by people directly involved in making that history.
The other nice thing about these old machines is you can understand the whole thing. You get a better idea of what is fundamental and what is just fashion.
IDK. The android emulators I run on my Mac sure don't seem perfect. For one thing, scrolling a RecyclerView up and down using the mouse doesn't always work right. Gesture detection seems to lag or miss events sometimes. Working with a physical android device is often more stable and "solid" IME.
OTOH android emulators do seem pretty fast.
Not to mention the fun of playing with front panel switches. I built an emulator for one long before I acquired my IMSAI. They did not behave at all how I expected. Even more interesting the front panels are not synchronous on these "hobby" machines from the 70s but instead are timed by RC circuits that are supposed to be "close enough" to the CPUs clock.
Not all of these problems are from age (although that has an effect), the hardware was pretty flaky even when new.
That is by far one of the most curious things I've ever read on Hacker News.
Also, $1M is a lot of money to risk subtle changes to the logic of a 40-year old program. Main reason why big financial orgs are still running software from the 50's on mainframes, that.
Can confirm, I had a job that was essentially get legacy code working on new systems. There were guys there that had been around since the inception of the thing and kept things running smoothly. The downside is they were always opposed to any sort of refactoring or rewrite, even if that made sense.
I own some old kit that I like to keep working mainly some Amiga and Atari ST machines and he's 100% right. Unless people see what they are doing they literally assume they are some sort of keyboard.
Probably in Manchester as that was a bit of a thing up there -Later on I helped refit an office for the third time after they had been cleaned out twice.
I personally try to thank our office's cleaning lady. She does a lot of work, and everyone appreciates it.
I was simply trying to explain to my colleague who has known a world with modern computers being prevalent that there are still many people that have never used them.
Plus, if they really do meet that second qualification, disparaging them for it only makes you look even worse.
I would encourage you to seek out somebody who does meet those qualifications. You might learn something.
Quite a lot of people that do "Blue Collar" jobs that are in their 50s and 60s probably don't have to interact with a computer that often (I know my father doesn't). If they do it is normally through a kiosk of some sort or they are using their phone.
I was actually adjusting my coworkers expectations. He is younger than me and the thought hadn't entered his mind that someone may have never used a modern computer.
So in future before you start spouting about people being entitled, maybe you should not make a bunch of assumptions that is based on your incorrect reading of a comment.
https://www.popularmechanics.com/technology/infrastructure/a...
When it finally gives up the ghost it's likely going to cost thousands to design a new system with modern hardware, which doesn't even include the cost of writing up all the new safety documentation and grounding the aircraft for a refit! To add to the headache, it's all written in BASIC so the only ones who knew how to do anything with it have long retired or passed away. I don't look forward to the day I have to reverse engineer that bad boy.
On a simple clock comparison, it was about a million times slower than a Raspberry Pi Zero. Computing has come a LONG way
The FACOM128B is asynchronous, and takes about 0.15s per instruction using the same estimation (1.5x best case), so about 7 instructions per second. See timings at: http://museum.ipsj.or.jp/en/computer/dawn/0012.html
However, the FACOM128B is 69bit, and the Atmega is only 8bit (it can do some 16bit operations, but those are limited to certain registers and operations, so I'll just assume it's only 8bit). 69 is about 9 times bigger than 8, so I'll assume the FACOM128B can do about 9 times as much work per operation (there is overhead in calculating wider results from narrow operations, but the full width isn't always needed, so this simple estimate seems reasonable to me).
Therefore the FACOM128B is like an Arduino with about a 190000x slower clock.
The keystroke was too heavy and couldn't accept fact consecutive typing because of head jamming.
Now what is remaining for me is to use the working VT100 terminal and teletype.
As it happens, this came handy throughout my career (before and after I was a software developer). No matter what you do, you are much more productive on a computer, if you can type without looking at the keyboard at 70-80 wpm (not bragging because in the world of good touch typists, that is a poor score).
Humming would be hitting a HALT and waiting for the operator to press a button.
Kinda sorta. Relays are mechanical devices that wear every time they're toggled. Every time you toggle a 1 to a 0 or vice versa, you risk destroying a relay.
Vacuum tubes don't have moving parts, so the wear is significantly reduced. However, when they're on, they're very hot, so their wear is related to power cycling. Every time you power the machine or power the machine off, you risk destroying a tube. Colossus was kept in a powered on state 24/7, even when not in use, despite using an ungodly amount of power. It was a measurable proportion of all of the electricity used on all of Britain during WWII.
So if you never run any programs on a relay computer and keep it in a low humidity basement, it will last indefinitely. But if you use it to do stuff, you'll be diagnosing and replacing failed relays routinely. If the computer has a clockrate of 10Hz and uses reed relays (the long life kind) with a lifetime of 10 million cycles, you can expect any individual relay to last 2,000,000 seconds of continuous use. Which is about 23 days. Multiply that by 1,000 relays and you've just figured out why it takes a full time employee just to keep the machine running. Imagine a RAID array using drives with a MTBF of 23 days. Eww.