IRC channel logs
2023-10-25.log
back to list of logs
<gnucode>is anyone going to be annoyed with me if I toot on fosstodon about our bcachefs talk ? <gnucode>I realize that there are no Hurd developers actively porting bcachefs to the Hurd (and probably won't be). <gnucode>but it was still a cool talk, and I would like others to be able to watch it. <gnucode>and I want to encourage people to donate to Kent's patreon. <gnucode>psydroid: also please don't post the link to phoronix. youpi didn't want me to do that. He didn't want people to accuse the Hurd project of being vaporware. <psydroid>gnucode: I avoid phoronix myself, so that shouldn't be an issue <gnucode>psydroid: thanks. I have to go and find the link again. Let me browse through bug-hurd archives. <gnucode>also I am currently trying to transcribe solid_black and damo22 talk about a simplified Hurd bootstrap/boot up idea. <gnucode>Any suggestions on where it should go on the wiki would be welcome. <psydroid>I can't say anything about that. Let's hope someone who is officially affiliated with the project jumps into the channel later today. <gnucode>at the very least I can transcribe it. <psydroid>are you a kernel/driver developer yourself? <psydroid>I only know Linux and I only wrote a driver a few years ago for my OS class <gnucode>psydroid: I appreciate the compliment, but I am primarily a documentation writer for the Hurd. <gnucode>I probably need to spend more time writing C code, to be a kernel/driver developer. <gnucode>my Hurd on bare metal almost locked up just now. <gnucode>I closed xfce4-terminal, and it began running smoothly again. <gnucode>maybe I need to play with using a different terminal. <gnucode>also git send-email appears to not work on the latest 32-bit hurd. <psydroid>being able to run it on bare metal is quite some progress <gnucode>psydroid: I actually think that the Hurd is easiest to run on bare metal. <gnucode>I have been trying to use the Hurd as an occasional daily driver for several years. <gnucode>I bought this old T43 with 1.5 GB. And it works. <gnucode>I have filesystem corruption that I have to deal with about once every two weeks. <gnucode>there are some other minor annoyances, but mostly I'm satisified. <psydroid>gnucode, I don't think I've ever tried to run it on bare metal <danmorg>gnucode: you're are definitely an inspiration for the Hurd. I have been lurking here for weeks. I would try to more C and become a kernel / driver developer. You can even write about your experience and this will encourage others to get involved. If anything the Hurd needs, is the documentation you provide... Thanks! I installed the Hurd weeks ago on a VM. but didnt know what to do after <danmorg>gnucode: I am sure you know about the https://wiki.osdev.org/Main_Page for those working on the internals of an OS. I found this tutorial on writing your own OS in assembly and C. Not so much to write my own, but it has helped me understand the low-level hardware details of protected mode 386 OS. Many OSes abstract the low-level details away. <danmorg>hmmm. i should try the Hurd on bare metal. does it play well with other OSes on a MBR partioned drive? I have Debian Linux and Minx 3 on it and use GRUB as the boot manager. and i have an available primary partition i could use. <kilobug>danmorg: GNU/Hurd requires Grub as bootloader so you should be fine, but its hardware support is limited, you'll have to check if it supports your hardware or not (sorry I didn't run it on bare hardware in a very long time so I don't know the current status) <danmorg>I usually use a live DVD of Debian linux to repair the GRUB after installing an OS. or use a partioner such as gparted which i have to install in the live os. my first partition (MRB partioned) is used as root \ for kernels and grub. i assume the Hurd would put its kernel there too. <gnucode>psydroid: thanks for the encouragement. That means a lot. <gnucode>danmorg: I have heard about it before...I should give it a try. <gnucode>danmorg: also I have been told that the Hurd runs on a Thinkpad 510. I actually bought one recently, but I have not tried to get it set up yet. <gnucode>my blog gnucode.me will probably eventually have the details. <luckyluke>are glibc's argz_next() and friends used only in hurd? I think I found a bug in argz_next() where a pointer is truncated to 32 bit... <youpi>it's used in some code of glibc <youpi>and other software, in debian <luckyluke>uhm, let me add some context... I was trying to understand why the mtab translator crashes on my hurd64 vm, and I found that the strings returned fron fsys_get_children(), when unpacked with the argz_*() rountines , crash <luckyluke>otherwise, the value returned from argz_next is truncated to 32 bit <luckyluke>it might be related to how I compile my code, or how glibc is compiled; if I copy the argz_next() code as-is, it still works, but if I use argz_next() from the library it fails <youpi>changing 1 to 1ULL shouldn't change anything here: strchr returns a char *, so we get normal char * pointer arithmetic here <luckyluke>yeah maybe it's the wrong lead, if I compile the code myself I don't need the ULL, but if I use the glibc version the result is truncated <etno>This is mysterious, reminds me of that time when the compiler didn't know about a function prototype and decided that the return type is (int) <youpi>luckyluke: you don't get any warning when building it ? <youpi>it's possibly missing some #include <youpi>and then, yes, there's a truncation, but not due to +1, but to assuming the return type is int <youpi>but string.h is supposed to bring the strchr prototype <etno>That's what I would imagine, yes