Thinking to change to the dark side (blue)

[Van_M]

Well I have a strange feeling that if AOS4 doesn't get released for Pegasos 1-2 then MorphOS will be equiped with a transparent compatibility layer that will enable API-friendly AOS4 apps to run. Something in the sense of WINE for Linux... API copyrighting isn't possible, right?


--EDIT-- More like the current A/Box will be expanded so it will be able to run AOS4/PPC compiled programs apart from AOS3.9/68K ones.

[Kronos]

@Van_M

How many OS4-only apps are there ? (or better will be)

AudioEvolution, some gameports from Hyperion, and ?

Don't see that someone from the MOS-team would waste lots of time for that.

[Van_M]

-->How many OS4-only apps are there ? (or better will be)

well I guess, in a couple of years after its release it will have equal amount of apps as MorphOS. I also think, doing some further work on the Abox wouldn't be such a terrible waste of time. The result would be an all-in-one unified solution for anyone willing to return in the amiga community (if anyone is going to).

[Kronos]

@Van_M

It doesn't matter how many apps there will be for OS4, but how many
that are ONLY available for OS4, and sofar the ones I listed are the
only ones announced that way (not counting small SW-tools and suchlike).

It is certainly better to invest that time in something looking forward.

[ksk]

@Warface

>On the contrary, it seems from the rate of development it will be quite some time before OS4 can catch up -

So you say again.

Show me the list of things there is in the MOS(for advanced users)1.4 that is not available in the AOS4.0 internal beta?

Or in 1.5.

MOS does have advantage in maturity, on many parts, though.

UPDATE: Now I spotted your mention about those MOS things.
"Mainly I think about the 24 bit internal system from ground up, and their 3D system, of which ATM only the Warp3D wrapper is publicly available."

That is not much. Also AOS4.0 will have 3D.
The old WB might be a handicap. Especially if Ambient is more solid&stable.

> and MorphOS developers ain't fiddling their fingers neither.

But I think it is still lacking things that are available on AOS3.9.
Things that AOS4 was/is going to have immediately at the launch.



>Care to tell us what were the disadvantages of the MOS strategy compared to the AOS4 strategy?

It was y2001-y2002 back then.

- MOS and Peg were being done by the same company (products tied together)
- MOS was heading towards Abox instead of Qbox & own merits
- AOS was being done by a SW-only company, targetted to multiple HW platforms (there was HW agreements even)
- AOS had roadmap forward instead of sidestepping via some other OS emulation.

Not much have changed since...




Except that the blue camp got their own "information" minister & huge amount of EMPTY promises.
(at this rate they catch up with AInc {bleep} amount)

MOS have almost finished it's sidestep. But the next step is unclear. Will it be another sidestep to AOS4 emulation?

AOS4 has got new features described later in the roadmap and lost the DE part of it. And it's yet to be released...

[ksk]

@Kronos
&
@Van_M

It is good to see that most applications will be available for both/all Amiga-like platforms.

(even though fanatics tried/try to insist otherwise)

It's superb that application developers seem to be above all the dirt.

I could (pay someone to) kiss their sweet asses. Any volunteers?  :lol:

[magnetic]

I'd like to point out that every customer who ordered a peg for the first time got their "pre-order" pegasos. Genesi is very committed to customer satisfaction. They have an irc channel for Morphos support where the actual developers give support. Sometimes you can even talk directly with bbrv the owners of the company. The community has many helpful people and there is the nice Morphzone website with tons of information. This is phenomenal support.
  It took me 3 weeks to get my pegasos1 a year ago but I didnt mind the wait. Especially since it was just over $300 and I got a bunch of great FREE software. Pro Station Audio, MorphED, Birdieshoot, Feeble Files, Software Tycoon, Fx Paint Lite, Image Fx lite, etc etc..  There are also tons of MorphOS NAtive PPC software and ports are coming weekly.

  This whole foolishness of "the dark side" needs to stop. The MorphOS community is what the Amiga community used to be in the late 80s. Fun, accepting, and creative. Every amiga person who gets a Pegasos LOVES it. Not only that, but there is tremendous Linux support. Unlike on the AmigaOne which has lousy support all around and no OS in sight.
Also, all updates of the MOS operating system are FREE.

