Nicolas Roard wrote:
On 5/19/06, Günther Noack <[EMAIL PROTECTED]> wrote:
Hi!
Am 17.05.2006 um 02:39 schrieb Quentin Mathé:
> Feedback welcome :-)
Please don't call Etoile a 'virtual microkernel'. Etoile neither has
a kernel, nor does it provide any functionality that makes it an
operating system. It doesn't do scheduling, it doesn't handle virtual
memory support etc etc. The only thing that *may* in the future be
implemented in Etoile and that in fact is a part of an operating
system, too, is a virtual filesystem. GNOME and KDE both provide you
with these things, and they can hardly be called an operating
system. ;-) Don't set your aims too high!
Well, additionally to the virtual filesystem, there's the whole
notification/name service thing too... But anyway, that's why Quentin
choose "virtual microkernel" and not microkernel :-)
Virtual because indeed it is not an operating system dealing with
memory allocation and scheduling; but it provides the same kind of
services you'd expect from a microkernel..
Anyway that's how I understand it. Interesting concept imho.
True, however this terminology assumes that everybody who is interested
in the project knows what microkernels provide, and quite frankly a lot
of people don't know, especially perhaps the younger crowd, people who
are now around 18-22. Moving forward, I think fewer and fewer people
outside academia are going to be at all intimately familiar with
microkernel design. Something to consider. I actually quite like
Nicolas' much more-clear but longer explanation. Perhaps we could say
"Etoile provides some similar types of services you'd expect from a
microkernel." or something to that effect. Even going on to explain what
those services are very briefly would be better, IMHO.
Many things you say here are in my personal opinion still a bit vague
and at least I didn't find a more precise documentation, although I'm
quite sure some of you thought more about it. For example, you don't
mention why you want to deprecate all those GNUstep classes below...
Agree with that. I can understand some deprecation (NSWorkspace) but
other are quite fuzzy
Right, rationale is often just as important as statement. Otherwise,
things can seem arbitrary to newcomers.
I never heard of Io. Why don't we use Steptalk for scripting? It
looks very promising to me.
Also agree; Quentin love Io, and io is indeed a very cool language :D
but we don't have a working bridge, etc (although probably not too
difficult to do), while we have Steptalk. At least for the Scripting
part, Steptalk looks to me a better choice, it already provides a
proper architecture.
StepTalk is actually language-neutral. The default bundle just happens
to be Smalltalkish. You can write bundles to allow StepTalk to be used
for any language. Perhaps using both the io-objc bridge and also having
an easier-to-use (perhaps? I don't know if this would actually be the
case) StepTalk-Io module might be of value. I know Stefan has always
wanted to see more language modules/bundles for StepTalk, and he's
certainly put a lot of time into it, and also into making it OS X
compatible recently.
Now the point of Quentin is that Io could be used as a main language
to develop application -- not just as a scripting language.
It could certainly be interesting, once the language stabilizes, and it
might actually attract folks who are Io-fiends to the project.
Personally I think it's a bit remote, but well, if we have a bridge, why
not.
I sure would love developing applications mainly in Smalltalk or Io
and only coding few objects in Objective-C / C for performance
reasons..
[snip]
Why do you want to override those? What do you want to improve?
Agree here... we need some justification (although I can see some of
them, it would be much better to write it down. Possibly in a specific
document).
A corresponding document and/or subsection with matching section numbers
for rationales would be a good idea, but if you can keep them somewhat
brief, why not just keep them inline in the document?
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
