IRC channel logs


back to list of logs

<nickgaw>Hi, From a users point of view what would I notice with using the gnu hurd over a linux system?
<damo22>memory usage is much lower
<damo22>its a microkernel system design, all the things are in separate userspace processes
<nickgaw>Is it still being maintained?
<damo22>its being developed yes
<damo22>just slowly
<nickgaw>Are there still methods for getting access to a hurd system remotely?
<damo22>you can boot it up in qemu very easily
<damo22>see the topic for image
<nickgaw>I will look into it but no more remote accessible hurd systems?
<damo22>i dont know
<damo22>you can run it locally and shell into it
<labrador>This is nice
<labrador>hurd is still being developed?
<damo22>i want a 64 bit gnu/hurd that records audio and browses the web, then i will probably ditch gnu/linux
<labrador>why tho?
<labrador>whats wrong with linux
<labrador>its okay at being a kernel
<ThinkT510>it is always good to have alternatives
<ThinkT510>BSD does not have a microkernel design
<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
<labrador>yeah I guess microkernels are stabler
<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?
<Pellescours>I don’t know
<biblio>Hi, any update of initial support (32-on-64) "64bit boot support from grub" and "32/64 RPC compatibility for RPCs served by kernel". Is anyone working on these ?
<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
<biblio>curiosa: I saw but could not find any master-x86_64 branch. Yes I agree.
<curiosa>Interesting discussion
<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
<luckyluke>Xnu is probably worth a look, yes
<biblio>luckyluke: One thing is not clear to me. Do we still need to add patch in grub to boot 64bit gnumach ? based on
***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
<biblio>luckyluke: . ok i will check.
<luckyluke>Another useful source could be the x15 code, this is the entry point from grub
<biblio>luckyluke: ok noted