Merger between AmigaOne and Pegasos dev teams

[uncharted]

downix wrote:
@uncharted

Egads, you really don't know how OS's work, do you?

Then explain it to me.

-Edit-

I hope that just wasn't a lame excuse to get around my statements.

[Kronos]

@downix

Sorry, but bbrv did do just that right here some months ago.

Wether that was honest, or just a PR-trick to show how thin Hyperion's pro-dongle
arguments were is beyond my knowledge, but thta offer was made.

[downix]

@uncharted

No, it's that I really am not the ideal person to explain OS design theory to anyone.  While I understand it, explaining it I am not very good at.  But let me try.

The fundimental problem I see here is that you're thinking too much in the AmigaOS mindset on how an OS has to run.  The comments about not being able to use Quark from within the ABox demonstrated this to me.  Of *COURSE* apps within the ABox can use Quark.  Otherwise, as Quark is the kernel of the system, nothing would run!  Can you directly access Quark, no, because it exists outside of the ABox, but you can use it.  How, you might ask?  Simple, you have a window into the lower-end of the system, namely the HAL and reimplimented exec.library.  The new functions that can be implimented inside of the ABox without breaking the API's can be access this way, through this window.  That way, since there is a barrier, you cannot kill the whole system with some dumb random crash.  It is the only proven method of ensuring a stable environment without destroying compatability.  It is how MacOS, OS/2, WinNT/2k/XP all do it.  

In a way, AmigaOS's own multitasking strength is now it's weakness.  Compare to Atari's TOS, single-tasking OS.  AmigaOS, one cannot add MP, VM, etc without breaking the API's and causing apps to not run because the apps are engineered to look for other applications, libraries, modules, datatypes, etc and just fetch them out of memory directly.  A full MP environment requires a program to ask the OS for these components, rather than just do it on their own.  This means, if one were to add full MP, one would break this ability, thereby not allowing the application to run at all.  Atari's TOS, by comparison, is little more than DOS, a single-tasking, no-library OS.  WYSIWYG.  This allowed some smart fellas to create the MiNT kernel, which creates a virtual-machine for each application, allowing one to run many TOS apps simultaneously, all with full MP.  However, this turns into Windows, with monolithic apps, and is very ugly in the long term.  None of the sharing and beauty of AmigaOS.  

man, that was one long rant.  But did any of that make sence to you?

[uncharted]

downix wrote:

man, that was one long rant.  But did any of that make sence to you?

Yes and no.

Firstly I think you misunderstood what I meant about using Quark (Likewise I'm not that great at explaining what I mean all the time) So I knew most of it anyway.  I also know the problems of MP and message passing in AmigaOS, and I know that you can't just shove MP on willy nilly.

The window idea is something I hadn't heard of before (although isn't the HAL what the kernal sits on?) in MorphOS what features of Quark would this allow you to use in the ABox?

[downix]

@uncharted

Right now not much, as Quark's QBox is not fully developed.  But, the VM I mentioned is one example of how an ABox app can access a Quark feature.

But, as more and more functions get added to the QBox, more and more things the ABox gets to exploit without breaking the app.

Also, I'd point out how with Quark one will be gaining such things as transparent networking.  Imagine a single ABox running on 4 or 5 computers.

So, you get a choice.  Pick an OS with new functions you can't use, or one without new functions, but a way to use them as they are added.

[uncharted]

downix wrote:
@uncharted

Right now not much, as Quark's QBox is not fully developed.  But, the VM I mentioned is one example of how an ABox app can access a Quark feature.

But, as more and more functions get added to the QBox, more and more things the ABox gets to exploit without breaking the app.

Also, I'd point out how with Quark one will be gaining such things as transparent networking.  Imagine a single ABox running on 4 or 5 computers.

So, you get a choice.  Pick an OS with new functions you can't use, or one without new functions, but a way to use them as they are added.

Thanks for the answer.

Here's a question I've been trying to get answered for a while now.  How will things change in structure and usage once the QBox gets introduced fully?

Will it be like OS X where everything changes, but the old stuff is kept to one side and is called upon when needed (classic) or will it all just fit together with the abox OS3.1 reimplented stuff.

[downix]

@uncharted

From what I understand, it will be a slow migration from ABox to QBox.  For a time, both will be running side-by-side.  But in the end, the ABox material will be moved to one side in logic, but not in function.  You don't need to have a seperate desktop or window just for ABox functions, from a user perspective it will appear to be one and the same.

Unlike the MacOS to OSX transition, MorphOS already has a next-generation desktop, Ambient, which is built using MUI and CyberGFX directly.  Both MUI and CyberGFX are good canidates for moving to QBox, once the other underlying systems are finished.  This means that Ambient, as well, would be migrating.  So unlike OS X, where a whole new destop has to be designed, the same desktop will be present from one side of the migration to the other. As a result, we're not talking some grand-scale change, like the jump from MacOS 9 to Mac OSX here.  This is a far more gradual shift, where you migrate over time from one to the other, without your apps being any the wiser.