Re: RMS: users request you perhaps program HURD: they fear the path the linux kernel is going.

[Alexander Vdolainen]

On Wednesday, November 13, 2019 1:50:52 AM EET Svante Signell wrote:
> Hello,
Hi,
> 
> below are incomplete answers to your questions and some links. Many facts
> are supplied by Samuel Thibault, the main GNU/Hurd developer. Since he is
> very busy, he does not want to reply directly due to lack of time to answer
> any follow-up questions.
> 
> Thanks!
> 
> On Tue, 2019-11-12 at 10:44 +0200, Alexander Vdolainen wrote:
> > Hi,
> > IMO GNU Hurd is a good thing to have, btw at the moment Hurd architecture
> > 
> > isn't so good:
> >  - it's a microkernel, isn't it? if so, why mach still contains drivers
> >  ...
> 
> We're working on this, precisely. The most promising is usage of rump kernel
> drivers, from NetBSD, see https://en.wikipedia.org/wiki/Rump_kernel. Very
> soon these drivers will be supported in Hurd.
it's nice to know, will check out this topic later.
> 
> > why not to use a 3rd microkernel generation ... etc ...
> 
> Why doing it? This has been done in the past, it's a lot of work, while
> we can on the contrary shrink Mach instead.
Just because of IPC, yep it's still possible to do so with Mach, but IMO there 
are comparable efforts to do so. 
> 
> >  - MIG ... it's an ugly thing
> 
> Frankly, like all RPC designs. Newer ones have a nice red package, but
> in the end the issues will always be the same.
And yes and no. I will pin this mail message to reply with more technical 
details about this later. Personally it isn't something I'm not familiar with.
> 
> > as I understood GNU hurd development has stalled due to the different
> > reasons, but one of them is architecture itself.
> 
> Not really, it's the fact that yes it's more complex to make
> non-monolithic designs, and thus people prefer to go work on Linux, and
> only cry when they happen to want to do containers.
Again, it isn't something i'm not familiar with, and from technical point of 
view monolithic design loses to microkernel design.
However, to make microkernel design truly secure iommu is required. As far as 
I know Hurd doesn't support iommu yet, am I right ? (I would like to be happy 
if I wrong) 
> 
> Very soon now, Gnumach+Hurd will also have SMP support. Regarding 64-bit
> support 64bit userland is not planned for, but 64-bit kernelland has made a
> lot of progress, see https://www.gnu.org/software/hurd/faq/64-bit.html.
I suppose full 64bit support is quite required nowadays. It's nice to have an 
OS sandbox and playground, but I wish Hurd to be a real working horse.
> 
> > To change this a lot of work is required, but nobody wants to go deep with
> > that.
> > 
> > however, if we're going to speak about GNU system we're limited with a few
> > 
> > components:
> >  - GNU userland - ok it exists
> >  - GNU toolchain - yep it works
> >  - GNU kernel/system services - ... nope
> > 
> > I know linux kernel just works, but it's not a GNU project.
> 
> Debian GNU/Hurd has been available for a long time. Around 75% of all Debian
> packages are available, see
I know. 
> 
> For more info see:
> http://darnassus.sceen.net/~hurd-web/
> https://www.gnu.org/software/hurd/index.html is outdated.
> https://www.debian.org/ports/hurd/
> https://wiki.debian.org/Debian_GNU/Hurd
thank you ! will check out this links too.

-- 
Alexander Vdolainen,
The evil contractor.

signature.asc
Description: This is a digitally signed message part.