IRC channel logs

<stikonas>fossy: https://github.com/fosslinux/live-bootstrap/pull/275 now needs a rebase

<oriansj>stikonas: merged

<oriansj>nektro: or perhaps have a book published on low-acid paper and stored in an air tight container with detailed instructions of how to make a reader and information required to allow someone in the future to decode the contents as well. (Ideally there are checksums and other bits which allow sanity checking during development)

<nektro>yeah books in humidity-stable environments do surprisingly well

<stikonas[m]>Well, museums and libraries have books that are hundreds of years old or so...

<nektro>i thought https://www.microsoft.com/en-us/research/project/project-silica/ was cool but this one gets into the need for pretty advanced readers/writers

<oriansj>and information about how to build them is completely secret

<oriansj>heck, is there even a single drive that isn't a RAM, papertape disk or SSD that actually has an open hardware design out there?

<muurkha>oriansj: there are probably lots of patents from the 01970s that include fully open hard disk designs

<muurkha>maybe the 80s too

<muurkha>16:43 <@oriansj> which tells us very directly, anything without humans caring enough to keep something working; will die with little to no

<muurkha> nope of recovery.

<muurkha>I don't agree with this

<muurkha>Sumerian cuneiform had nobody caring enough to keep it working from the 2nd century AD until 01836

<nektro>languages are super fragile and absolutely have to be cared for

<nektro>see https://www.nytimes.com/2023/04/09/us/new-mexico-spanish.html for even a recent example

<muurkha>it survived about 17 centuries of total disuse, but was recovered. given the volume of the corpus, the relative simplicity of the format, and the stability of the physical medium, its recovery was inevitable once science arose

<nektro>"given the volume of the corpus," thats people caring about it

<muurkha>no, nobody cared about it during those 17 centuries

<muurkha>at least not very much

<muurkha>Egyptian hieroglyphics and Linear B have similar stories: the hieroglyphics were lost for a somewhat shorter time, while Linear B was lost from about 01200 BCE until, say, 01951

<muurkha>it's true that during the Bronze Age people did care a lot about cuneiform, but not enough to keep it working. it stopped working entirely 1800 years ago

<stikonas>but Linear A was lost and not recovered

<muurkha>yes

<muurkha>and Sumerian is mostly only recovered because it remained the language of diplomacy for a long time

<muurkha>so there are surviving textbooks in Akkadian about how to learn Sumerian

<vagrantc>ACTION ♥ #bootstrappable

<muurkha>also science and liturgy, sort of similar to Latin in Europe in the period 00400 CE to 01800 CE and to some extent even today

<muurkha>Akkadian is a Semitic language like Hebrew and Arabic, so it was relatively easy to decipher (and Linear B is Greek, while Linear A is likely some unknown language family, similar to Sumerian but with a much smaller corpus)

<oriansj>muurkha: a corpus either means multiple people cared enough to keep something around that they couldn't read and opted not to use it to address their short term needs or that it was lost into the ground or sea until one day it was discovered by someone who would care for it.

<oriansj>and I'll certainly grant the idea of a spinning magnetic disk and some ideas about how to control a magnetic head might exist in patents. But I fully doubt anyone would put a guide to build a hard drive from commonly available parts in any patent.

<muurkha>oriansj: as I understand it, it was mostly the second case; the preserved cuneiform tablets were recovered from archaeological digs, where they had been underground for thousands of years

<muurkha>I agree that they aren't talking about commonly available parts, but they'll talk about how to make them out of parts that could be made with 50-year-old technology

<muurkha>a lot of the preserved cuneiform tablets were actually accidentally preserved: the usual way to use them was to re-wet unwanted clay tablets to turn them into fresh clay tablets

<muurkha>unbaked clay is not great at surviving underground

<muurkha>but when there was a fire, as when a city was burned by an invading army, often that would fire the tablets into a more durable form

<sam_>hhvcvgdtjgnrhgjtvnjtitcbievfrkf

<sam_>oops

<muurkha>sam_: I have days like that

<nektro>i see someone else has a yubikey

<nektro>nice

<nektro>well i dont anymore, my old work laptops had them

