When the author says 'I tend to run older hardware', how old do they mean? I'm typing this message right now on my Thinkpad x220 from 2011, which is unfortunately too old to run Zed because its internal Intel HD graphics card doesn't support Vulkan. I'd be an everyday user if not for this.
One of the coolest projects I've seen in a while! Amazing work! In case anyone missed the write-up^1, it's very well-written. I really enjoyed the chapter about designing the instruction set.
A lot of effort goes into accurately emulating historic processors in the MAME project, as well as other vintage hardware. It's generally accurate enough that MAME is regularly used to emulate vintage hardware when reverse-engineering devices.
Very cool! Would you believe I was actually just listening to some of the old Ultima game soundtracks when I saw this?
I wonder if they considered writing their disassembly in the 'pre-C++98 dialect of C++' used in the original, and targeting the original compiler. I've done some disassembly of binaries which ran on vintage systems, and I would've targeted the original toolchain if I could have. It's an interesting philosophical question.
Thinking about what would be going through Bill Kerman's little head as he approaches the rocket having just seen poor Jebediah Kerman vaporised on the launch pad was pretty funny. I don't think this same gallows humour extends to kittens.
To me it seems more sensible to store information relevant only to this OS in a specific cache somewhere within that OS. It would even make cache-like functionality such as evicting old entries super easy.
There are some tradeoffs. Like if you used a usb and set up folder colours or any of the other things stored in the file, they would not move along with the usb when used on another computer.
If I set a folder colour in Finder on my work MacBook, and then plug that USB drive into my personal computer which uses Thunar as a file browser on Debian, nothing would happen.
And? If you mount a Unix file system on another system, you may see ‘invisible’ fuels whose name starts with a period, may even see weird files named “.” or “..”, may not see ACLs, and may not see any file attributes such as user and group information.
In 1970 it already was not true that one could treat all filesystems the way Unix did, but it certainly isn’t true anymore today.
In case anyone doesn't know, Oxyrhynchus is a major source of archaeological discoveries. Particularly ancient (Ptolemaic/Roman Egypt) papyrus fragments recovered from an ancient landfill on the outskirts of the city. Notably some of the earliest-known Christian textual artefacts were found there (the actual earliest fragments came from elsewhere in Egypt). It turns out that Egypt's hot and dry climate provides the perfect environment for their long-term preservation.
Is this true? Paper (and I assume papyrus) expands and contracts with varying humidity even below the saturation point, and this motion embrittles and cracks it, no? So consistent humidity is key, and "consistently dry" is much more achievable than "consistently at an arbitrary other point."
Your intuition is more correct: it is not true. The relative humidity of the air matters below 100% as well. I think the parent commenter mistakenly assumed that only "condensation" matters, but materials will absorb moisture from the air even if the water doesn't condense. Entropy drives the dispersion of moisture, and some materials are "hygroscopic", meaning they don't merely reach equilibrium with the air, but actually concentrate moisture from the air and get significantly more wet than the air which feeds it water.
> Its unlikely that another platform would be able to reach this state...
Is this really true? The computer ecosystem is more open now than ever. The original PC BIOS (which PC-compatible manufacturers needed to implement) was never an open, documented standard. It was a proprietary, closed system made by IBM. It's pretty fair to say that IBM didn't anticipate a PC/x86 ecosystem developing around their product. They even sued companies who made their own compatible BIOSes (like Corona). Intel didn't really have much to do with the success of the product at that point in time either, much less Microsoft.
In contrast, every widely-used modern system for hardware abstraction (UEFI/ACPI/DeviceTree/OpenSBI/etc) are open, royalty-free standards that anyone can use. Their implementation in ARM is newer, and inconsistent, but that's only because of how hugely diverse the ARM ecosystem is.
I think the issue is that desktop and server computing are “open” in the sense that you have full control over the software you run on them. So people interpret the dominant desktop and server platform architecture (the world of x86-64) as being open.
The embedded world is mostly closed, you are meant to run the software your hardware comes with. The platform’s popular there are considered less open (ARM and RISC-V).
Mobile devices like phones and tablets are historically closed devices, regardless of ISA. They are generally getting more closed in the name of security.
It is not the ISA that is “open” but the industry.
That said, in RISC-V, there is a sub-current of openness. I do not think that will overcome the industry tendencies in general, but there will be a small cadre of folks trying to create an open presence in every niche. The good news is that there is nothing to stop them. They will succeed eventually.
The early PC era was a mess, and that's not the period I'm talking about. IBM was clearly not up to the task and Intel didn't care much yet, but Microsoft certainty did a lot for compatibility from the start (i. e. DOS abstracted away a lot of BIOS routines, so it would be easy to port MS-DOS to a non-IBM x86). But after IBM revealed MCA to show just exactly how much do they care about compatibility and platform openness, Intel realized they are missing out and cleaned up the MCA/EISA/VLB mess with PCI. Then Microsoft and Intel jointly released APM 1992 (which was clearly not enough), and then ACPI in 1996 (which is a total dumpster fire, but a sufficiently functional dumpster fire). I. e. ACPI and UEFI are exactly the product of the monopoly. M$/Intel profited from the abundance of cheapo white boxes, so it was in their best interest to come up with a standard even DELL can implement. The fact that AMD is going to implement the ACPI too wasn't much bother for Intel - they were so dominant that they could afford not to care.
On the other hand, ARM sells the cores to SoC vendors (and doesn't care much what becomes of it), SoC vendors ducktape the ARM cores to a bunch of Synopsys peripherals and sell the resulting SoCs to smartphone and car makers (and doesn't care much for the product). System integrators throw Android on top and sell it to the customers. Then Google, who get all the cream via Play, hides all the mess behind a thousand layers of Java abstractions.
DeviceTree is an offshot of Sun's OpenFirmware (and it leaves out all the hard stuff - OpenFirmware had Forth, DeviceTree expects the kernel to support every single brand of fan switch). OpenSBI is a disaster. I'm sorry, but what kind of bright mind came up with the idea of hiding damn *timer* behind a privilege switch? Timers were enough of a pain point on x86 already, then it settled on userspace-accesable RDTSC. RISC-V SBI? Reproducing x86 one stupid decision at a time.
reply