IRC channel logs
2023-02-27.log
back to list of logs
<oriansj>essentially any audio device becomes a viable storage medium when bootstrapping. <muurkha>it's a question of bit rate and error rate <muurkha>by "page 32" you mean the page numbered 30, which is the 32nd of 152 pages? <oriansj>muurkha: yes, thank you for the correction <muurkha>I think the "floppy-ROM" must have been a record cut (or pressed) into a thin, flexible sheet of plastic; I forget what these were called <oriansj>also it appears the decoding into memory is done entirely in software; so in theory one could add error recovery and compression <muurkha>aha, "The flexi disc (also known as a phonosheet, Sonosheet or Soundsheet, a trademark) is a phonograph record made of a thin, flexible vinyl sheet with a molded-in spiral stylus groove, and is designed to be playable on a normal phonograph turntable" <muurkha>though as the schematic on that page shows, the signal was sort of demodulated before the software saw it <muurkha>it's kind of a shame; a stereo vinyl record has easily 400 kilobits per second of channel capacity, and with the right kind of modulation you could use *all* of that <muurkha>46 minutes at 400 kilobits per second is 140 megabytes <oriansj>which is most of the first stages of live-bootstrap <oriansj>although the demodulation circuit would certainly be a good deal more complex <oriansj>or it would be a good bit much more complex in software <muurkha>maybe somewhat more complex in software, yes <oriansj>otherwise turbo loaders would have achieved that <muurkha>oh, well, you couldn't increase the decoding baud rate very much on machines of the time <muurkha>but you could record many channels in the same signal, and demodulate only one of them at a time, under software control <muurkha>in an AM crystal radio, the signal in from the antenna contains all the radio stations at once, but a detector consisting of a capacitor, a variable inductor, and a diode is sufficient to select a single one of those stations and decode it into an audio signal <muurkha>for software control it is probably convenient to substitute a PLL for the capacitor and inductor, but that's potentially comparable in complexity to the circuit shown <oriansj>well I am thinking more in terms of simple to make for a bootstrapping computer with as little software as possible (and thus willing to waste a good bit of potential storage) <oriansj>as I am thinking even floppy disk drives would need ROM programming before they can be properly bootstrapped. <oriansj>for example the commadore floppy disk drives used a 6502, 8KB of ROM and KB of RAM <oriansj>well kinda but not exactly; as the Apple 2 used the computer's CPU and RAM to tell the floppy disk drive where to position the head, how to spin the disk and handling all of the encoding/decoding of the tracks and sectors <muurkha>most floppy disk drives of the 01970s were simpler than that, and the Apple ]['s drive was famously simple <muurkha>it did a lot of the encoding/decoding in an EPROM-driven finite-state machine on the drive; that was the great simplification <muurkha>but yeah, having the CPU telling the floppy drive where to position the head was how floppy disk drives work even today, and how hard disks worked throughout the MFM/RLL era and well into IDE <muurkha>it didn't do the PRML stuff modern hard disks do obviously <oriansj>or rather clever things like Logical block addressing; <muurkha>right, LBA was when the CPU stopped telling drives where to position their heads <muurkha>(though servo tracks and servo heads in hard disks predate LBA, and drove an internal feedback loop in the drive the CPU isn't involved in) <oriansj>plus by having a separate CPU, you can transparently do things like block retry, block remapping and block error correction. <oriansj>and your interface becomes load(block, memory_address) and store(block, memory_address) and all of the complexity of storage is hidden in the devices themselves. <muurkha>you can do that with subroutines on the same CPU too though <muurkha>except that there are some niggling issues left over with timing and latency <oriansj>with a good bit more complexity required for the software. <muurkha>I don't know that moving the software all onto one CPU makes it more complex <muurkha>occasionally that happens because of timing constraints, but usually the effect is the opposite <pder>stikonas: with latest code in live-bootstrap I am getting a checksum error with binutils-2.38_0.tar.bz2. My checksum is actually the checksum before you changed it starting with aa910ea75. Is there anything I can provide to help debug? <pder>Same error twice in a row running in qemu mode <stikonas[m]>Tomorrow i might update first binutils to 2.30, so maybe we csn compare then? <pder>ok, in the meantime, I'll try a few more runs to see if the checksum ever changes <lain_>Had an idea, was wondering if anyone here knew if it's viable: could guix itself be thought of as a compiler of sorts insofar as diverse double compiling is concerned? The inputs would be everything needed to bootstrap guix, as well as all source code for programs required, and the outputs would be guix itself. This could be compared against almost any system capable of creating the same environment guix creates I think. <lain_>I guess more broadly, my question is whether diverse double compiling can be used to test the environment too instead of just the compiler <oriansj>lain_: well DDC by definition only applies to compilers but reproducible builds is certainly something which is more in line of what you are describing. <lain_>oriansj one of the assumptions of DDC is the integrity of the build environment, so if you use the same trusted compiler in 2 different build environments and the results differ, you should be able to conclude that at least one build environment is untrustworthy, no? <oriansj>lain_: well yes that is one of the assumptions in the formal proof but it doesn't go backwards. Just because 2 different build environments produce the exact same compiler, doesn't mean both are trustworthy. <lain_>the compiler exists within the build environment <lain_>or uses the build environment <lain_>if the compiler is trusted and one environment is trusted, I believe a different result from a different environment and same compiler would indicate the environment was untrustworthy 