>>>>> <olafbuddenha...@gmx.net> writes: […]
> For my desktop:
> - PPPoE/routing/NAT/packet filtering.
I'd much appreciate IPv6 support, and there will be virtually no
need for NAT for me then.
(There's an obvious interest in P2P in the free software
community, and effective use of P2P at the world scale is only
possible with IPv6.)
> However, I have been planning to get an extra router box for quite
> some time now -- so that is really only a temporary
> consideration. (Holding me back so far is the excessive cost of
> suitable x86-based boxes, and the inconvenience and limitations of
> MIPS-based ones...)
I'm not quite sure on what boxes were considered, but
personally, I've ended up using an Intel Atom 330-based system
in a Mini-ITX (InWin BM648) case as a router (1 Ethernet
interface on-board + 1 PCI + 1 USB).
Of course, it runs Exim, Rsync, Apache, read-only public NFS,
Tor, some traffic accounting, etc. just as well.
[…]
But once again I wonder, given the sheer variety of drivers'
code written for Linux, how NOT to duplicate the effort?
To my mind, the approaches considered so far were:
• glue code;
• Xen with a Linux-based dom0;
• message passing on top of Linux:
– with a user-space daemon;
– with a kernel module.
Do I understand it correctly that once a Mach could be made to
run in user-space (the same trick as with User-mode Linux),
making Hurd run on top of it will be straightforward?
This effectively makes the Hurd only a single command, namely:
# apt-get install hurd
away from from a J. Random (Debian) GNU/Linux user.
For those wishing for a better experience, a Linux kernel module
version of Mach could be developed at some time later.
Then, the sole question will be the tasks that Hurd covers.
Eventually, some users may find that they use little or no
native Linux modules, but instead use the Hurd ones. The
transition to GNU/Hurd[/Linux] will be over for them.
--
FSF associate member #7257
pgp00wS3s5s4T.pgp
Description: PGP signature