With a Pegasos2 you have everything you need for ANY computing application (except for Video Editing which is being worked on) I use my PEgasos2 G4 with MorphOS for Amiga compatiblity, and MOS native apps - I use Linux for cool PPC Linux apps as well as running Open Office so I can view and use MicroSoft Word docs, PowerPoint Presentations, Excel spreadsheets and more - I also have Mac OSX Panther running through Mac On Linux and this allows me to also use all the OSX Apps (again with M$ apps if you'd like) I use Internet Explorer, Mac sound apps, Games, etc...  

An all in one computer. I built it for less than $900. (Almost the cost of the A1 board Alone) That is pretty impressive and the community is very supportive and friendly.  Genesi and Bill Buck stand by their products.

Now, Hyperion is doing a stand up job with OS4 but its a monumental task. I have a lot of respect for these guys, but the reality is they will have a hard time catching Morphos. Also, it is common knowledge that the Pegasos2 is a much better technology than the Amiga 1 board.

As an Amigan would you rather have a board that was designed by Phase 5 Engineers (who brought PPC to the Amiga) or by some overseas company (MAI - Teron Amiga 1) with faulty hardware?  This is the facts, not FUD. On the A1 with Articia there are documented DMA problems, the sound doesnt work, and other issues. Of course, this is expected in 1st generation hardware and its an OK reference platform, but like the OS4 vs MOS they have a long way to go to catch PEgasos..

magnetic


 :-)

[ksk]

@-D-
>> Also AOS users say that application crashes are often not able to take the system down.
>This is also common with MOS/AOS 1-3.x, depends on how the app bombs whether or not it crashes the OS completely.

Ofcourse, but if AOS4.0 memory protection for SW code & unused memory is working (& the automatic stack enlargement). The difference to AOS3.x stability should be big.

Actually... I think I have not heard of such things for MOS yet. Perhaps they are not planned because abox & new apps will be boxed in a few years time???


(the biggest stability threat to AOS is that it is young since it rebirth, even though it contains some well tested legacy stuff)

[blubbe]

But I think it is still lacking things that are available on AOS3.9.
Things that AOS4 was/is going to have immediately at the launch.

ARexx, Installer, TCP/IP, .. ›*HOPEFULLY in 1.5*

- MOS and Peg were being done by the same company (products tied together)
- MOS was heading towards Abox instead of Qbox & own merits
- AOS was being done by a SW-only company, targetted to multiple HW platforms (there was HW agreements even)
- AOS had roadmap forward instead of sidestepping via some other OS emulation.

Not much have changed since...

1. So ?
2. Whaat ?
3. Whaat ?
4. Whaat ?

Somehow you seem Pro-OS4 but your listed resons just dont
expalin why.

[KennyR]

ksk, AmigaOS4 will not have the memory protection you seem to expect. I've never used it, and how do I know? Am I spreading FUD? No. It's a matter of the Amiga API. And the fact that it uses a shared memory address space.

OS4 keeps to the Amiga API for legacy. It has to, or it would just be a new OS with nothing in common but the name. But the downside of this is that real memory protection cannot be implemented, because AmigaOS was never designed for it. Amiga tasks and processes can be redesigned to care for MP, but in doing so it changes their structure and destroys compatibility. Sure you could use the MMU to hard-protect every task, and have linked lists track every resource, but the nature of shared addresses space (virtual or not) makes the overhead of this just too much to be practical.

QBox and Windows both took the sandboxing away to get around this problem (the 16 bit Windows layer *still* has no real MP). OS4 did not. Whatever memory protection OS4 will have, don't expect it to give you the peace of mind using bad apps under Linux or Windows will give you. It's just impossible to do without abstraction - sandboxing. OS4, like MorphOS ABox and AROS, will always suffer the "Bad app brings down whole system problem". It's a conceptual impossibility to prevent it, although you can lessen its impact in certain ways.

[matt3k]

I purchased a PegII G4.  I really enjoy using it.  

I pre-ordered though ultraspec, they were terrific to work with.  They did not charge my card until after the board was shipped.

It does most of the items I needed very well - runs checkitout, ibrowse, miami, addresser, sbase, final writer, turbocalc, simplemail.

The only program I have not yet been able to get to work is Organizer.


Enjoy.

Matt

[blubbe]

Ofcourse, but if AOS4.0 memory protection for SW code & unused memory is working (& the automatic stack enlargement). The difference to AOS3.x stability should be big.

Protecting unused memory isnt improving stability, but is
nice for debugging.

