That made me think of Law and Order (since I remember reading that day players want to get on those shows for the residuals), and I saw a relatively early episode of SVU on a rerun that looked freshly shot.
Because children watched them on 13"-25" tube TV's that were designed to make those imperfections look acceptable (for the time), that a modern display blows up to proportions never seen during production even with the best studio displays of the era.
semi-related: I'm visiting my parents with a Sony OLED, and the frame interpolation made parts of Monty Python and the Holy Grail look like it was shot on an HD video camera.
This has been my conclusion as well. A lot of people complaining about the quality, bugginess and general fragility of vibe coded codebases are comparing it with their own personal, thoughtful, (and expensive!) dev process.
Having inherited a couple of hastily written but dirt cheap offshored codebases to fix, I would rather vibe code than try to untangle those garbage code bases.
Vibe coding is terrible compared to the thoughtful output of a seasoned dev, but is significantly cheaper, faster and easier to iterate on than the lowest bidder offshored. Undoubtedly most offshore coders will just vibe code anyway, so in the near term I suspect LLMs will impact these “programmers” the most.
Rather than signaling AMD's bankruptcy, this could be seen as a strong indication of how heavily China is investing in legacy technologies. That's why I wouldn't be so quick to draw conclusions. China’s eagerness in this area doesn’t mean that the investments are efficient. What truly matters here is the ability to build a full ecosystem. They practically wiped Huawei off the global smartphone market simply by banning Google services on their devices.
If done correctly a ~35 year old Laserdisc's glue layers are still fine. This depends on the plant and when the disk was produced, but Pioneers plants were quite good by the late 80's.
Most 1980's CD's are still fine, except for ones made by PDO UK.
I'm not sure if the glue layers in DVD are organic or not, but I think the rainbow part itself is aluminum.
It's an honor to get a reply from the ELKS inventor! In your own assessment, how much would you say does ELKS have in common with the Linux of back in the day? I've read you say something along the lines of "many of the structures are similar to pre-SMP Linux", but I wonder how much of Linux-of-back-then translated well to x86's segmented memory model without MMU and privilege levels of any kind, and how much of it required significant reimagining. I imagine segmentation instead of paging alone means that the mm layer is probably its entirely own design?
By the way, there used to be some few MMUs for pre-286 x86 CPUs back in the day. It was all extremely custom stuff as far as I can tell. The one I'm mostly familiar with was for 80186, and made entirely out of 74xx style logic chips and a bit of SRAM. It supported page-granular mapping and protection across multiple (hardware-defined) process address spaces + kernel, and even I/O space protection (though original SINIX, the system that used it, did not seem to end up turning on I/O protection for some reason). No on-demand paging though, i.e. page faults had to resolve to killing the process instead of resolving the fault, as the pipelined design of even 8088 CPUs already made restarting instructions entirely unpractical.[1]
It would have been fun to see ELKS support such things, though I don't have the time and energy left to look into that nowadays (especially given that those super-bespoke MMUs were never very common, and are virtually extinct today). I also guess that the more interesting MMUs, i.e. the ones that do have page-granular mapping, also wouldn't fit very well with ELKS in the first place, as it's (presumably) entirely written for segmentation.
[1] There is the famous Silicon Valley lore of a workstation manufacturer running two 68000 CPUs in lock step to work around similar limitations, one CPU running behind the other one so it can be used to "restart" the faulting instruction, but that's a story for another day.
Thanks! It was a long time ago(tm) so my memory's dim (maybe even so-dim), but yeah the MM (and console) code were pretty much original. The VFS and filesystem code were cut down from contemporary Linux quite a bit.
Never had any hardware with those exotic MMU's, so working with them never crossed my radar.
Paging MMUs are still useful, one could just tell the memory allocator to place user space programs at 4K, or even 64K, boundaries.
I realized last night (almost 30 years late!) that I should've implemented a BIOS-type interface (or modified EMS) to do memory mapping and then had a few different handlers (memory swapping, 286 and 386 LOADALLs, 386 v86 mode, etc) to choose from without messing with ELKS itself too much.
Working on ELKS now has the great advantage that the emulated 8088 PC is now faster than the computers anyone had back in the 90's, and all of that emulation can easily fit in CPU caches.
I can't pick these up for a few reasons (#dayjob and other hobby projects that I don't have enough time/energy to work on properly!), but here's a couple of thoughts that've been percolating for a while that didn't make the last topic:
- If I were a 19-year old (and odd) college student thinking about starting something like this again (I picked up the idea from Alan Cox and did the early versions suuuuch a long time ago now!), I'd have targeted the Pi Pico, and been absolutely estatic when the RP2350/Pico 2 came out.
You could make a pretty interesting 80/early-90's workstation using a couple of rp2350's (one for frontend, the other to run the hacked-up Linux) w/additional SRAM and Flash.
- One can use a 386+ as a memory mapper/protection unit while still running everything the rest of the system in real/v86 mode, in blissful ignorance that it's running on a 32-bit system.
There's a few RISC-V single-chip computers that put the Raspberry-Pi's products to shame. I'm evaluating the Bouffalo Labs BL808 and the Sophgo SG2000 for an upcoming project. They have MMUs and enough integrated RAM to run a mainline POSIX operating system. Both have multiple asymmetric cores that allow one to run a full Linux OS, one to run an RTOS or bare metal, and one for low-power tasks to run while suspended.
They're basically as capable as a Pi Zero, but work in a Pi Pico form factor. Check out the Ox64 and Oz64 boards from Pine64 or the Duo series from Milk-V.