<fossy>stikonas[m]: ack re the rebase, i'm doing that now

<j-k-web>Hello. the readme mentions a "Phase 23: build chmod" but I see no such thing scanning through the `x86/mescc-tools-*-kaem.kaem` or the rest of the repos. Is that something that was removed?

<oriansj>muurkha: only for patents that cover how to make the machine sort of deal or the realy old style of the patent that covers the machine that makes a hard to make thing. Once software showed up in patents; the amount of blackbox abstraction went to 11 and there are patents out there covering things that no one knows how to actually make.

<j-k-web>are the chmod and mkdir phases gone now? I need them quite early in my bootstrapping process

<oriansj>j-k-web: look in mescc-tools-extra if you need chmod and mkdir early in your bootstrapping process.

<oriansj>as it contains: CC chmod.c -o ${BINDIR}/chmod${EXE_SUFFIX} and CC mkdir.c -o ${BINDIR}/mkdir${EXE_SUFFIX} and is built with M2-Mesoplanet

<j-k-web>ahh I see. thanks. and would you say that building those are a better idea than trying to patch more builtins into kaem.c? I tried porting this to the latest stage0-posix but I've not got it to build happily yet: https://github.com/melg8/cit/blob/c66f8733f4a872d67cd60c50c0a23a5c8bc9de17/bootstrap_nix/bootstrap_seeds/kaem.c#L468-L506

<oriansj>well small tools are easier to reason about.

<oriansj>also what build errors are you seeing as kaem.c should build without any issue.

<j-k-web>I'll send the patch & the build error. is there a blessed paste site for the channel?

<oriansj>paste.debian.net is pretty common but there is no blessed paste site as no one here needs blessings to be awesome. Who does decides.

<j-k-web>(y) https://paste.debian.net/1277211/ error is `/build/kaem.M1:12816 :Received invalid other; LOAD_EFFECTIVE_ADDRESS_ebx` off /build/M1 --architecture x86 --little-endian -f /stage0-posix/M2libc/x86/x86_defs.M1 -f /stage0-posix/M2libc/x86/libc-full.M1 -f /build/kaem.M1 -f /build/kaem-footer.M1 -o /build/kaem.hex2

<j-k-web>seed & mini are unchanged apart from pointing to my kaem.c & outputting to /build instead of ./x86/artifact and ./x86/bin. I can run all the way through seed & mini with no issues if I leave the normal kaem.c

<oriansj>sounds like your M1 assembly definitions in the M2libc you are usings don't match the M1 assembly instructions you included.

<oriansj>also you don't need to define anything in assembly as all needed syscalls should already be included in M2libc

<j-k-web>ok awesome thanks for the all the pointers. I'll mess with it some more :)

<stikonas[m]>j-k-web: you need newer m2libc

<stikonas[m]>Have you updated submodules?

<oriansj>and if anything in stage0* isn't perfectly clear, feel free to ask ^_^

<stikonas[m]>LOAD_EFFECTIVE_ebx was renamed to lea_ebx,[rip+DWORD]

<stikonas[m]>Or something like that...

<j-k-web>yeah the assembly is from old stage0. I'm on rev "e8ffea3b2ab1cad652d37c0beafe93c8e75b6ddf". I found the part that looks like that so I'm hoping it will work fine with some slight tweaks

<j-k-web>I'm guessing you can't do `int mkdir() { ... mkdir() ... };` so I'll have to call it bmkdir or something

<oriansj>j-k-web: well M2-Planet/M2-Mesoplanet has a single namespace as a logical result of a 1:1 translation rule into assembly

<oriansj>and then how would M1 assembly be able to know which :foo function was intended.

<j-k-web>I totally forgot about the if else that goes through the tokens. I can can the function whatever but still check for "mkdir":D I realised that when I had a successful build but it still didn't know what `mkdir_` was

<j-k-web>Success :D - pretty-fied log https://paste.debian.net/1277219/

<oriansj>congrats

<j-k-web>Thanks. pretty much all I'm doing is gluing together the awesome work by yourselves & tweaking some of what melg8 did '=D

