IRC channel logs
2023-07-20.log
back to list of logs
<kerravon>hi guys - some time ago we discussed CDs and briefly touched on paper tape <kerravon>it has just come to my attention that IBM mainframes in the 1960s also supported paper tape - not just cards <kerravon>i don't think it was very common, but did exist <kerravon>so - i have a mainframe OS (z/PDOS), which is also capable of running on S/370 <kerravon>and i have ported a flavor of "Sector C" to that <kerravon>and i'm just trying to clarify an end goal <kerravon>i believe what i want is a paper tape containing some bootstrap programs including the Sector C variant, plus source code, plus compiled executables <kerravon>and the idea would be to manually inspect the initial essential binaries in machine code (i haven't yet determined what that would be) <stikonas>nektro: lua tarball just seems to be autotools <kerravon>and then you IPL (boot) from punched tape (we believe that is possible - there is no technical reason why it shouldn't be) <kerravon>and then I assume there needs to be an option from the user - this option could be given by a separate device (card reader) or terminal or maybe a bit of preceding paper tape <kerravon>and the first option that should be chosen is to "print source", so the bootstrap program jumps to each pre-calculated offset on the paper tape and prints the source code <kerravon>so this then needs to be read to confirm it is as expected <kerravon>and then you IPL again and choose the option to build - so all the source code gets compiled, and byte-verified against the executables already on the tape - and it should match <kerravon>and either before, during or after, the contents of the paper tape are put onto a disk so that you can IPL from that instead <kerravon>there are no device drivers involved here - IBM mainframe peripherals are "intelligent" - although i'm not sure how much intelligence there was in a punch tape reader from the 1960s <kerravon>so i'm thinking this is a good starting point to "rebuild the world securely" <kerravon>it shouldn't be a problem emulating any of this <kerravon>not sure how feasible it is to reproduce the hardware of the 1960s <kerravon>does that process sound correct though - first pass is to just print the source code on the paper tape? <kerravon>i've never used paper tape, but i am disappointed that options have to come from another device or stuff around with another piece of paper <kerravon>maybe it could be time-based instead? if you IPL in the first half an hour of an hour, it does the print option <kerravon>and there's no typing involved in any of this <kerravon>i guess if the printer device number is being hardcoded, you may as well hardcode the device number of a card reader <kerravon>the card reader, card punch and printer are at well-defined device numbers anyway (00c, 00d, 00e) <kerravon>2. is it possible to build a paper tape reader today? they've had them for centuries <kerravon>oh - also, is it possible to make "paper" tape out of something more durable - the plastic that was mentioned earlier as being possibly suitable for cards <oriansj>kerravon: well it would be more secure if the process that builds the source code just includes an echo in the reader function (so that everything the reader sees is written to output for audit and review) thus making it impossible for the build process to see anything that isn't also output. <stikonas>oriansj: any chance you would have riscv64 version of hex2 (from mescc-tools not assembly version) <stikonas>I'm trying to investigate why qemu upgrade broke stage0-posix-riscv64... <stikonas>and I have a theory but it's not confirmed yet <stikonas>it might be due to us not allocating memory... <vagrantc>muurkha: i haven't dug up the old references to the reproducible toolchains from the 90s ... it was never much detail, but at least find the names <stikonas>(possibly brk location changed and there isn't enough space for unallocated storage that we might have used <stikonas>hmm, actually somehow scratch is located in the middle of brk section... <stikonas>just skip some memory after brk allocation <stikonas>and not sure if further programs will also need this <stikonas>well, I have a workaround for hex2 now, but M0 probably has a similar problem <kerravon>oriansj - surely a copy of the card deck is entirely useless? you already have that <kerravon>it's the source code that needs to be printed out for review <muurkha>vagrantc: I talked to a couple of Cygnus people from the 90s, but they couldn't remember the GNU toolchain being reproducible in that way <stikonas[m]>well, even if they couldn't remember GNU toolchain being reproducible, it might have been <stikonas[m]>at least 10 years later GNU software was mostly reproducible <oriansj>stikonas: yes one built by gcc and another built by M2-Planet. Could it be classified as a Qemu bug? as the code did work on a real machine (if I remember correctly) <stikonas>I'll have to apply something similar to M1 <oriansj>yeah, that would have a .data segment by default which would use up that block <oriansj>brk 0 is supposed to return the address of the first free address for a malloc/calloc; which seems very odd behavior in qemu if it is a gas .data block sized offset wrong. <stikonas>anyway, I think it might be a blocker for next stage0-posix release <sam_>i think this is fixed already <sam_>i remember at least one brk fix, and another important mmap one <sam_>or is this not linux-user? <stikonas>I probably don't have this commit in qemu stable on gentoo <sam_>I kicked off bug 909541 earlier which will include this fix too, IIRC <stikonas>will save us quite a lot of hassle of workarounding it <sam_>ah, I remember some of this now! <muurkha>vagrantc: yes, I thought that was amusing, though maybe I shouldn't <muurkha>I mean obviously working together with John is important, and he has a demonstrated capacity to work together with people <vagrantc>i have not always found that to be true, but have not crossed paths too much <stikonas>well, but in any case they did not do bootstrappable builds in cygnus even if there is some debate about reproducible builds <muurkha>what I mean is that he built Sun, Cygnus, and the EFF, and if working with him were impossible all three would have failed <muurkha>but not at the level of Stallman, say <muurkha>also I don't mean working with him is *necessary* <muurkha>just that it's a big advantage if it can happen <muurkha>to clarify, a couple of lines above should have read "not that he's *easy* to work with"