Re: Hurd Advocacy?
On 18-Aug-03 19:07:19 Farid Hajji <farid.hajji@ob.kamp.net> 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 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*.
>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:timrue@mindspring.com
Web @ http://threeseas.net
Virtual Interaction Configuration (V.I.C.)
http://freshmeat.net/projects/victor1
Reply to: