Re: Hurd Advocacy?
[Timothy Rue]
> There may seem to be some redundancy here from a very general perspective,
> but user freedom does go beyond removing false constraints in user space.
> Ease of use contributes to improving user freedoms but even more important
> is the ease of which the user can put things/functionality together, for
> themselves. There are alot of resources, already built functionality,
> created under the GPL and such. No physical reason why such resources/
> functionality can't be presented to the users in a manner that allows the
> user to easily put things/functionality together, for themselves and as
> they see fit.
The Hurd is one possible architecture which gives users the freedom
to implement and use their own semantics. Say, you want a special
kind of filesystem with custom ACLs etc.., all mounted on a
subdirectory of $HOME? No problem: Write or modify an FS translator
and you're set. You want to use an alternative network stack because
you're not happy with pfinet? No problem: Write your own and hook it
up in the global tree. You can do this even on a multi-user machine,
without being root. That much freedom is unthinkable in current
monolithic systems.
The Hurd is also about stability. Say, you want to write or test
a new device driver. In Linux or BSDs, you'd probably use kernel
modules. In the Hurd (once we've completed the transition to Hurd/L4
with drivers running as user-level tasks), all you need to do is
start a new device driver server in userland (we'll discuss
details on l4-hurd@). If there's a bug in a Linux or BSD kernel
module, you'll panic() the system. A bug in a user-land Hurd
device driver would simply cause that driver task to be terminated.
You get a much more stable system this way.
The Hurd has also potential for some kind of virtual machine.
Because it runs on top of a microkernel (like Mach now, L4 in
the future), it doesn't hog the hardware alone, but must access
it through a layer of abstraction (the microkernel). This is the
key to virtual machine architectures like IBM's S/390 and similar
OSs of parallel machines. The Hurd can run in parallel with other
OS servers simultaneously. Nothing prevents you from running
the Hurd, some sub-Hurds and e.g. Lites (an early BSD OS-Server)
at the same time on top of Mach. Some resources still have to be
synchronized, but that is not a show-stopper here.
The Hurd has very high potential for portability, as soon as
we get Hurd/L4 rolling. L4Ka::Pistachio already runs on multiple
CPU architectures (see http://l4ka.org/) and a port of Hurd/L4/x86
to, say, Hurd/L4/ppc, Hurd/L4/ia64, etc... is mainly a matter of
porting glibc and a very tiny amount of glue code. We don't have
to care of L4's internals if we don't have the resources to
do it: The L4 community is doing an excellent job at this.
> A single user system is generally easier to use than a multi-user system
> in very inherent ways. But the multi-user system of GNU has far more user
> available resources than a typical single user system.
Ack.
> The tool set is around the corner and platform independant, but IPC is the
> third user interface (CLI and GUI being the first two) that allows
> "putting things together".
My bogometer just triggered :-)
OS design is still complex engineering task. In the future, users may
be able to drag and drop modules, filesystems and other resources in a
nice flashy GUI environment (why not?), and they are also free to
shoot themselves in the foot. Multiple times. With a machine gun...
After all, it's all about user freedom. Nah, just kidding :-))
> >If you're interested in contributing code to Hurd/L4, please consider
> >subscribing to the l4-hurd@gnu.org mailing list.
>
> I may subscribe, probably will (is there a non-subscriber web based
> archive I might use for monitoring the list?), but will pass the info
> along to the AROS effort, that some may at least monitor the hurd L4
> development that it may influence decissions they make with AROS
> development. Especially as it relates to *running as a user-space*
> *application on the Hurd*.
http://mail.gnu.org/archive/html/l4-hurd/
Sure, AROS could one day run on top of Mach or L4, and coexist
peacefully with the Hurd on the same box. It may also run inside
the Hurd as a task (or set of tasks). You're welcome and encouraged
to put AROS on top of a microkernel (I'd really recommend
L4Ka::Pistachio for this) instead of the bare metal.
> >P.S.: As far as AROS is concerned: Did you have a look at NetBSD,
> >including their amiga port? Actually, I personally think that one
> >way to refactor the Hurd would be to do some kind of NetBSD/L4
> >port (or partial port) first and then use as much as possible from
> >NetBSD's very clean architecture (MD vs. MI code, drivers, ...)
> >as framework for the Hurd/L4.
>
> FYI (To correct and clairfy your understanding of AmigaOS related works)
>
> AmigaOS(TM) is only being ported to the PPC w/bios dongle.
> (release uncertain)
>
> The AmigaOS has a curse on it, which has been identified to be rooted in
> its Intellectual Property Rights. All who become legally involved in its
> IP or rely on it are hurt by it. (the apex example of why proprietary is
> a bad thing, with a long list of those hurt and being hurt by the curse)
>
> UAE (a GPL'd Amiga Emulator) is probably what you are refering to, but it
> too requires proprietary Amiga ROM kernel images (*at this time - see
> below *.)
No, I'm not referring to UAE or any other emulator, but to the port
of NetBSD to Amiga:
Current: http://www.netbsd.org/Ports/amiga/
Future : http://www.netbsd.org/Ports/amigappc/
This is NetBSD on an Amiga. AROS is AmigaOS clone.
Sure, that's absolutely different, but both projects
could cross-polineate as well :)
> * AROS is a clean, from scratch, ground up portable clone of AmigaOS3.1
> (starting target - to evolve beyond that). Its license is based on the
> MOZILLA PUBLIC LICENSE Version 1.1. Because of its disconnection from the
> Amiga IP curse, it is being considered as a replacment of the Amiga ROM
> images used by UAE, which in turn would provide AROS with an emulator
> able to run original (classic) Amiga third party applications "without
> being recompiled to run natively on AROS". aros.sourceforge.net
> (BTW - like the Hurd, AROS is also being ported to PPC)
> How secure would something like AROS be, when running on the Hurd?
How do you define "secure"?
--
Farid Hajji. http://www.farid-hajji.net/address.html
Reply to: