<nickgaw>Hi, From a users point of view what would I notice with using the gnu hurd over a linux system? <damo22>its a microkernel system design, all the things are in separate userspace processes <nickgaw>Are there still methods for getting access to a hurd system remotely? <damo22>you can boot it up in qemu very easily <nickgaw>I will look into it but no more remote accessible hurd systems? <damo22>you can run it locally and shell into it <damo22>i want a 64 bit gnu/hurd that records audio and browses the web, then i will probably ditch gnu/linux <damo22>labrador: linux is good at being a monolithic blob of stuff that you cant easily audit and all the drivers run as root <damo22>hurd gives you the ability for example, to kill the audio driver and restart it without causing a kernel panic <damo22>it separates the execution, licensing concerns and debugging of each driver out to different components, and they all communicate via remote procedure calls (RPCs) <damo22>so you can run gdb on a driver while its running ***biblio_ is now known as biblio
<slex>Hello guys, can someone say me what was xMach? Mach 4 successor? <curiosa>Regarding that discussion for the 64-bit mig port, wouldn’t it make sense to see what they did in mug for macOS? If I recall correctly at some point they had a 64bit kernel supporting 32bit userland <curiosa>I’m wondering if the conversion from port names to ports in xnu is obtained just by adding a constant base address, that would amostly retain the optimization that rbrown was referring to <luckyluke>You can compile 64-bit gnumach from the master branch. I think currently it only supporta xen, I was trying recently to make it work on qemu with multiboot but no success yet ***Noisytoot_ is now known as Noisytoot
<luckyluke>We need to fix gnumach to handle multiboot when compiled for 64 bit, and handle the boot sequence, which is a bit more complicated than on xen <luckyluke>I think this could be enough to be on the same level as the xen port <biblio>luckyluke: ok. I have some spare time to contribute to 64bit port. do you have any idea which part to start with ? I would like to focus on initial support (32-on-64) then pure 64bit support. <luckyluke>I was stuck with the vm layout, if you want tomorrow I can share some code <biblio>luckyluke: sure it would be great. <luckyluke>I would suggest to get familiar with how the address space is organized <luckyluke>I already had something that could jump from 32 bit protected mode to 64, just with the wrong memory layout ;) <biblio>luckyluke: yes I read recently about address space. Also memory management in Linux Books. <biblio>luckyluke: yes I have theoretical idea. And checked some assembly code in Linux about this jumping from 32bit protected to 64. I hope I can help. :) <luckyluke>Then I had linker issues trying to use the range over 4G, and I didn't fix that yet