IRC channel logs

2024-01-11.log

back to list of logs

<gnucode>also I'm curious what the issues with lwip are...
<gnucode>hmmm. So I think I can use debbootstrap to install the Hurd on my T410. I have Debian GNU/Linux installed on a seperate partition...
<solid_black>"someone" is "trying" to port the ladybird browser :)
<ThinkT510>solid_black: did I miss something?
<Arsen>I don't understand the quotations
<solid_black>that someone is me, and I did port it (see the screenshot that I posted on the mailing list)
<Arsen>ah, cool :)
<ThinkT510>sweet
<ThinkT510>nicely done
<gnu_srs1>solid_black: Did you send it to bug-hurd ML?
<solid_black>yes
<solid_black> https://mail.gnu.org/archive/html/bug-hurd/2024-01/pngq_2jXg0b5W.png
<damo22>solid_black: youre probably the only one with that user agent string
<damo22>lol
<gnu_srs1>solid_black: tks :)
<anthk_>on ext2fs, couldn't that be extended to ext4fs? I guess some API it's missing
<nikolar>ext4 is quite a bit more complicated
<nikolar>it's not trivial
<youpi>I'd like to point out something that might be misunderstood: journalized filesystems do *not* protect about filesystem implementation bugs
<youpi>I believe quite a few problems that people have with ext2fs are just bugs that are rare enough that we don't hit them so often
<youpi>notably, any issue while having rebooted normally would not be fixed by a journalized filesystem
<youpi>extending ext2fs to ext4 would introduce new code, thus new bugs, thus rather increase implementation bugs, and not protect from the existing ones...
<gnucode>solid_black: I thought you were hoping trying to get ladybird with the gtk4 port working on the Hurd
<anthk_>ladybird got a gtk port?
<gnucode> https://serenityos.social/@bugaevc/110963254207386754
<dsmith>gnucode, How goes the installation battle?
<gnucode>dsmith: well I think I found an example of how to use debbootstrap to install GNU/Hurd
<gnucode> https://darnassus.sceen.net/~hurd-web/hurd/subhurd/
<gnucode>That has some commands how how you might go about it.
<gnucode>But it only works if you are already running GNU/Hurd.
<gnucode>I wonder if Debian GNU/Linux can use debbootstrap to install GNU/Hurd in a spare paritition.
<gnucode>and maybe I should just try the text install.
<gnucode>or* maybe I should just try...
<youpi>gnucode: it's called crosshurd ;)
<gnucode>youpi: I guess I could try that. Does crosshurd support Debian GNU/Hurd?
<gnucode> https://www.gnu.org/software/hurd/hurd/running/debian/CrossInstall.html
<youpi>as the name strongly suggests... yes
<gnucode>very cool
<gnucode>I wonder why ./native-install must be run twice.
<gnucode>just curious...according to reddit GNU Mach is 344,000 lines of code. If we "clean up" GNU Mach...I wonder how many lines of code we would drop. Probably a fair amount of that is device drivers.
<dsmith>So I'm fairly ignorant of the Hurd (I'm mainly here for the bot). But wasn't the idea of Mach is a very small microkernel, and so drivers and things can be in userland?
<sneek>ACTION wags
<azert>Would be cool if all gnumach drivers would move to userspace. I wonder if this can be done
<gnucode>dsmith: yes that is the plan. The Mach should only have IPC, memory accounting, and scheduling (maybe other stuff).
<azert>What if something goes wrong.. there wouldn’t even be a way to signal errors
<gnucode>Currently Mach has disk drivers in the kernel. This may soon change with rumpdisk. One can already use rumpdisk for kernel stuff, but it uses almost 1GB of memory or something silly.
<gnucode>There are people running the Hurd and have disabled the in-kernel disk device drivers.
<azert>Did you guys followed this on hacker news https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-29361481f805@zytor.com/ ? Let’s say gnumach is ported to c++, what would c++ buy to gnumach that doesn’t buy to Linux?
<gnucode>So I believe that there are Hurd developers running the Hurd will no device drivers in the kernel.
<gnucode>azert: I've no idea. I'm not sure how the device drivers in Mach are handled.
<gnucode>azert: That would be a question for our fearless leader. I don't know how he feels about C++
<dsmith>You would not have a grumpy Linus...
<gnucode>true. Samuel is much kinder than Linux
<gnucode>Linus*
<dsmith>(Linus refuses to allow C++ in Linux)