<j-k-web>nix drv for anyone interested https://paste.debian.net/1277220/ next step is probably to clean up this code & then maybe have this kaem do a fresh run through with itself instead of kaem-optional-seed https://paste.debian.net/1277220/

<rickmasters>I am starting work on the Fiwix to Linux kexec.

<rickmasters>The Fiwix hard drive work is in a good place now but I am going to set it aside to marinate.

<rickmasters>Mikaku: If you have any kexec code I can look at, even if it's not done, I think that would help me to get started.

<Mikaku>rickmasters: I was working on the kexec code before the issue #27 took over my time

<Mikaku>rickmasters: the implementation would be different than in Linux in the fact that it doesn't need any system call, instead you configure the kexec using the new kernel parameters: kexec_proto=, kexec_size= and kexec_cmdline=

<Mikaku>these parameters setup the current kernel to be able to kexec to a new one

<rickmasters>Mikaku: Is that a proof of concept then? While it would be helpful to me to see how that's implemented, I don't see the practical value otherwise.

<rickmasters>Mikaku: So it immediately restarts the same kernel or can it transition to a different kernel?

<rickmasters>Mikaku: What triggers the kexec?

<Mikaku>the trampoline code is finished and it works, before #27 I was about to touch mm/memory.c to reserve the memory space based on the kexec_size= parameter

<Mikaku>rickmasters: this kexec implementation works with the Fiwix kernel, you'll need to adapt it to boot a different kernel

<rickmasters>Mikaku: Right. I mean can it transition right now to a different Fiwix image or is it currently copying the currently running Fiwix code in memory?

<Mikaku>it can transition to a different Fiwix image, of course

<Mikaku>the idea is that you use the command 'cp' or 'dd' to copy the kernel you want to boot into a new device like a RAMdisk

<Mikaku>that's why the kexec_size= is needed for, it helps to reserve the memory space for the new kernel

<Mikaku>and you don't need any system call to kexec, just 'shutdown' the current system and it will switch to the kernel you copied into the RAMdisk

<rickmasters>Mikaku: I see.

<rickmasters>Mikaku: So when you're ready to share that please let me know. A different branch or a tar file is fine.

<rickmasters>Mikaku: I've got some cleanup work to do and I can always work on the hard drive stuff until you're ready.

<Mikaku>rickmasters: sure, let me finish the issue #27 and then we can open a new issue to track the kexec implementation

<rickmasters>Mikaku: Sounds good. I am curious about which patch fixes your hang from issue #27.

<Mikaku>rickmasters: me too :-)

<doras>fossy, stikonas: I'm working on a presentation for Linux App Summit 2023 about Freedesktop SDK's new bootstrap process. I will of course have a few slides about live-bootstrap and its center role in the design. I'd also like to mention you personally for your contributions/review on live-bootstrap's side. Would it be alright from your perspective?

<stikonas[m]>Fine from my side

<muurkha>oriansj: even today patents that don't describe software are usually pretty good about describing the actual invention in such a way that you could make it if you had the right liaab

<oriansj>muurkha: true, a good set of engineers can take incomplete information knowing something is possible and figure out a way to do it. But if one wants to increase the odds that someone in the future is able to create a device able to read data off some media, lowering the total engineering costs involved seems like a good idea.

<muurkha>yeah, I'm not suggesting that you should just print the patent out and put it on the box :)

<muurkha>"liaab" should be "lab"

<muurkha>I've been reading "How To Invent Everything", which is enjoyably written but extremely substandard in terms of actual information. it's largely a bunch of popular misconceptions stated with authority

<oriansj>well not surprising as it takes a lifetime to filter things through experience

<oriansj>in fact, I assume that all my assumptions of how hardware will be will change promptly after I am forced to make the hardware and detail with the bits required.

<oriansj>^hardware will^hardware should^

<muurkha>well, certainly you could spend a lifetime learning about any of many fields described in the book: selective breeding of corn, for example, or ferrous metallurgy

<muurkha>but that doesn't mean you couldn't do a better job

<oriansj>muurkha: as I have published a grand total of [checks notes] zero books; I have no proof that I could do a better book.

IRC channel logs

2023-04-13.log