On 18-Aug-03 19:07:19 Farid Hajji <[EMAIL PROTECTED]> wrote: >me wrote: >> On the advocacy issue it is the above which is a good part of the reasons >> I'm watching two OS development projects. The Hurd of course being one of >> them, and by far the larger. The other, and to use the analogy of a smart >> terminal vs. dumb terminal... the other is the Amiga clone project AROS >> which besides being targeted to be a standalone, is currently running >> hosted on Linux. But I think the two (The Hurd and AROS) can make for an >> interesting pair running together. >[snip]
>The Hurd's project's objectives can be seen from two perspectives: > 1. being technically superior, innovative, bleeding-edge, ... > 2. being popular among mainstream (Linux?-)users. :) & 3. User Space Freedom. >This is similar to BSDs vs. Linux. Both are excellent projects and I >like using both kinds of OSes. Both are also excellent cultures, which >cross-polineate each other,..... [snips only to shorten response] >... Sure, both projects contribute greatly to open source and free >software, but they do so from different directions. Not sure I follow you here. There is no "this vs. that" in what I'm on about, there is only what can be done in the user space freedom, that I'm .... advocating the Hurd. >The Hurd, being work-in-progress, needs developers (and users to >test and help spread the word) from both camps...... [snip] we also >need innovative grass-roots developers, who are ready to jump in and >contribute new ideas and code in a Linux-like manner. The needing of developers is something even AROS needs, but spreading the word about each to the other and beyond is what I've been doing, more so spreading word about the Hurd in the larger scope of the "amiga like" land. Telling Hurd development efforts about such things as AROS and the V.I.C. tends to get wrongly preceived and results in a "don't distract us from our development focus with what others are doing" and oddly enough I understand the why of this error, and I'm even OK with it.... as long as the development direction of the Hurd is staying on such a course that will be technically supportive of these other efforts, when it is ready. Again, my advocating the Hurd is in regards to what can be done in it's user space. While pointing out that in a multi-user system there are security issues that must be delt with. And the Hurd has to deal with them, though the target is to remove the false constraints imposed upon the user. Dealing with security issues of a multi-user system does add code overhead, in comparison to a single user personal system. And there are often tradeoffs in what is and is not part of an OS. If you do not need multi-user security and are willing to give up real memory protection then you can make a much smaller and faster OS that inherently has no user access constraints. The best of both worlds combined, not just one on top of the other, but plugin integrated so to share resources, via user space freedom and IPC. 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. I say "physical" here meaning "Physics", but it's becomming more and more apparent that there are often other reasons to create and/or maintain false constraints. Job Security is one. Making people need you by preventing them from easily (within the scope of their available resources of time and knowledge) doing something without you (MS knows this quite well.) GNU/Hurd provides increased user freedoms in the scope and security of a multi-user system while having access to a huge resource base of functionality/applications. It has alot of overhead in comparison to the needs of a single user personal system, a difference the user does have to deal with, even though their focus is only in regards to doing stuff in their user space. IE, file access and protection bits/flags. It's nice to be able to see what you can of what all is out there in the "world", but the only thing relevant to the user doing things is what they have access to. It can be, and often is, extra work complexity, to determine the difference between what you can see an what you can actually use, or understanding in what ways you are allowed to use it. But to be using a system within the user space, that has only what the user can actually use, available to them.... (this does not exclude the ability of the user to step outside of such a system to see what they may, from within their user space of the Hurd). 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. Who said we can't have our cake and eat it too? And this is not the tool set for allowing the user to more easily put things together for themselves, but only creating an environment that inherently provides support for it, extending user freedom potential. 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". In sum: Functioning resources fromthe "commons" available thru the security and stability of a multi-user system, accessable in user space by the user and thru a user friendly OS (smart terminal) where the available functioning resoures can be integrated and controlled by the user, as they see fit, without the concern of dealing with multi-user system security issues. Instead of a this OS vs. that OS it is a "this OS that inherently provides these benefits (resources, security and stability) to this other OS that inherently provides these (ease of use and ease of integration of available resources, or putting things togeher) additional benefits. >We've got a pretty good contact to L4 developers at l4ka.org as well. >..... [snip]....... The complete infrastructure >is finally in place (L4Ka::Pistachio, IDL4 compiler, a device framework >from DROPS or e.g. NetBSD sources, ...) to build the framework on which >a new Hurd could be build upon. >To attract talented developers (from both camps), we need *.... [snip]..... > * developers of user-space applications, distributions etc..., > which would port applications to the Hurd, extend the Hurd > by writing more translators, device drivers, ... People with > this set of skills are probably most represented in the Linux > community and I'm confident that we'll find enough hackers who > are willing to help (in addition to those already working on > debian-hurd). .....[snip].... >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*. >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 *.) MorphOS is an Amiga like clone, made free to Genesis Pegasos PPC hardware owners as a default OS, but proprietary (closed source). May have Amiga IP issues (Amiga curse). Amithlon - was a popular mostly proprietary Amiga(tm) emulator that required Amiga ROM Kernal Images. It was distroyed by the curse. * 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) ------- I hope I have clairified the difference between the values of a multi-user system and a personal single user system enough that you can see the user freedom advantages in connecting them. I also hope I've clairified any faulty perception about what AROS is. That on the hurd, or otherwise connected to the Hurd (via internet shell account) AROS would be considered a user space application or smart terminal (depending on were and how it is run.) External to the Hurd hardware, as smart terminal, it would also help to reduce it's (and the users) load on the Hurd. At least until people figure out how much functionality resources are available to them to integrate and find a need to, as they see fit...) When people better understand the potential of the Hurd, they will realize the value of including a common end user accessible IPC side door to applications, function libraries and devices, such that one can access the functionality of such without having to access its CLI/GUI. Making it commonly possible for the end user to put functionality together while accessing the functionality from a smart terminal, perhaps remotely, which may have it's own user definable GUI system for such integration. Correct me if I'm wrong, but isn't this functionality accessability what translators are all about? Not to mention the "server" nature of the hurd to "serve functionality"....;) How secure would something like AROS be, when running on the Hurd? As secure as a user space directory on the hurd can be made to be, and this might additionally mean the mounting of a USB micro ramdrive device (car keys), a business card size CD (credit card) or other such device (analogy). Security is handled by the Hurd and user possession of device. As to being connected to the hurd as a smart terminal, that too, is a Hurd security matter. Hmmm, I wonder if you could use the hurd to set up a functionaly access rental system???? (not that I'm interested, only looking at what is possible) --- Timothy Rue Email @ mailto:[EMAIL PROTECTED] Web @ http://threeseas.net Virtual Interaction Configuration (V.I.C.) http://freshmeat.net/projects/victor1
