Specifically, oil cooled Porsches take that much, because they have to fill the oil cooler at the front and the lines that lead to the engine at the back.
- original Quake CDs are of limited supply since new ones aren't being pressed.
- your CD player has to be smart enough to recognize Track 1 as data and skip it or else it will blast your ears with two minutes of loud static before the music starts.
- the audio tracks on the Quake CD were mastered with pre-emphasis and your player has to support applying de-emphasis equalization or else it won't sound right. I did check my copy when writing this comment and the TOC does at least flag `PRE`, so supporting players should do it automatically, but still there are loads of ways this can go wrong because it's a relatively niche CD feature and because most modern software players won't handle it at all:
What's so important about retaining your existing account? Remove payment methods, change the account email address, then close the account and open a new one.
You may not have ever had to deal with SCSI termination errors before. Earlier system had to have the device numbers manually assigned, if they were wrong, all sorts of weird things could happen (of just nothing would work)
I'm a SCSI fan, but it took a few revs to get it righted.
SCSI was so much less tedious than dealing with IRQ / DMA / address hell on ISA cards, though. Once you understood it you could apply that knowledge across lots of platforms and devices. SCSI was much less arbitrary than dealing with random devices from manufacturers who each thought up their own way of setting configurable parameters (jumpers and DIP switches, option ROMs, tool you boot in DOS to frobnicate settings in an NVRAM, etc).
There is some truth in that. Like I said, I'm a fan, but I also remember some painful times where we were missing a physical terminator and at least twice adding a new device and had to check the jumpers on everything and someone one of the jumper blocks were upside down or maybe we couldn't tell which pin was 1 or something such that the devices were numbered wrong. We got it fixed and working every time though.
Aside from the time we lost a terminator for a few days, I never once felt like the scsi system couldn't work, it was just a matter of a really young me and my dad getting it sorted out. IRQ/DMA/ISA fuckery? There were multiple times I can remember getting a shiny new piece of hardware, that took months of begging my parents, and after getting things assembled thinking that "this configuration of devices" might not be possible to make work together.
SCSI cost too much for the extremely cost-conscious PC market of the early 90s. They'd already consolidated down all the IBM PC legacy buses (e.g. parallel, serial, AT keyboard interface etc) into a single chip that cost peanuts.
USB started off as a way to replace the legacy buses with something even cheaper, so naturally the PC industry bit. It wasn't really even supposed to do SCSI things; that was Firewire's job. We didn't get equivalent performance out of USB up until version 3.0 which isn't even the same bus as USB 2.0.
The underlying tension is that there are two different kinds of computers that want to do different things with their I/O:
1. The "SCSI philosophy" is to make peripherals that feel like extensions of the high-end computer you just bought.
2. The "USB philosophy" is to give you the cheapest connection you can get to a thing that works.
A good example of this philosophical divide is daisy-chaining. SCSI, Firewire, and Thunderbolt all supported it because it's the premium way of doing things. USB makes you buy a hub separately if you want more connectivity. Or, alternatively, you can look at this as SCSI and it's successors forcing you to buy a hub with every device you plug into them.
You might think that USB won out, but really, this debate still rages on, because Thunderbolt wound up being rolled up into USB-C and USB4. So now USB has to be both a cheap and premium bus - hell, Thunderbolt even used daisy-chaining instead of hubs on USB! This is why USB-C cables and devices are a mess; they designed USB-C specifically so you could flood the market with cheap 2.0-only cables that are only ever going to be used for power; and super-premium USB4/DP cables for plugging your laptop into a $200 laptop dock just to get back the ports you should have had anyway.
And, I must stress this enough, most of those fancy USB-C altmodes never made it to desktop anyway. I think you can buy Thunderbolt cards that will mux DisplayPort but you have to use a wrap-around cable to go from your GPU to your TB card like we're back in the 3dfx Voodoo2 era or something. Most of USB-C's single cable functionality is super-premium stuff that required a level of internal integration that desktop never committed to. Which is, again, very SCSI-brained, except now the cheap consumer stuff has it and the expensive modular desktops don't.
As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to.
You could imagine creating a modified Go assembler that is more generic and not tied to Go's ABI that could accomplish the same effect as LLVM. However, it'd probably be better to create a project like that from scratch, because most of Go's optimizations happen before reaching the assembler stage.
It would probably be best to have the intermediate language that QBE has and transform that into "intermediate assembly" (IA) very similar to Go's assembly. That way the IL stage could contain nearly all the optimization passes, and the IA stage would focus on code generation that would translate to any OS/arch combo.
> As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to.
I don't think that's true. Zig have a cross-compiler (that also compiles C and C++) based on LLVM. I believe LLVM (unlike gcc) is inherently a cross-compiler, and it's mostly just shipping header files for every platform that `zig cc` is adding.
I do not have enough knowledge to say anything bad about LLVM. As an "amateur" compiler writer, it did confuse me a bit though.
What I will say is that it seem popular to start with LLVM and then move away from it. Zig is doign that. Rust is heading in the direction perhaps with Cranelift. It feels that, if LLVM had completely nailed its mission, these kinds of projects would be less common.
It is also notable that the Dragonegg project to bring GCC languages to LLVM died but we have multiple projects porting Rust to GCC.
reply