IRC channel logs

<stikonas[m]>mihi: no,not regenerated because we don't use autotools then

<stikonas[m]>Or are these some other files...

<stikonas[m]>I have a very bad connection right now, so hard to check...

<stikonas[m]>mihi: yeah, i think we should rebuild them...

<stikonas[m]>Can you open bug report?

<stikonas[m]>mihi: regarding split kaem files, I think that's fine, at least with make and tcc. Split mes is fine too but consider spending building part to mes upstream

<stikonas[m]>At least if janneke agrees

<stikonas[m]>Right now I think gash has no plans to support mes-m2, so mes-m2 -> mes kaem script might be useful

<pabs3>unmatched-paren: language ecosystem package managers have value to distro packagers btw; they increase the possibility of being able to automatically convert the upstream software into a distro package

<pabs3>Debian takes advantage of that a *lot* https://wiki.debian.org/AutomaticPackagingTools

<pabs3>I've learnt over time that no technology choice is solely good/bad, there are always both good and bad things about individual tech things

<janneke>stikonas[m]: samplet is working to port gash and gash utils to mes, but that will probably take some time

<unmatched-paren>pabs3: sure, but you could also just have some sort of package database that can also do that, without a package manager that just begs to be misused

<unmatched-paren>crates.io could exist without cargo

<unmatched-paren>and distros could use it to automate packaging

<unmatched-paren>it could even be a standard protocol to describe packages and builds! go, rust, ocaml, etc could all be imported via the same method!

<oriansj>unmatched-paren: the problem is people want their own problems solved, even if means making problems for others. So unless you already have a tool that solves their problem *now*, people really don't value promises from those they don't know or trust.

<oriansj>pabs3: there are some technology choices that are toxic long term, such explicitly making it hard for new people to learn and leveraging *magic* you can't reason about.

<oriansj>and I'm still hammering on the GFK filesystem spec to make sure I didn't make anything overly complicated.

<oriansj>now the smallest GFK filesystem is 3 sectors (2: 1536

<oriansj>The leadblock, the superblock and a single ROOT inode

<oriansj>^(2: 1536^(512=>1536, 4096=>12288)^

<oriansj>and if I stick to a 512byte block size and a 32bit block pointer, we should be able to support a 2TB partition (which would be more than enough to bootstrap Linux)

<oriansj>as we need 68MB for all source, binaries and artifacts in stage0-posix

<oriansj>(and 25.3MB of git history)

<rkeene>Hey oriansj, do you mind if I send you a message about something only tangentially related ?

<oriansj>rkeene: why would I mind? go for it

<rkeene>Some people don't like it

<oriansj>fair but I like getting alternate perspectives

<rkeene>I would say this is more like a proposition than a perspective :-D

<rickmasters>oriansj: is that 68MB the result of an x86 build?

<oriansj>rickmasters: 25.3

<oriansj>rickmasters: without the build and artifacts it is: 36M of source and .git history

<oriansj>^25.3^25.3MB of that is the .git history)

<rickmasters>oriansj: maybe something is different for me, after make test-x86 I get 38M from du -h .

<rickmasters>oriansj: and 14M for du -h .git

<oriansj>I guess my .git history is a bit more complicated than what everyone else got

<rickmasters>ok

<oriansj>after build x86 is 17M for me

<oriansj>and should be the same for you

<rickmasters>oriansj: yes, 17M

<oriansj>interesting looks like git clean -xdf isn't cleaning up artifacts properly, I probably should fix that

<stikonas[m]>janneke: yes, but my point was that it will be full mes and not the one compiled with M2

<mihi>stikonas[m], https://github.com/fosslinux/live-bootstrap/issues/176

<oriansj> and I'm updating stage0-posix and should have the commit up in about 20-30 minutes

IRC channel logs

2022-05-28.log