On Fri, Jun 24, 2005 at 01:13:21AM -0500, Richard Fillion wrote:
> You pose interesting questions. I think you should have sent them to
> uuu-devel@xxxxxxxxxxxx though, as you'd get a broader range of
> answers. (I'm cc-ing the list, hope you don't mind)
better yet, uuu-devel@xxxxxxxxxxxxxx We don't do anything on sourceforge
these days. Seeing that made me check the date header to make sure I
didn't phase shift to 2002.
> 1) Uuu as a userspace program ontop of linux. I've actually never
> run the Uuu/Linux combo, but from what I understand, it's not
> userspace. They run uuu right ontop of the kernel without switching
> to user mode (iirc).
nay, it's a userspace program.
On Jun 23, 2005, at 5:53 PM, Howard S wrote:
> Hi there.
>
> I was wondering if you have time for a few questions about uuu? As I
> understand it, uuu currently runs as a userspace program on top of
> linux. Is there sufficient abstraction of the lower levels such that
> linux can eventually be swapped out and uuu run directly on the metal?
>
> What about uuu for Qemu and/or Xen?
as rick mentioned, it ran on metal before it ran on linux. Python
provides oodles of abstraction, so it's pretty easy to port anywhere.
> Will uuu be a "monolithic kernel", and if so, do the shortcomings of
> this approach have any good workarounds, or will future uuu users have
> to concern themselves with recompiline the kernel each time a new
> kernel-level function is needed, as currently can be the case with
> linux?
>
> In light of current developments for GNU/Hurd, and the strengths of L4
> as a microkernel, what about uuu on L4 (which I suppose you could
> already accomplish as uuu on L4Linux, the linux port to L4) or on top
> of GNU/Hurd itself?
Any thinking involving "Unununium" and "kernel" is fruitless. "kernel"
is a word for a part of an OS of a very particular design, where there
is some code that can do anything, and isolated processes which can not.
Unununium is not like that. It has a single address space and everything
runs with full privileges. A capability based design and a VM that does
not allow arbitrary pointer creation will provide isolation when we get
around to implementing it.
> Given the design philosophy of uuu, am I to understand you are
> building a complete system where "functionality" no longer resides
> within the confines of applications, but is in-fact built into the
> system, and is available for use system-wide? If this is the case,
> could uuu be thought of, conceptually, in terms of "abilities" and
> "data", where all things (to the user) are either one or the other?
> You give some interesting and very open-ended ideas about uuu's gui.
> Do you have any sketches or diagrams available to share? I tend to
> believe in the strength of mock-ups and even doing things out on paper
> and ink before spending all the time putting it into code. May I
> recommed this approach (as seen in mockup.org). Even some
> "screenshots" that are really just images put together in GIMP or some
> other image editor would be great in terms of getting feedback and
> testing out new UI concepts. Just my $0.02
Those ideas are far, far down the road.
> Ok. Thanks for reading this. I look forward if and when you chose to
> reply. Best of luck,
>
> Howard S.
|
