IRC channel logs

2026-07-06.log

back to list of logs

<paculino>Coreboot includes some drivers in one laptop now. Would that satisfy rms or must it be gnuboot thinkpad
<damo22>hurd does not exist just to please rms btw
<solid_black>morning!
<Alicia>good morning solid_black
<solid_black>I saw https://salsa.debian.org/hurd-team/hurd/-/commit/10dffe164c1d8e8b3b55e1cec36a8bcee59400c3
<solid_black>which, correct me if I'm wrong, disables any and all MIG type checks for incoming fs and io RPC requests
<solid_black>which is a HUGE security hole, to put it mildly
<solid_black>i understand that this is being done to have some grace period so we can later change what new-style structs desugar to,
<solid_black>but maybe there should have been more of an announcement and discussion?
<youpi>solutions welcome
<youpi>to be frank, I see a lot of people discuss, but not that many people actually propose solutions
<youpi>and not actually seeming to care that solutions are needed
<youpi>so at some point, yes, I end up just pushing forward to get something actually working
<solid_black>I don't mean to sound unappreciative of your work
<youpi>I understood that
<youpi>I'm just explaining the why
<solid_black>"let's just disable security" might be an acceptable trade-off in this case, or not, but indeed I have not seen it discussed, or even announced
<solid_black>and even that patch bears no explanation of what it actually does and what the security impact of it is
<youpi>again, help welcome
<solid_black>it just says "Avoid 64b typing error"!
<youpi>as in: I don't think the 64b typing was entirely tested
<youpi>just like the recent proposal to change the 64b time type was clearly not tested: it would break the existing 32b userland
<solid_black>yes
<youpi>at some point I just don't have the mere time to keep taking the time to raise concerns
<youpi>and just move forward
<solid_black>hmm, I wish we could have a variant of dir_lookup that moved the port into the call, so the server could see that there are no other send right to it
<solid_black>is vm_allocate_contiguous the only way to get a physical address for a memory block from userspace?
<solid_black>in particularly I'm interested in finding out the physical address for an existing page mapping
<solid_black>i.e. a way to invoke vm_map_pageable / vm_wire, and get the physical address back
<jab>damo22: while I do agree that the Hurd does not exist to please rms, it would be pretty cool to let him run the Hurd before he dies. He did a lot to get this project going.
<jab>I mean he can run it in qemu of course, but it would be cooler to have him run it on real hardware.
<jab>paculino: the last time I emailed rms, he said that he wants to use GNU Boot. libreboot (and coreboot I believe) bundle some binary blobs.
<jab>I personally use libreboot. Try running a T60, T400 without those blobs. The thing overheats under too much computation (video editing) and hard shuts itself off.
<jab>The only blobs I currently use are those CPU microkernel updates, which in my opinion...you should probably run.
<jab>alos, if it is flavio that is doing the new typed structs work...it would be great to have some kind of annoucement email in bug-hurd once it is done
<jab>so that I could write about it in the next qoth.