Merger between AmigaOne and Pegasos dev teams

[downix]

You'd just have the Peg dev team, as the A1 is a licensed board, not designed by Eyetech itself.

[downix]

@Russ

since when does Hyperion have anything to do with the AmigaONE nor Pegasos?  Nor have anything to offer in light of either platform.

Please keep the arguement to the topic at hand, which is A1 and Pegasos.

[downix]

@HMetal

And what does that have to do with the price of tea in china.

The topic clearly says Pegasos and AmigaONE, not "pick on your favorite developer."

Heck, I've never seen a Pegasos channel.

[downix]

@HMetal

ya know you could have asked.

I run AmiFTPd on my Peggy with only minor problems.  Speed-wise it's fine, but Miami keeps having the TCP stack lock-up when I run it.

[downix]

@BlackMonk

Nothing to flame over, you stated an opinion, and honestly I do agree with it.

I think part of the problem is paranoia, that or jealousy.  One group is jealous over the other one, and that jealousy makes them blind to the common insterest of the community.

From my angle (mind you, I work for Genesi) I see resistance, and fear, regarding our products.  Resistance because we lack the name.  Fear because, from my observation and opinion, we have the superior product.  

However, I see it from the other viewpoint as well.  Genesi is the upstart, the new kid on the block.  It is taking away mindshare and loyalty from AInc's solutions.  From their angle, this is a low-blow, and cheating ones way to the top.  Add on top of it announcments that hurt your products or those of your licensees.  It seems Genesi is going for an all-out war, so you retaliate in kind.  

But this schism goes deeper than just Genesi/AInc.  I saw it during the GateMiga days, with competing vendors kept pushing their own, proprietory API's on the market.  Over time, these API's consolidated into 2 groups, the MorphOS and the AmigaOS4 camps.  MorphOS gained the CyberGFX, MUI, PowerUP, AROS strengths while AOS4 gained the Picasso96, ReAction/ClassAct, WarpUP and AmigaOS strengths.  This polarization of the community is difficult to heal, and is only a direct result of ignorance by those that have held the trademark in the past to define a STANDARD.  This resulted in a splitting of the community, and the situation we have today, with 2 OS's, 2 motherboards, 2 solutions to everything.

I'd point out, an attempt to correct this has begun, with the openamiga project at:  http://www.openamiga.org

If you really want to see this community heal, that's where to look, in my personal opinion.

[downix]

uncharted wrote:

downix wrote:
From my angle (mind you, I work for Genesi) I see resistance, and fear, regarding our products.  Resistance because we lack the name.  Fear because, from my observation and opinion, we have the superior product.  

Don't agree with this totally, while there are people out there who may be like this, I don't think it's the main bulk of people.  From what I have seen of your postings you have totally dismissed AmigaOS out of hand, I don't think you have been objective about it (comments about the new amidock spring to mind).  I haven't had chance to try out OS 4 yet, but I don't think from experience that MOS is the superior product (Cue 10 of the most hardcore to tell me how wrong I am)

So, have I dismissed it?  Yes, I have.  Not as an OS, but as a step forward, much like WinME.  Even the screenshots and data given show nothing of the necessary evolution, nor even the framework *for* an evolution of the platform.  It is a very tough world out there, and if AOS4 is not ready to tackle MacOS X or Windows XP, it will not survive.

This industry is brutal, it is only a matter of time before both AOS4 and MOS have to go head to head against companies with billion dollar budgets and a userbase that makes ours look like a mere speck.  What gives AOS4 or MOS a chance here is their sheer stubborness and willingness to rip into each other.  This guarantees that at least one, if not both, will be strong enough to at least stand a chance against the other predators out there.  And possibly grow into giants themselves.

I think, in the end, AmigaOS's biggest problem is overoptimism.  They misjudged timelines, they misjudged the marketplace, they misjudged their customers.  All due to overoptimistic feelings and lack of business skill.  This, more than anything, makes me dismiss it as the solution for the market.  Unless Amiga gains some real management, this will remain so.

As for OpenAmiga, I stated my personal opinion, as well as other Genesi employees have done.  I would note, the "a joke" comment was with the discussion of 68k binaries, not the idea itself.

[downix]

@uncharted

Huh?  Where the heck are you getting this stuff on the OS's design?  BOTH OS's are using a sandbox technique here.  The only difference is that one seperates the new MP-enabled kernel from the old non-MP kernel.  This way, should a non-MP app kill itself, you don't loose the entire system, just the non-MP protected section.

-EDIT-
And MOS has VM.

[downix]

uncharted wrote:

downix wrote:
@uncharted

Huh?  Where the heck are you getting this stuff on the OS's design?  BOTH OS's are using a sandbox technique here.  The only difference is that one seperates the new MP-enabled kernel from the old non-MP kernel.  This way, should a non-MP app kill itself, you don't loose the entire system, just the non-MP protected section.

The OS 4 feature list it explains that it does not use a Sandbox approach.  I mean before you started slagging it off you did actually READ the information available on it didn't you?

I read Ben Hermans latest statements on AOS4, and he said clearly that to seperate new-API from old-API they will be using a sandbox.

And, yes, I have read the AOS4 feature list.  I dissected it quite completely, and it meshes with what Mr. Hermans said, a sandbox is needed for future roles.

So you are saying that I can write an application for MOS that makes use of all the advanced features of Quark including MP?
That's either great news or total rubbish.

Nope, but you can't make an application that can use all of the advanced features of ExecSG either.  So no difference here.

-EDIT-
And MOS has VM.

Available to the applications written for ABox?

Yes.  However, like in QNX, with MOS the VM is added using a system module, so apps can only make use of VM if they are designed to.

Having run such a system with QNX, I know very well how nice that is, not having the OS decide when to allocate VM but instead the app decide on exactly how much VM it needs.  Gives me far more control over the applications that way.

-edit-
Got some clarification about MOS's VM system.  It is currently in internal beta, but not a high priority for inclusion into the public release.  

[downix]

@Russ

Made an offer, when?  IIRC, it was Genesi that made the offer, not Hyperion.

[downix]

@uncharted

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

[downix]

But somehow I don't think the board was what Nate was refering to, but when Genesi offered to sell Pegasos bundled with OS4, just not with an licence from Ainc or a dongle.

Genesi never offered such a deal, so quit spreading it so thick.

I was refering only to the times a board was offered to Hyperion, and nothing more.

[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?

[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.

[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.