IRC channel logs

2024-10-09.log

back to list of logs

<gnucode>morning friends.
<gnucode>damo22: I've edited the wiki with your recommendations about not using coreboot, if wanting to use X. I'm at work now, so I'll have to send the patch in 8 hours or so.
<user_oreloznog>hello !
<gnucode>howdy user_oreloznog
<user_oreloznog>Hi gnucode! I'm running Guix System right now and hope to have the time to resolve a ssh key problem. It's about trying guix-hurd in a virtual machine.
<gnucode>user_oreloznog: that sounds like fun.
<gnucode>I also use guix system. I seem to have a much harder time updating lately with guix system.
<ZhaoM>hi darnassus.sceen.net is down so the searching bar on https://www.gnu.org/software/hurd/hurd/documentation.html does not work
<sneek>Welcome back ZhaoM, you have 2 messages!
<sneek>ZhaoM, gnucode says: The Hurd project is really useable! I edit the Hurd wiki, render changes, view the resulting webpages, and send the git changes from a Hurd running on a Thinkpad T43 with 1.5 GB of RAM.
<sneek>ZhaoM, gnucode says: I hope to install it on a T60 shortly. More RAM, faster processor, all that good stuff.
<ZhaoM>is there alternative?
<gnucode>ZhaoM: do you mean a faster laptop to run the Hurd on?
<gnucode>The X200 or T400 is probably the latest Thinkpad that has working internet with the Hurd.
<gnucode>but it's slightly harder to install on.
<ZhaoM>gnucode: oh I mean the searching bar on https://www.gnu.org/software/hurd/
<gnucode>The T60 is probably the easiest to get set up and running, but if you want to use X on it, then you cannot use coreboot or libreboot.
<gnucode>What's wrong with the searching bar on the wiki?
<gnucode>works just fine.
<gnucode>except for now...it was working for me a little bit ago.
<ZhaoM>btw the machines that can run Hurd is also interesting to know
<ZhaoM>I feel a bit unnatural to use virtual machine to play with the Hurd
<ZhaoM>gnucode: I am quite curious about what are the main difficulties of running the Hurd on different machines (I'm new to OS).
<gnucode>ZhaoM: "main difficulty of running the Hurd on different machines."
<gnucode>well, it's just like running Debian.
<gnucode>I'm currently running i3, emacs, netsurf. Works fairly well.
<gnucode>I'm planning on writing an article on the wiki called "Hurd Pain Points" Or maybe "Hurd Gotchas"
<gnucode>basically there are a couple of things that if you do this, then you will lock up your computer, which when you hard shutoff will cause filesystem corruption.
<ZhaoM>I'm quite looking forward to it
<gnucode>eg: start X, then open a terminal and type in "sudo halt" -> filesystem corruption.
<gnucode>You first have to quit X, then run "sudo halt."
<gnucode>when you get your computer, please do bug me on irc to ask me to share the "Hurd Paint Points" document. It'll save you some issues later.
<youpi>is that really reproducible?
<youpi>it's really odd that X would have an impact on ext2fs
<youpi>possibly X just doesn't manage to shut down, preventing proper shutdown?
<gnucode>youpi: is that really reproducible ? I'm happy to execute sudo halt inside X again and see what happens.
<gnucode>but basically after you execute sudo halt inside X, I could not get back to the Hurd console.
<youpi>ok but you mean the system doesn't actually shut down ?
<gnucode>so I had to hard shutoff, which caused the corruption. I suppose I could have tried ssh-ing in to halt the machine...
<youpi>then it's not the sudo inside X that produces the corruption
<youpi>it's shutting down by hand
<youpi>make sure to be specific, otherwise it's just vague reports that one cannot do anything about
<youpi>also, try sudo shutdown-hurd
<youpi>that won't wait for X or whatever to shut down
<youpi>ssh-ing to the machine would allow to determine what doesn't shut down
<youpi>and from there it could be determined why
<gnucode>Would you like me to try (while running X) to run shutdown-hurd to see if that makes a difference ?
<youpi>you can yes
<gnucode>ok. I'll keep you posted.
<youpi>my point is that articles that pinpoint painful stuff are useless and just bring bad press
<youpi>what is useful is to work on pinpointing what exactly there is going bad
<youpi>sudo halt involves a lot of things
<gnucode>youpi: may I argue my point a little? I had an issue that annoyed me for several days...until I figured out what was wrong. "startx" stopped working. I couldn't figure out what was 'cause it to fail.
<gnucode>then I figured out that /home AND/OR was --readonly.
<youpi>sure, that's annoying
<youpi>doesn't mean that writing an article about it will be beneficial for the hurd, on the contrary
<gnucode>While that may not be a "bug", the casual user could get confused why startx suddenly stops working.
<youpi>people will take from it "bah, hurd can't even startx several times, boo"
<youpi>it definitely is a bug
<youpi>at least in properly reporting in error messages why it doesn't work
<gnucode>youpi: would you like me to re-name the article "Hurd Tips" ?
<youpi>still
<youpi>tips that are just work-arounds for bugs that should just *not* be there from the start, is not really a good way to move forward
<youpi>if a bug is hard to fix, a tip page could be written, yes (and *tell* why it's hard to fix)
<youpi>but most often bugs are not hard to fix
<youpi>it's just that nobody takes the time to investigate where the bug actually is
<youpi>we don't lack people reporting things happening wrongly, what we lack is people working on pinpointing exactly where things are getting wrong
<youpi>and then most often patching is easy
<gnucode>ok. Well I've already got the document mostly written. I'll send it in the email list, and you're free to not commit it. But maybe some of the tips have easy solutions, that you would like me to add to the small hacking entries. Sound good?
<youpi>if it's not a "solution" but a "work-around", we should just work on fixing them, not on documenting them
<youpi> https://darnassus.sceen.net/~hurd-web/open_issues/ext2fs_dtime/
<youpi>is an instance of something odd that is hard to fix
<youpi>and thus documented
<youpi>but otherwise a lot other cases are probably just easy to fix
<youpi>it's just that nobody takes the time to pinpoint what exactly goes wrong
<gnucode>Also, did my latest wiki edits & Qoth upset you somehow? I'm happy to re-edit the latest qoth, which you pointed out some issues, and resend it.
<youpi>that didn't upset me no
<youpi>it'sjust the usual review process
<gnucode>ok good.
<user_oreloznog>gnucode: oh, sometimes me too, but it's generally solved by launch again some commands and/or adaptative options...
<gnucode>adaptive options ?
<Gooberpatrol_66>user_oreloznog: if you're having the same problem as me, it's not an ssh issue, you can't log into the vm at all, even through VNC
<user_oreloznog>gnucode: eg: 'guix upgrade --fallback' if the 'guix upgrade' command failed.
<user_oreloznog>Goberpatrol_6: I meant, it's not an issue, as my private and public keys are obsolete. Just need to work around to reactivate theese ssh keys things.... When I'll have enough time :)
<user_oreloznog>Goberpatrol_66: Sorry, I meant, it's not an issue, as my private and public keys are obsolete. Just need to work around to reactivate theese ssh keys things.... When I'll have enough time/energy :)
<Gooberpatrol_66>ah i see