It has been years since I was familiar enough with the insides of SSDs to tell you exactly what they are doing now, but even ~10-15 years ago it was normal for each raw 2k block to actually be ~2176+ bytes and use at least 128 bytes for LDPC codes. Since then the block sizes have gone up (which reduces the number of bytes you need to achieve equivalent protection) and the lithography has shrunk (which increases the raw error rate).

Where exactly the error correction is implemented (individual dies, SSD controller, etc) and how it is reported can vary depending on the application, but I can say with assurance that there is no chance your OS sees uncorrected bits from your flash dies.

OpenAI's spending is mostly buying compute from other people. In other words, OpenAI's growth is paying for Microsoft's data centers. The only real asset OpenAI is building are their models. While they may be the best models available today it is unclear if that those any durable advantage since everyone in the industry is advancing very quickly, and it is unclear if they can really monetize effectively them without the infrastructure to run them.

Here is a gift link a NYTimes article with more details: https://www.nytimes.com/2012/02/19/magazine/shopping-habits....

Why build a new browser in C++ when safer and more modern languages are available?

Ladybird started as a component of the SerenityOS hobby project, which only allows C++. The choice of language was not so much a technical decision, but more one of personal convenience. Andreas was most comfortable with C++ when creating SerenityOS, and now we have almost half a million lines of modern C++ to maintain.

However, now that Ladybird has forked and become its own independent project, all constraints previously imposed by SerenityOS are no longer in effect. We are actively evaluating a number of alternatives and will be adding a mature successor language to the project in the near future. This process is already quite far along, and prototypes exist in multiple languages.

“A randomly generated UID is fused into the SoC at manufacturing time. Starting with A9 SoCs, the UID is generated by the Secure Enclave TRNG during manufacturing and written to the fuses using a software process that runs entirely in the Secure Enclave. This process protects the UID from being visible outside the device during manufacturing and therefore isn’t available for access or storage by Apple or any of its suppliers.“

Symbol versioning allows you to have multiple symbols with the same name namespaced by version, but you still have no control over what library in the search path they will be found in. So it does not improve the speed of the runtime searching (since they could be in any library an the search path and you still need to search for them in order), and it does not provide the the same binary compatibility support and dylib hijacking protection (since again, any dylibs earlier in the search path could declare a symbol with he same name.

One could use symbol versioning to construct a system where you had the same binary protection guarantees, but it would involve every library declaring a unique version string, and guaranteeing there are no collisions. The obvious way to do that would be to use the file path as the symbol version, at which point you have reinvented mach-o install names, except:

1. You still do not get the runtime speed ups unless you change the dynamic linker behavior to use the version string as the search path, which would require ecosystem wide changes.

2. You can't actually use symbol versioning to do versioned symbols any more, since you overloaded the use of version strings (mach-o binaries end up accomplishing symbol versioning through header tricks with `asmname`, so it is not completely intractable to do even without explicit support).

I do wonder if it might make more sense to rewrite the binaries to use Direct Binding[1]. That is an existing encoding of library targets for symbols in ELF that has been used by Solaris for a number of years.

1: https://en.wikipedia.org/wiki/Direct_binding

On Darwin we redesigned our fixup format so it can be efficiently applied during page in. That did in include adding a few new load commands to describe the new data, as well as a change in how we store pointers in the data segments, but those are not really properties of mach-o so much as the runtime.

I generally find that a lot of things attribute to the file format are actually more about how it is used rather than what it supports. Back when Mac OS X first shipped people argued about PEF vs mach-o, but what all the arguments all boiled down to was the calling convention (TOC vs GOT), either of which could have been support by either format.

Another example is symbol lookup. Darwin uses two level namespaces (where binds include both the symbol name and the library it is expected to be resolved from), and Linux uses flat namespaces (where binds only include the symbol name which is then searched for in all the available libraries). People often act as though that is a file format difference, but mach-o supports both (though the higher level parts of the Darwin OS stack depend on two level namespaces, the low level parts can work with a flat namespace, which is important since a lot of CLI tools that are primarily developed on Linux depend on that). Likewise, ELF also supports both, Solaris uses two level namespaces (they call it ELF Direct Binding).

  static void *(*nextmalloc)(size_t) = NULL;
  if (!nextmalloc) 
    nextmalloc = dlsym(RTLD_NEXT, "malloc");
  }

Admittedly supporting that would require updating how all the tools are built and not just defaulting to Whatever Linux Does™, which is probably too much effort to justify in this case, but it is hardly an unsolvable (or even an unsolved) problem.

Yes, you can do all the same things in software, in fact it is trivial, just take the same output from you EDA tools and run it in a simulator. Of course that is so slow it cannot interface with (most) real external HW like CRTs and accessories, but in some technical sense it is software taking the exact same set of inputs as an FPGA, and generating the exact same outputs (just much, much slower).

If we accept that as the premise then then we can consider emulators an optimization where instead of using the simulated verilog we try to manually write code that performs equivalent operations, but can run fast enough to hit the original timing constraints of the HW we are replacing. The thing is that the code is constrained by the limits of the modern HW it is running on, and sometimes the modern HW just cannot do what legacy HW did.

