[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 [EMAIL PROTECTED] 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
