One unified OS for the future?

[itix]

And another reply moved to this thread.

That's all I'll say, otherwise it'll all go red vs. blue again - but that osnews article is misleading because for one thing MOS devs had more information than AmigaOS devs about the Peg-II, and also because the osnews article is measuring speed differences between MorphOS 2.3 and AmigaOS 4.1 beta - it doesn't take a rocket surgeon to know that comparing a beta to a mature 4-year old product is a little unfair.

Spirantho is wrong. If they are selling beta OS to consumers that is the product then they are selling beta OS to consumer. Beta OS is what you get.

Besides, there is no hidden information about Pegasos 2. Its hardware is documented and it is available to developers.

[itix]

Not being an NG user or a programmer, I'm wondering, how hard is it to code an application that works under both OS4/MorphOS? That I see different versions for things on Aminet is about the most knowledge I have on the subject. From what I understand, they both can run non hardware-banging 3.1 compatible applications natively, correct? And both can run native Amiga hardware-banging code through some form of JIT compiler or built-in UAE, correct? So beyond that, how difficult is it to write things to run on both?

If you use OS 3.1 API then you are source compatible with each other. If you compile to 68k target you are binary compatible with each other.

But problem is that you cant use any new stuff.

[itix]

There are too many differences of opinions on which direction is the best for any one of those choices to be considered the ONLY right choice for all of us.  Each choice has it's own life now, it's own user base (though many users are involved in more than one of these choices), it's own developers, and it's own vision for the future.

MorphOS and AmigaOs 4 lack common interests.

 - MUI 4 / Reaction
 - CGX / P96
 - Ambient / Workbench
 - Netstack / Roadshow
 - Poseidon / other

And many more if we go deeper.

AHI is probably only one of common interest.

[itix]

My point was that comparing a mature OS of several years with a beta version of another OS isn't a fair benchmark of speed. I don't think I was wrong.

Soon it should be possible to compare AmigaOs 4.1.7 against MorphOS 3.7 on Pegasos 2 hardware and later AmigaOS 4.1.7 against MorphOS 3.8 on SAM460.

Plus there are some very low level bits of documentation that the AmigaOS devs did not have access to, which the MorphOS devs did.

Care to mention what bits of documentation Hyperion did not have access to?

[itix]

Yes, the Sam460 will be a much fairer comparison than the Peg 2.

Funny that you say that because MorphOS 3.8 will be the first version to support SAM460 while AmigaOS 4 has supported SAM460 several years now.

;-)

I believe that bPlan kept some of the really low level stuff to themselves. Just did a quick Google and found this, for example:

http://morph.zone/modules/newbb_plus/viewtopic.php?forum=11&topic_id=4548&post_id=42844&viewmode=flat&sortorder=0&showonepost=1

That thread is just talking about twiddling the timings, nothing to do with AmigaOS - but the important thing is that it illustrates that bPlan did keep that sort of info to themselves.

Users dont need such kind of information. And OS developers dont either if they want to stay compatible.

[itix]

As long as the morphos devs have full access to the hardware details, then once MorphOs has reached a mature state on the 460, then I suspect we'll find there's very little difference.

Are you sure? Are you sure MorphOS is not faster on some task and OS4 is not faster on some other tasks?

Some benchmarks like RAM disk speed is not necessarily always tied to underlying hardware but to algorithms used in RAM disk implementation.

Of course before that state is true, then yes, MorphOS may well appear slower and that wouldn't be a fair comparison either. Look at G5 benchmarks on MorphOS now compared to their first beta releases, there's quite a difference.

It would be fair comparison because it tells exactly what you get. It is important to users so they can hold their buying decision if it turns out that support is not mature enough yet.

Mods: this discussion should be moved to its own thread.

[itix]

As for the review being fair - yes, it was a fair indication of the state of AmigaOS 4.1 on the Pegasos II at that time, but in no way should it be used - several years later - to say that because of that AmigaOS as an OS is slower than MorphOS as an OS. All the review proves is that a pre-release beta of AmigaOS is slower than the full release of MorphOS at that time on that hardware.

Funny that you claim Hyperion was selling pre-release beta to their customers. They never advertised it as such.

But yes, it nly reviews state of affairs in year 2009. Today if AmigaOS 4.1 FE (not released yet) was compared to MorphOS 3.7 (released) it could be even greater victory for MorphOS... ;-) I mean, it is also possibility, isnt it?

[itix]

The OSNews article was done on the beta of AmigaOS 4.1 for the Pegasos II:

Absolutely, it could be. But I still say we need to wait until we have a fully open platform and a mature version of each OS on that platform before we can possibly make any decisions.

The OS news was repeating wrong information from French article (http://obligement.free.fr/articles/amigaos41_vs_morphos23.php) where it initially claimed that AmigaOS 4.1 for Pegasos 2 is beta. This was corrected later:

Contrairement à ce que j'avais écrit dans un premier temps, l'AmigaOS 4.1 sur Pegasos II n'est pas en version bêta. Il n'en demeure pas moins qu'il s'agit de la première version de ce système pour Pegasos II. Est-ce l'AmigaOS 4.x s'améliorera sur ce matériel%&$#?@!? Peut-être ou peut-être pas. En attendant, il reste moins optimisé que MorphOS. Enfin, on peut noter que la performance de certains tests est plus due à la façon dont a été compilé le logiciel qu'au système lui-même.

So it was full release vs full release. I know that Hyperion fixed slow disk I/O in later update, though.

[itix]

MUI is "standard" for old users, but for returning people like myself when a program refuses to run because it wants xyz file/program as a basis, its not as apparent where and how to go about it.

I wonder how you got your Amiga online, because...

1) AmigaOS 3.1 comes without TCP/IP stack
2) AmigaOS 3.9 comes with TCP/IP stack but it is on CD-ROM

