IRC channel logs
2023-05-10.log
back to list of logs
<janneke>emilytrau[m]: what kernels does nixos support?a <janneke>fwiw, mes should run on the hurd too and there was a preliminary initial contribution for freebsd, but that's about it for now <emilytrau[m]>NixOS is built on linux+systemd, but nix and the nixpkgs package set support linux, macos, some BSDs, and many other platforms <emilytrau[m]>I've got a pull request open to even support SerenityOS in nixpkgs :D <emilytrau[m]>There isn't a hurd platform (yet) but that could be an interesting project. Although I'd guess maybe hurd users would already be using guix? <efraim>(when it gets started, another build process grabbed that machine it looks like) <janneke>ACTION is meanwhile building substitutes using qemu <efraim>ok I finished the other build and now it's starting <janneke>ah, and with the m2-planet from git, mes-m2 runs \o/ <stikonas_>as !0x1 will not generate 01 with hex2 on riscv64 <stikonas>so machine code generated by mescc is somewhat wrong <stikonas>(more precisely by the combination of messcc and hex2) <stikonas>so I expect final mes binary will segfault <janneke>stikonas: what about using --architecture amd64 for M1 on riscv, would that help? <janneke>it's great to know mes builds until here, at least <stikonas>I want to fix it properly but it will take a bit of time... <janneke>iwbn to have something running, adapting mescc to the new M1 riscv immediates shouldn't be too hard? <stikonas>janneke: it's not too hard but it's not completely trivial either <stikonas>part of it is my unfamiliarity with mescc <stikonas>so I need to exactly understand what code we need to emit... <janneke>yeah, so i was hoping that using M1 in x86_64 mode would produce working code; then it would be easier to extrapolate from there <efraim>about 3 hours in on building mes and still going ... <janneke>efraim: it looks *much* (maybe an order?) slower than qemu on x86_64 <efraim>the truth is it doesn't get built that much, so it probably isn't that big of a problem <efraim>ah, yeah. that's why I deleted the wip-riscv branch, it was where I was staging patches when working on riscv64 support in guix <[exa]>rv64 doesn't have any instruction/ramops decoding acceleration in qemu yet, right? <ericson2314>emilytrau: did you see my comment on trying to use multiple derivations for parallelism? <Irvise_>One quick question. Has someone bootstrapped Erlang? <Irvise_>Afaik, it uses precompiled binaries that it runs on the C based VM (which is compiled as a first step). From what I saw in Guix, it seems that it is not bootrapped, but maybe I am not understanding things right. <Irvise_>To me it seems they are doing the same approach as the one in Zig. Or maybe I should say that Zig is following Erlang's approach. <Mikaku>rickmasters: just let me know if you want to submit some PRs, in order to avoid keeping a separated fork of Fiwix for live-bootstrap <rickmasters>Mikaku: yes, I'll try to submit some soon. I've put that off too long. <rickmasters>stikonas: i don't mind moving builder-hex0-x86-stage1.bin there. hopefully it would clear the reuse license lint error? <stikonas>we do have a mechanism of specifying license in a detached way <stikonas>but if we move then we don't need to worry about it <mihi>emilytrau[m], in my opinion anyone who is interested in using the Hurd would probably use Debian Hurd. I evaluated Arch Hurd some time ago and the only way to actually use it is in a chroot inside Debian Hurd. I spent a few (too many) hours trying to get the startup and Shepherd scripts to boot my machine (VM) without manual intervention, and eventually gave up (probably due to lack of Shepherd <mihi>knowledge). OTOH, Guix Hurd when I last evaluated it booted fine without issues (after adding some swap partition), but soon applications broke/segfaulted, including the build of gdb. So I decided to keep both parts :P <mihi>My Debian Hurd VM is running here since at least 2016 and I boot it up every few weeks to either test something or install updates and see it getting better <FireFly>or maybe guix with hurd? if that's a thing, IIRC it was at least originally meant to be a thing <janneke>mihi: yeah, it's not really feasible to build a new hurd outside of the debian build system, there are some problems wrt sharing their patches <janneke>i'm hoping this will get better once development is less in flux <qyliss>emilytrau[m]: HURD in Nixpkgs is on my long term todo list <qyliss>(if nobody gets there first, of course) <civodul>janneke: we do build a full GNU/Hurd in Guix though :-) <qyliss>I was thinking it would be cool to document it and use it as a way to make a tutorial on how to add a new platform <civodul>the situation re patches has vastly improved over the last couple of years <janneke>civodul: yeah, but our sources are ~2y old? <civodul>we've just updated them, so they're like 2m old now! <civodul>it wasn't easy though, because of the lack of releases upstream... <janneke>yeah, i thought there was this netbsd/rumpkernel/quilt patch problem <civodul>dunno, maybe we're just not building that part? <janneke>and ask for at least a synced git archive once or twice a year <mihi>(and yes that is ~2y old, and I believe there were some changes in how translators are stored in the filesystem now. But last time I needed it, it worked well enough) <mihi>I believe the most annoying bug in Hurd is cache invalidation when unmounting a loopback device. It used to be aptitude randomly deadlocking, but that deadlock was fixed somewhen last year by one of the security patches (which could not get merged upstream for some time due to missing FSF legal paperwork) <sam_>at some point I'll port gentoo to hurd again <mihi>sam_, qyliss, when the resulting system boots, I will probably test it :D <drakonis>i'm learning some assembly to bootstrap a forth, might be fun <drakonis>these feel like a turing tarpit for this <fitzsim>they'd need memory peek/poke extensions, at least <theruran>fitzsim: I think oriansj has got some opinions about SectorLISP but also it is missing some important things for bootstrapping. I can't remember exactly <drakonis>it requires too much energy to do anything basic <drakonis>sectorforth, otoh seems usable due to not being a turing tarpit <theruran>drakonis: have you looked at seedForth? I think the main contribution is pulling together the Forth words for a 'standard' Forth. would be nice to build from that <theruran>it is currently bootstrapped from gforth though <drakonis>i have just found out about seed and pre forth while looking at the wiki <muurkha>very few programs I've read from beginning to end <drakonis>i'm familiar with jonesforth but i'm not quite ready for it <drakonis>working on improving my assembly knowledge first <drakonis>other assembly forths i know of is yourforth from the author of ciforth, which jonesforth is based on, uses fasm, and nasmjf, a port of jonesforth to nasm <oriansj>janneke: risc-v is a word based architecture, so you are unlikely to have much luck trying to leverage the amd64 M1 behavior as the immediates are encoded in a very ugly manner. <oriansj>fitzsim: sectorlisp lacks the abilties one needs to write any data to disk, make bios calls or read any data from disk. So the only way to use sectorlisp for bootstrapping involves doing a buffer overflow attack and a few nasty things. <fitzsim>I was thinking more like "sectorlisp+bootstrapping primitives" <oriansj>sectorFORTH however, is usable for bootstrapping if you can write 600bytes without error <fitzsim>but I don't know what that'd look like or how big it would become <oriansj>oh, you could get the bootstrapping primitives in 3 bios calls or about 120bytes <janneke>oriansj: so what you're saying is that the current mescc implementation/usage of immediates for risc-v never worked at all? <drakonis>stoneforthknife's author mentions the hidden complexity of metacircularity <oriansj>well the previous RISC-V behavior of M1 fudged the data to kinda get it to work but it easly hit bugs on any immediates greater than 5bits <muurkha>oriansj: I'd say that RISC-V is a byte-oriented architecture <muurkha>but it's certainly true RISC-V immediate encoding is ugly <oriansj>muurkha: I'll give you half-word oriented for the 16bit packets <muurkha>oriansj: but if you increment an address and fetch from it, you get the data 8 bits later in memory, not 16, 32, or 64 <muurkha>word-oriented architectures are things like MIX or the PDP-10 or PDP-8 <muurkha>where memory is 12 or 32 or 36 bits wide, not a byte wide <oriansj>muurkha: oh, I see what you mean. I was referring to the decoding of the instruction as only being clear when you look at the whole word <muurkha>yes, the instruction encoding is based on 16-bit parcels <oriansj>and that was the nature I was referring to <oriansj>the, you need to real the whole instruction as the immediate might be scattered across the whole word <oriansj>vs x86 and knight which the immediate is just a single block which M1 previously could just dump with @5 <oriansj>and why for a very long time I thought M1 might never support RISC-V <oriansj>but I must say, stikonas and others really helped to make the impossible possible. <drakonis>a question, how hard is it to make a bootstrap chain using a self hosting assembler written entirely in assembly? <janneke>"<oriansj> but I must say, stikonas and others really helped to make the <muurkha>drakonis: Don Knuth claims that for a reasonable machine you can do it in an afternoon <muurkha>but I think that might be because he's a better programmer than I am