IRC channel logs
2023-09-15.log
back to list of logs
<xelxebar>Oh nice. I'd love to have you show off hurding to me. Wish there were hurders around where I live. <gnucode>xelxebar: I basically just walked through the translator primer <gnucode>I guess I should probably start taking my linux laptop with me. that way when hurd's X get locked up again...I can try ssh-ing into it. <zamfofex>gnucode, GNUmoon and gnu_srs1 are the same people, and you can’t convince me otherwise. 😅 <damo22>zamfofex: i know one of them personally, the other two i have had separate conversations with <zamfofex>I acknowledge, I’m just trying to be a bit snarky, is all. <xelxebar>damo22: But have you had *simultaneous* conversations with them?? Your paranoia level is way too low. /s <damo22>i used to have problems with that, not anymore <gnu_srs1>(15:19:38) gnu_srs1: damo22: No I did not: Somebody probably broke in to that image and installed Windows? Or broke in to the host box?? But the linux host process running the image was the same. <gnu_srs1>hurd-2013.img: DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,2), end-CHS (0xa1,254,63), startsector 1, 4294967295 sectors, extended partition table (last) <mbakke>the images are generated "on the fly" and can be connected to other guix branches for development <mbakke>janneke: btw "guix" fails to build on the hurd-team branch! <janneke>ACTION _just_ built a fresh image for the hurd from hurd-team (plus some other patches) <mbakke>janneke: /gnu/store/y66lhm1in110b1rz5s5i8xsm7d250fxl-guix-1.4.0-12.f8ecf2b.drv :P <mbakke>I just tried building the same hurd-qcow2 image from that branch <mbakke>the "package-transitive-supported-systems, implicit inputs" test fails because i586-gnu is missing from supported-systems <mbakke>not sure why that derivation is pulled in from my guix system image command <janneke>i guess because we have no sensible ci in place just yet <gnucode`>zamfofex: I really should log in as GNUmoon sometime. haha! <gnucode`>hmmm, showtrans /home --> outputs nothing <mbakke>I could use more puns for the tryhurd.gexp.no loading messages ... <azert>Im sorry for the confusion between gnucode and gnumoon <azert>I really thought they were the same <azert>Philosophy question: to what extent the Hurd is or can be made robust to random server crashes? Would it be possible in theory to kill and replace the proc or the exec server and have all apps keep running? <azert>Let’s see if anyone dare to answer.. <azert>Most difficult is probably ext2fs, since it is prone to mount the file system read only upon a dirty shutdown. But one could imagine adopting an fs without this issue <janneke>headsup, the "guix" package builds again on hurd-team, thanks mbakke <nikolar>azert: how would the new proc iherit info about the processes <nikolar>and any server that keeps volatile data <azert>Well you need a policy that servers don’t keep any volatile date <azert>Proc might still ré-register processes as they come <azert>Even now one can start a new task without registering it to proc <nikolar>so not keeping volatile state means always writing to disk, which means everything is slow <azert>Depends, state might also be kept on client owned memory <azert>And servers use shared memory to access it <azert>Regarding proc, I wonder why on Hurd tasks not register themselves directly with the filesystem. Using things like pidfd by default <azert>In any case, keeping the state mostly on client owned memory is a cleaner interface, and there is nothing really to hide to clients when it is about their own state <Gooberpatrol66>azert: minix 3 had a "resurrection server" or something that detected hung or crashed servers and restarted them <nikolar>minix kept track of proc and such in kernel