Just wondering

[itix]

Maybe he is not writing this on an Amiga?

I dont think AmiStore is that useful without internet

[itix]

Probably not a simple question to answer, but in your estimation, how many MUI applications depend on custom classes that are uniquely defined within that application (i.e. by runtime subclassing/extension in the BOOPSI fashion) as opposed to reusing existing shared classes?

Many old MUI applications depend on NList.mcc custom class because it has neat features (like horizontal scroll bar) to developers missing from the original MUI 3.8 List.mui class. Probably another is TextEditor.mcc/TextInput.mcc because standard MUI 3.8 also lacks text editor capabilities.

But you can use NList.mcc and List.mui (standard) interchangeably -- if NList.mcc is not installed application can fallback to List.mui. If TextEditor.mcc is missing you can fill blank space with text box telling how to download and install one. But better would be provide all in one. It really annoys me if I have to download dozen of libs and classes.

But before any GadTools or MUI version I would do market research how many potential users there could be and what is their typical configuration. Kinda pointless to have stripped down version if there are next to none products they could run on their system.

[itix]

Edited out this quote of the private conversation information I should not have paraphrased out of context, please forgive my mistake.  AmigaDave

Well, no. Now it has been several years when I had Pegasos 2 and my memory is getting vague on these matters but there was great debate amongst users which configuration, one used by Linux or one used by MorphOS was better.

I cant remember which way around it was but IIRC in MorphOS 64-bit reads and writes were faster than in Linux but at expense of 32-bit read/writes (those are faster in Linux). Or was it vice versa, I cant remember anymore.

But it is strategy chosen by the MorphOS team and it is debatable which one is better. Linux or OS4 performance is not crippled in this regard.

Edited out this quote of the private conversation information I should  not have paraphrased out of context, please forgive my mistake.   AmigaDave

Of course because OS 4 was slower. If benchmarks were done on SAM460 or other platform there is no guarantee they would be using same configuration even on same hardware.

Spirantho mentioned that he perceives an "End of the Road" for MorphOS development on PPC hardware, when they have completed support for the last few Mac PPC hardware choices that are not currently supported.

That is funny statement.

This is one area where I think that A-Eon and AmigaKit have hit a "home-run".  They see the value of now focusing their efforts on supporting the creation of more and better software to run on AmigaOS4.x, is their most important task.  Having the software you need or want is what makes using any computer useful.

I hope that the MorphOS Dev. Team members will soon have more time to work on new, or newly ported software.  More and better content/software applications and games, will probably do more for getting people excited and interested in using their Amiga, and/or Amiga inspired systems, than anything else.

Uhm, but this is what MorphOS team is doing and what Hyperion is not doing. There is bunch of useful software developed or ported by the MorphOS team, starting from Odyssey web browser to SDL ports. Sketch, Transfer, Scandal, Scribble, RemoteShell, Jalapeno, Jukebox or VPDF are examples from the MorphOS ISO. And dozens of ported or new libraries making porting and writing software easier. And there is new and ported software released externally.

[itix]

Just to clarify - what I meant is that once all the Mac PPC models are supported, they're going to be stuck with increasingly ageing hardware which is going to get more and more obsolete. They're going to need to change to another ISA such as x86 or ARM if they're going to stay at all current - I don't think there can be any argument to that.
If they don't, then in the future AmigaOS will be using multi-GHz multi-core low-power brand new hardware, AROS will be using brand new low-cost x86 hardware, and MorphOS will be stuck to ancient Mac Behemoths without any support for the current technologies - that would be a bad thing for MorphOS.

That is going to take several years and there is always possibility that MorphOS is ported to some future AmigaOne hardware or gets ported to different CPU arch.

I just found it funny because there is no future for PowerPC on desktops. If A-eon calls it a day it is the end of AmigaOS 4.

[itix]

@OlafS3

The other problem with abstraction layers like that (or even bytecodes like .NET) is that of speed. We will always suffer from a lack of speed compared to Windows machines, and as programs get heavier and heavier in their resources it's going to become more and more impractical. We need to grab as much power out of our "Amiga" machines (whatever they are) - the primary advantage we have is that we have much more lightweight operating systems. If we go the way of bytecode and abstractions we lose that strength entirely.

If not losing on speed then we are losing on application development. It is so much faster to type programs in C# using .NET than using relatively low level languages like C. When C programmer is working on 0.7 beta C# programmer is already finalizing new features to forthcoming 3.1 release.

And speed is not so much important anymore when we are at 1GHz+ range. Most of time CPU is running almost idle wasting its potential.

We are already using bytecode in sense how we run 68k programs on PPC and it is fast enough. We just dont get advantages of .NET with it.

[itix]

It depends on what you want to do.
If you want to encode (or decode) video, play MAME, that sort of thing, then using bytecode would be impossible.
I know what you mean, though - for less demanding applications, high level programming languages like C# or Java can speed up the writing massively - but as usual different applications have different requirements, so we can't force people to use high-level code as it could be disastrous (especially for things like device drivers).

Bytecode is not solution to everything but you could write a MP3 encoder in C# and use encoder libraries written in C.