IRC channel logs

2022-04-23.log

back to list of logs

<pabs3>"Ribbit Scheme bootstraps with Posix shell while supporting TCO, call/cc and GC" https://github.com/udem-dlteam/ribbit/commit/14077d111425c8472dd5a0e865462dea70a8d206 https://news.ycombinator.com/item?id=31096771
<muurkha>cool!
<nimaje>that ribbit scheme thing reads to me like the added a posix shell backend to their scheme compiler written in scheme, I don't really see where the bootstrapping is (ok, you could compile the compiler to sh and than run it on some system where you have some sh, but probably you can run some binary there, so you could compile to a native binary for that system too)
<nimaje>ah, (githubs ui is stupid), so they have a virtual machine for their byte code written in sh (not sure if that is handwritten or generated), but seems like there is no compiler in sh
<unmatched-paren>pabs3: "Microsoft is big on supply chain security these days" <- i suppose they're only big on supply chain security for *themselves*, otherwise they'd release the source code of every program they'd ever made... if my assumption is correct, Microsoft already has a secure path to dotnet-core, through the old dotnet. obviously since it's their program they can audit it as much as they want.
<unmatched-paren>of course, this doesn't give anyone else a secure path...
<unmatched-paren>Maybe my assumption that they consider only their security to be important is incorrect, but it's Microsoft we're talking about here.
<oriansj>unmatched-paren: well bootstrappable chains contain a cost (of developer time and effort) with a benefit few in the market actually value; so companies have a large incentive to ignore it until some external event forces it as an issue.
<littlebobeep>oriansj: Why is it not valued? :/
<bauen1>littlebobeep: comapnies (or groups in general) might be okay with a less extreme version, i.e. a bigger seed, there's always the licensing trade offs
<stikonas[m]>Companies would already be quite happy if their builds are reproducible, they don't try to bootstrap builds
<littlebobeep>bauen1: How is a bigger seed = a less extreme version?
<littlebobeep>Also what does licensing have to do with it?
<oriansj>littlebobeep: well if you start with all of your dependencies as binaries, the bootstrapping path by definition is just a single step (just do the build)
<oriansj>and that is what everyone was already doing.
<bauen1>^ now, there might have been (or still is) a path from another language, but if you're developing a language there's a good chance this path may be abandoned / fall behind once you become self hosting
<oriansj>So the shrinking of your bootstrap binaries is an extreme extension by common definitions
<oriansj>and the most extreme version is ZERO bootstrap binaries
<bauen1>there's also some difference between aiming for libre-licensed bootstrap from source only, or aiming for an auditable bootstrap (i.e. source-available)
<bauen1>if you just want to exclude the possibility of a backdoor, then the source-available and auditable bootstrap way is good enough (i think)
<oriansj>bauen1: well public audits generally allows anyone to gain prestige by finding anything in your bootstrap which tend to be be a stronger trust model than trusting a handful of individuals not to be bribed or lazy
<oriansj>for example: I was mistaken at first glance at Guile's Psyntax but the public process quickly revealed my mistake and now Guile is properly bootstrapped.
<markjenkinssksp>oh, very nice to hear about the Guile bootstrap and pysyntax, I missed the mailing list post https://www.freelists.org/post/bootstrappable/stage0posix-release and haven't read the chat much in awhile
<markjenkinssksp>I was aware of https://github.com/schierlm/guile-psyntax-bootstrapping , but I wasn't sure if it was complete in terms of what it needed to do for guile or the state of the scheme running it
<markjenkinssksp>I suppose the relevant scheme is the port of Mes to M2-Planet?
<stikonas>markjenkinssksp: we actually built guile in live-bootstrap too using guile-psyntax-bootsrapping
<stikonas> https://github.com/fosslinux/live-bootstrap/blob/master/sysc/guile-3.0.7/guile-3.0.7.sh
<stikonas>as for mes, I don't think ti's relevant for mes
<muurkha>oriansj: what were you mistaken about with respect to psyntax? I think you were right that it was built with itself and that fixing that was a significant obstacle
<markjenkinssksp>ahh, stikonas, I think guile-3.0.7.sh from fosslinux/live-bootstrap reminds me where I've got things wrong
<markjenkinssksp>Schierl's work included patches to guile and so all of the scheme code in guile-psyntax-bootstrapping is run by a patched guile, possible because Schierl used scheme features available by just compiling the C parts of guile
<markjenkinssksp>and so the involvement of mes and mescc in terms of bootstrapping guile is just bootstrapping the C compiler, not running any scheme code more directly related to the guile psyntax bootstrap
<stikonas>indeed, mes is only used to run mescc and nothing else
<stikonas>it would be nice to eventually be able to run gash but that's not possible right now
<stikonas>being able to run gash would solve some licensing issues
<markjenkinssksp>I think I used to be aware of this stuff about guile-psyntax-bootstrapping and forgot, at one point I was doing something experimental, incomplete and unpublished with the Schierl code
<markjenkinssksp>re gash, is there currently a loop of gash required to bootstrap guile but guile is required to run gash..
<markjenkinssksp>reading https://savannah.nongnu.org/projects/gash/ I see it is used to bootstrap bash, so revising my loop, building guile needs bash, bash needs gash, gash needs guile...
<stikonas>markjenkinssksp: gash is not required to bootstrap guile
<stikonas>bash can be built without gash at all
<stikonas>the problem is not building stuff
<stikonas>but we do have a licensing problem
<stikonas>mes C library is GPLv3
<stikonas>and in order to build bash without any pregenerated files you need to rebuild parse.y, yacc from heirloom-devtools can be used
<stikonas>but that is under CDDL license
<stikonas>so the final binary is GPLv3 + CDDL which is not redistributable
<stikonas>if you don't care about parse.y and happy to use pre-built parse.c then there is not issue and gash is not needed
<stikonas>markjenkinssksp: in live-bootstrap we build bash using handwritten kaem and makefile scripts
<markjenkinssksp>I see, though I'm a bit confused by the concept of final binary in a bootstrapping context, seems to me that we're talking about binaries created in the middle of the bootstrapping process that are tossed at the end and not really distributed the way bison binaries, glibc binaries end up being
<stikonas>yes, they are tossed away
<stikonas>hence it's not a big deal
<muurkha>stikonas: does the CDDL really apply to the yacc *output*?
<stikonas>muurkha: no, but yacc itself is licensed under CDDL
<stikonas>and C library is licensed under GPLv3
<muurkha>oh I see
<stikonas>with gash there is a workaround
<muurkha>the final binary of yacc, not the final binary of gash including the yacc-generated parser
<stikonas>postpone building of yacc until after musl
<stikonas>it's actually the first binary of yacc that has this issue
<stikonas>after that we build flex and previous yacc is completely removed from live-bootstrap
<stikonas>so in live-bootstrap that's not a big deal
<muurkha>right
<stikonas>but e.g. if Guix would try to do strict no-pregen bootstrap like live-bootstrap does, that would be a problem
<stikonas>because intermediate steps would end up in /gnu/store
<stikonas>and potentially in binary builders
<markjenkinssksp>I don't think I violate any license if I start with a bunch of source, produce a yacc binary for my private use, and then use yacc in a bootstrap that ends up with me publishing other binaries
<stikonas>yes, for private use combining GPLv3 and CDDL is legal
<stikonas>since GPLv3 doesn't really kick in until you start redistributing stuff
<markjenkinssksp>I guess complication one is that there's a desire to publish all intermediate binaries as a kind of cache in a GUIX context
<oriansj>muurkha: my earlier mistake with guile's psyntax was mistaking believing that it was human written rather than generated and need to be properly bootstrapped. I was quickly corrected of that mistake if you look early in that history
<markjenkinssksp>reproducibility kind of demands that people be able to publish binaries they relied on so we can see that multiple people got the same binary
<stikonas>markjenkinssksp: publishing binaries is not necessary for reproducibility
<stikonas>you can publish hashes
<oriansj>markjenkinssksp: yeah, it is a minor problem involving distribution (solved by either a licence change or a replacement library used)
<stikonas>that's what live-bootstrap does
<stikonas>and using replacement library would be almost trivial if we get gash on mes
<stikonas>hence we are not pursuing license change
<oriansj>(or possibly a better scheme that M2-Planet can build which is able to run MesCC+Gash)
<stikonas>not necesserily M2-Planet
<stikonas>if tcc could build it, that would be fine too
<markjenkinssksp>thanks for the catch-up folks
<stikonas>markjenkinssksp: this is the list of what live-bootstrap builds https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst to avoid any pre-generated files
<oriansj>(personally I am hoping siraben's scheme written the Haskell subset supported by blynn-compiler [which was bootstrappable from M2-Planet+M2libc])
<oriansj>then the root bootstrapping langauges become: assembly, C, Scheme and Haskell
<stikonas>siraben was busy recently... not much changed in blynn-compiler
<oriansj>stikonas: it happens
<stikonas>although scheme and haskell are fairly slow...
<samplet>Oh hey everyone! I’m porting Gash to Mes as we speak. :)
<stikonas>samplet: oh hi!
<oriansj>samplet: nice!
<markjenkinssksp>I was just looking at https://git.savannah.nongnu.org/cgit/gash.git/commit/?h=wip-mes samplet, but clearly I'm looking in the wrong place
<stikonas>yeah, I saw that branch too but it wasn't updated recently
<stikonas>I guess samplet has more stuff locally
<samplet>Right now I’m trying to get the Mes module system working: https://git.ngyro.com/mes/log/?h=wip-guile-module
<samplet>The current plan is to get Guile 1.8 modules working on Mes, and then port Gash.
<samplet>However, I’m having trouble with Mes so far.
<stikonas>have you talked to janneke?
<samplet>Yeah. It was his idea to start with modules. It’s a good idea, but it’s proving very difficult.
<samplet>The way Mes thinks about variables and bindings, etc. is rather different than Guile.
<samplet>We’ll see. I might have to bail on modules and rig up Gash the same way as MesCC: load everything into a global namespace and be very careful with names.
<samplet>:/
<muurkha>oriansj: oh, I see