IRC channel logs


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>and showed that X worked just well.
<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>no theyre not
<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>more info: file hurd-2013.img
<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)
<gnu_srs1>file hurd-2017.img
<gnu_srs1>hurd-2017.img: DOS/MBR boot sector
<mbakke>hey, I made a service that provisions a Guix/Hurd image on a remote machine and connects it to your browser:
<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>mbakke: waaay cool!
<janneke>mbakke: which "guix", exactly?
<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
<janneke>whut, the x86_64 build is broken?
<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>why does stuff keep breaking?
<janneke>i guess because we have no sensible ci in place just yet
<nikolar>mbakke: ok that's pretty cool
<Gooberpatrol66>mbakke: that's very cool
<gnucode`>morning hurd friends!
<gnucode`>zamfofex: I really should log in as GNUmoon sometime. haha!
<gnucode`>hmmm, showtrans /home --> outputs nothing
<gnucode`>fsysopts /home --> outputs the options
<mbakke>I could use more puns for the 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>that's mostly for device drivers
<nikolar>minix kept track of proc and such in kernel