An NES does not have a frame buffer (it does not even have enough ram to hold ~5% of a rendered frame of its output!). To cope with that the games generate their output line by line as that the video signal is being generated. What that means is that you click a button on the controller it can change the output of the scanline that is currently writing to the screen (and you can release it updating the output before the frame is being generated, changing subsequent lines). IOW, the input latency is less than a single frame of input. That is not true with modern computers where we render into a memory mapped frame buffer which is then transmitted to the screen with a complex series of of chips including the GPU and DC, and ultimately synchronized on the blanking intervals.

On an FPGA you can design a display pipeline that matches that of legacy consoles, and get the same latency. Of course you could also do the same thing in software emulation on a computer if you clock it so high that it renders and outputs one frame of video for each scanline of output on the original, but given the NES had a framerate of ~60 (59.94) fps and vertical resolution of 240p that comes out to a framerate of ~14,400 fps to hit the latency target for accurate emulation.

Now in practice most of the time it is a non-issue and emulation is more than sufficient, but some old games do very funky things to exploit whatever they could on the limited HW they run on.

It is also worth noting that FPGAs are a lot more interesting for older systems. Once you get to more modern systems that look more like modern computers the strict timing becomes less important. In particular, once you get to consoles that have frame buffers the timing becomes much less sensitive because the frame buffer acts as a huge synchronization point where you can absorb and hide a lot of timing mismatches.

In 1985 when the 386 came out I believe the fastest speed you could get was 16MHz. They added higher speed variants for years afterwards. Intel made a 40MHz 386 in 1991 that was strictly aimed at embedded users who want more perf but were not ready to move to 486 based designs (386CX40), I doubt almost anyone used on in a PC. AMD made a Am386 at 40MHz which was a reverse engineered clone of the 386, but again that came out in the 90s (the big selling point was that you could reuse your existing 386 motherboards instead of replacing them like you needed to for a 486).

* The most obvious is the commonly mentioned fact that syscalls may change. Here is an example where golang program broke because they were directly using the `gettimeofday()` syscalls[2].

* The interface between the kernel and the dynamic linker (which is required since ABI stability for statically linked executables is not guaranteed) is private and may change between versions. That means if your chroot contains a `dyld` from an OS version that is not the same as the host kernel it may not work.

* The format of the dyld shared cache changes most releases, which means you can't just use the old dyld that matches the host kernel in your chroot because it may not work with the dyld shared cache for the OS you are trying to run in the chroot.

* The system maintains a number of security policies around platform binaries, and those binaries are enumerated as part of the static trust cache[3]. Depending on what you are doing and what permissions it needs you may not be able to even run the system binaries from another release of macOS.

In practice you can often get away with a slight skew (~1 year), but you can rarely get away with skews of more than 2-3 years.

[1]: https://developer.apple.com/library/archive/qa/qa1118/_index...

[2]: https://github.com/golang/go/issues/16606

[3]: https://support.apple.com/guide/security/trust-caches-sec7d3...

The LCII on the other hand is a bit less excusable since it could physically hold 12MB but only 10 was usable. As I said I suspect the reason is that it was a fairly quick revision they squeezes in before the redesigned LCIII and they just didn’t rev those parts of the ROM, but it still seemed pretty bad).

If you want more info there is a pretty deep dive on this here: https://68kmla.org/bb/index.php?threads/technical-explanatio...

First off the LC was in no way a threat to the Iici. The IIci had 32 bit data bus with a 25MHz 68030 and and supported a CPU cache. The LC with a 16MHz 68020 with a 16 bit bus. The Iici was conservatively twice as fast.

Second, the LC HW did not support nearly as much ram as the Iici. It shipped with 2MB soldered down (which logically you can think of 2 1MB SIMMs) and had 2 slots that each supported 4MB SIMMs, which were the highest density commonly available at the time. The (cheaper) memory controller used in the LC only supported 24 bits of physical addresses (and only in so many configurations), resulting in a maximum of ~16MB. Once you account for the soldered down two megabytes and how the slots had to be configured that left you with the ability to install 4MB into the each slot you get 10MB.

Technically speaking it was probably possible to get it to support 12MB or 16MB with a ROM patch if you desoldered the builtin memory and soldered from the address lines on the controller to some custom memory board. But as shipped with the builtin RAM and the controller chip they included 10MB was the most it could reasonably use.

The LCII did up the builtin memory to 4MB and had a software limit of 10MB like the LC (which meant if you installed 4MB SIMMs you would be missing 2MB), but I suspect that was more a result of how quickly it came to market (it was essentially just an LC with a 68030 and 4MB of ram, both of which greatly improved the experience of using the machine with System 7, which shipped after the original Mac LC).

Within a year or so after the LCII the the LCIII shipped with a completely redesigned board, and it supported 36MB of ram.

Source: I owned a Mac LC, paid for and installed a 2Mb memory upgrade to get it to 4MB, then eventually did a motherboard swap to upgrade it to an LCIII. I can even still tell you how much each of those upgrades cost ;-)