IRC channel logs

<jemarch>oh well, step by step. gnumach built swiftly

<jemarch>gzip -9 < gnumach > gnumach.gz

<GNU_Hurd_Rocks>jemarch: yes, aarch64, personally would love to see RISC-V perhaps

<GNU_Hurd_Rocks>uh wait how small is the overall system?

<GNU_Hurd_Rocks>I have a Pico2, was thinking I could see what it would take to have Hurd on it

<damo22>what is its boot media?

<GNU_Hurd_Rocks>damo22: it can be flashed with UF2 but I think there is some partitioning that can be done

<GNU_Hurd_Rocks>and the flashing can be done over USB or I think UART

<GNU_Hurd_Rocks>damo22: this is covered much better in the manual, https://pip.raspberrypi.com/documents/RP-008373-DS-rp2350-datasheet.pdf

<damo22>is the boot media in flash?

<damo22>is it SPI?

<damo22>looks like it

<damo22>i dont recommend developing hurd on something that requires its boot media burnt into a chip

<damo22>develop it on a more flexible boot media

<damo22>eg sdcard

<damo22>ie, find a riscv board that allows booting off something other than SPI

<Gooberpatrol66>nice hurd shirt

<jab>jemarch: I run the Hurd on a T420. It works fairly swell.

<jab>i3, emacs, netsurf, etc.

<GNU_Hurd_Rocks>i3?! damn

<jab>works just fine.

<jab>I've had some issues...maybe once a month (or every other month), the Hurd will lock up.

<jab>and I have to hard-shutoff.

<GNU_Hurd_Rocks>damo22: ideally I would want more RAM anyway, and more storage to actually fit decent programs

<jab>GNU_Hurd_Rocks: I believe we have a working xfce4 as well.

<GNU_Hurd_Rocks>anyone here aware of RISC-V boards that are decently open enough for development on?

<GNU_Hurd_Rocks>will ask #fsf too :3

<damo22>i have a milkv jupiter

<azert>when I developed for an aarch64 board, u-boot would allow to load the kernel and everything else directly from the serial console

<azert>that was very handy. Best in fact would be to keep everything on the sd and load what is developed over serial

<GNU_Hurd_Rocks>damn, no longer online

<GNU_Hurd_Rocks>was going to say that the Pico2 can have code loaded into its main memory, possibly over USB but I don't remember the UF2 format enough

<Gooberpatrol66>sneek is a bot that leaves messages for offline people

<Gooberpatrol66>sneek: later tell azert ignore this

<sneek>Will do.

<GNU_Hurd_Rocks>Gooberpatrol66: ah, very helpful

<GNU_Hurd_Rocks>damn, wish I would have remembered the MilkV Duo existed

<GNU_Hurd_Rocks>I don't know honestly, none of these boards interest me enough to actually like them, will have to design something from scratch but I don't have the time for that sadly

<azeem>jemarch: IIRC oskit was abaondened (maybe because Roland never finished it before mostly leaving development) so we sticked to gnumach-1.3 and now use rump for drivers. I might be wrong though.

<GNU_Hurd_Rocks>azeem: rumpkernel for drivers

<jemarch>rump, that I don't know

<GNU_Hurd_Rocks>something BSD, NetBSD?

<GNU_Hurd_Rocks>there is a wikipedia on it, https://en.wikipedia.org/wiki/Rump_kernel

<jemarch>I see several Linux drivers under gnumach/linux but no reference to rump kernel

<azeem>the rump code is external

<azeem>jemarch: I haven't really followed along, but the rump glue code seems to be in Hurd itself

<youpi>partly, yes. The idea is that the OS-porting code is in the rumpkernel repository itself, which builds librump* libraries, and then we have a translator in the Hurd itself, that uses these libraries to expose them in a hurdish way

<jemarch>oh ok

<jemarch>nice

<jemarch>oskit was rather invasive in mach

<jemarch>I see

<jemarch>rumpdisk and rumpnet are translators

<azert>jemarch: I think it would have been nice to have oskit, a good update of the Linux drivers

<sneek>Welcome back azert, you have 1 message!

<sneek>azert, Gooberpatrol66 says: ignore this

<azert>but keeping new drivers outside the kernel is even better

<azert>porting to riscv can be a good catalyst for this model. These boards are all different as such user space drivers make even more sense

<azert>you could think of a minimal denominator kernel with drivers just for cpu-level interrupts delivery and an uart for kernel messages, and everything else taken care in user space

<damo22>afaik, oskit low level drivers are all missing source so only the framework exists, one would have to implement the actual drivers from scratch?

<damo22>thats why rump is preferable, because we dont have to maintain the driver code

<azert>damo22: I think there are two different oskit. Utah’s oskit is just another Linux drivers wrapper, and that’s what at some point was planned for gnumach

<azert>then there is Apple oskit that is a new c++ based driver framework for the MacOs. While the latter may be fully open source, the drivers for it are not open source and very osx specific. I don’t think this was ever taken into consideration

<azeem>IIRC Roland was employed at/working with the University of Utah at the time, possibly with the expressive itent to get oskit to work and/or he looked at it as a side-project

<azeem>right, Apple has a tendency to call things with "kit" at the end, this predates oskit-mach

<azeem>eh, oskit-mach predates OS X

<azert>it’s a weird name, they could have called it DriversKit

<azert>you cannot build an OS with Apple oskit

<azert>anyhow, those things are so much in the past that makes little to no sense discussing

<azert>would be like discussing the choice of Mach for GNU after Steve Job hired its main architect for NeXT

<azert>a posteriori, it is easy to tell that it was insane

<azert>but nowadays anyway Linux is leader

<azert>so it makes sense as a long term solution

IRC channel logs

2026-09-07.log