Stackenlargement would possibly be able to get around
a few badly programmed pieces of code.

-

But sure, MOS protects unused mem and core OS libraries.

[ksk]

@magnetic
"no OS in sight."

 :-o  Perhaps an overstatement when some already have it.

But a load of valid points.
It's easy to believe that the support is a little bit easier to get. (also when you make your own HW you know how to make it work, instead of trying to learn a foreign HW)

Is your kind of use currently possible without adding missing pieces from AOS3.x?

(IIRC half a year ago AREXX and some other stuff had to added)

[ksk]

@blubbe

>Protecting unused memory isnt improving stability,

Yes it does.
The app with the "fuzzypointer" is more probably detected & killed before it messes up the memory of other apps/OS.

>but is nice for debugging.

Yes it is.
That also improves general stability.

>Stackenlargement would possibly be able to get around
a few badly programmed pieces of code.

According to Hyperion that's very common reason for SW crash. Time will tell how it affects.

>But sure, MOS protects unused mem and core OS libraries.

Nice. And nice to know now. ;-)


+++++++++++++
>>1.- MOS and Peg were being done by the same company (products tied together)
>>2.- MOS was heading towards Abox instead of Qbox & own merits
>>3.- AOS was being done by a SW-only company, targetted to multiple HW platforms (there was HW agreements even)
>>4.- AOS had roadmap forward instead of sidestepping via some other OS emulation.

>1. So ?
No competition & HW alternatives. High prices. Risky. See x86 success vs apple success ...
>2. Whaat ?
Well it was. Initially I thought they were building memoryprotected boxed system (I believed the hype, stupid me). Instead they were building Abox and everything was being put in it. MOS was "just" going to grab AOS market. HUGE disappointment to me.
>3. Whaat ?
See 1.
>4. Whaat ?
It was that way. Then. IMO, more appealing. The AOS I know & love being developed forward. Connection to "world fastest growing industry" even, as those fellow work mates @ Linköping said.

>Somehow you seem Pro-OS4 but your listed resons just dont
expalin why.

There's really no use of explaining or was there? People see these things differently. Some do not see (not meaning any person particularly).

[ksk]

@KennyR
>AmigaOS4 will not have the memory protection you seem to expect.

It does/will.

>I've never used it, and how do I know? Am I spreading FUD?

Yes. Or you simply did not know. Believe in religion?

>But the downside of this is that real memory protection cannot be implemented, because AmigaOS was never designed for it.

The full memory protection can not be implemented.
But partial can.

AOS apps need to be able to access other apps memory for fast data transfers.

And AOS apps need to have access to some OS memory areas.

I think there is no other restrictions.

In a result, those things that I mentioned can be protected.

>Amiga tasks and processes can be redesigned to care for MP, but in doing so it changes their structure and destroys compatibility.

Someday (after AOS4.1?) it might be possible to have more protection for new apps. Even in that case old 3.x apps might need to be recompiled / be run in a box.

> Sure you could use the MMU to hard-protect every task, and have linked lists track every resource, but the nature of shared addresses space (virtual or not) makes the overhead of this just too much to be practical.

Your previus information vas not valid. But that last one (above) is new to me. Hmmm... I do not figure yet how it would be any harder than in any other resource tracked systems.

Detailed explanation somewhere?

>QBox and Windows both took the sandboxing away to get around this problem

We all know how "fast" Windows/Linux is. QNX & BeOS are good examples that memory protection / boxing does not necessarily slow down the system.  (I think, @ work & so far it kills the application, we have extremely tight realtime requirements...)

>(the 16 bit Windows layer *still* has no real MP).

Same for current MOS.  (yes, I'm teasing)

>OS4 did not. .... although you can lessen its impact in certain ways.

Right!
That's what I said. I think. ;-)

Did you know MOS already had similar (not identical) protection than AOS4?
I did not. Now we both know. ;-)

[Georg]

Protecting unused memory isnt improving stability, but is nice for debugging.

At least with standard Exec Memory Lists unused/free memory is not really completely unused. Because the unused memory chunks are linked together through MemChunk structs. So code like this:

  Forbid();
  FreeMem(mem,100);
  *mem = something;
  Permit();

can cause trouble (it's bad/stupid/ugly anyway). The Forbid() protection does lock other memory allocations, that's true, but after the FreeMem() the first 8 bytes at address might be in use for the unused-mem-chunk-linking.