One unified OS for the future?

[guest11527]

The AmigaOS devs aren't stupid. They don't just change and break APIs for no reason - it's far too much work to do unless they need to.
As a maintainer of an OS, the first thing you need to do is to take the code you're given (in this case a patchwork of M68K and PPC 10 year old OS3 code). Then you need to clean it up and lay the groundwork for the future of the OS (in this case SMP and memory protection). Only then can you actually start on the new technologies themselves. That's exactly what Hyperion have been doing.

Certainly, and that's - from the perspective of a developer - also the correct thing to do, i.e. for the purpose of a clear Os design. I can fully appreciate that. However, and that's a big "however", this seems to happen (as I observe it, as an outsider) without really having done a requirements analysis. Hence, what is the end product supposed to do, which problems is it supposed to solve, and who wants to buy that for which purpose.

When it comes to those questions, I always keep scratching my head. Actually, not for AmigaOs 4.x itself, but also for MOS.

It seems to me that the two camps are here developing an Os for the pure purpose of developing an Os. This makes probably a nice hobby, but it does not sound like a sustainable business strategy. If it's not a business, then what's the problem of giving the Os away to those that want to play with it as a hobby in first place? Why do I need to buy into more obsolete hardware for that? I don't understand...

[zylesea]

If and when MorphOS starts work on SMP (have they done so already? I really don't know) they too will have to change the API somewhat, but I just wish it would be with changes that are compatible with AmigaOS's API changes. Not going to happen, though, I suspect....

SMP and other goodies breaking up compability will probably come whitn an ISA switch. While AOS4.x tries a slow transition (we'll see how well that will work out), MorphOS will do that with a hard cut.

[spirantho]

That's another question - is MorphOS with a new SMP API, a new ISA and no binary compatibility with 68k Amiga or PPC MorphOS actually MorphOS at all? Or is it another OS by the same developers?

It will be interesting to see what happens for both OSes, I think! Anybody doing an API switch is going to have to be careful (particularly if they go x86) not to just reinvent the good work the AROS devs have done.

[Duce]

It's a preference thing.  I own both MOS and OS4 machines, and love both OS's for what they offer.

But there's still some things I am more comfortable interface and user experience wise with OS4 vs. MOS, and all the skinning in the world won't change that.  Think of it as how people prefer their morning breakfast rituals - some people take their coffee with cream and sugar, some like it piping hot and entirely black.  I'm just more comfortable with OS4, but you couldn't pry my MOS boxes out of my cold, dead hands.

OS4 is not a better OS than MOS, or vice versa.  Both are great experiences, but you'll likely prefer one over the other for strictly proprietary and personal reasons.  It's the same reason why one person will buy a Chevy over a Ford, etc.  It's a hobby, and it's a fools game to try and compare a hobby OS with a mainstream OS in terms of functionality.  I for one am thankful that in the Amiga scene we have all the choice in OS's that we do.

I've not tried AROS for some time, but I hope it gets to the point where I can build a new PC and simply install AROS on the machine.  As it sits, I lost a lot of interest in AROS when I had to build specific hardware builds to run it optimally.  I built an AROS machine up, then just converted it to an Amithlon machine.  That in itself doesn't make AROS a poor choice, it just wasn't for me, I suppose.  I hope in the future AROS (native, non hosted) can support pretty much any commodity hardware, but as it sits I can't even begin to consider running it on this machine - it doesn't work at all on this particular hardware, but the devs are covering a lot of ground rapidly with the hardware support, so I'm expecting very good things out of AROS over time.  It is quite a chore for them to try and support all commodity hardware, no doubt.  That being said, I'm admittedly and vehemently against "hosted" OS experiences, and I am aware that the hosted versions support a lot more hardware than native does.

[danwood]

I think the difficulty that's being faced is that AmigaOS has to change the API, whereas MorphOS doesn't. AmigaOS's long term goal is SMP and memory protection. That's a heck of an undertaking, and where a load of work has gone already (that's not been noticed because it's invisible to the end user). As MorphOS has been concentrating on single-core hardware, I haven't seen it making the groundwork towards SMP - which would require changing the API (like AmigaOS has done). SMP will never work on AmigaOS unless the API-changing groundwork is done first.

If and when MorphOS starts work on SMP (have they done so already? I really don't know) they too will have to change the API somewhat, but I just wish it would be with changes that are compatible with AmigaOS's API changes. Not going to happen, though, I suspect....

I must admit, I'll be highly impressed with Hyperion if they can successfully implement smp and memory protection while remaining compatible to current apps.

There are those who claim it's impossible, and famously even Apple tried and failed with Copland.

[Jpan1]

One OS to them all
One OS to find them
One OS to bring them all
And in the darkness bind them...

Sorry I've been drinking

I like it! And is there one machine to do it all?
Or from the question posed do I fall,
What maketh or breaketh the ideal OS
Depends upon what the user bringeth..

Sorry not drinking enough, and hence the pseudo jibe

[zylesea]

That's another question - is MorphOS with a new SMP API, a new ISA and no binary compatibility with 68k Amiga or PPC MorphOS actually MorphOS at all? Or is it another OS by the same developers?

Yes and no I'd say. If API changes that drastically that you need to rewrite all your code completely, then it's definitely a new whole OS, but if API stays rather similar (changes are of course inevitable and on a rather low lovel) then I'd say it's still the same OS. Probably somewhere in between. And i would welcome if MorphOS "NG" will still come with some compability to the old stuff, IMHO best approach in a boxed away implementation: http://via.i-networx.de/q86.htm

[Linde]

That's another question - is MorphOS with a new SMP API, a new ISA and no binary compatibility with 68k Amiga or PPC MorphOS actually MorphOS at all? Or is it another OS by the same developers?

If Amiga OS4 can be Amiga OS, while running on a completely different, utterly incompatible platform to the previous versions, only offering native support to a tiny fraction of Amiga software, I don't see why not.

[paolone]

I've not tried AROS for some time, but I hope it gets to the point where I can build a new PC and simply install AROS on the machine.

Good! So please learn the needed coding, and start writing drivers for the hardware you own. I'm afraid even if everyone here (and I mean anyone reading this) will do the same, we won't see AROS supporting ALL available PC hardware anyway. There's too much hardware to support, and too little people writing drivers, so the best we can do is trying to support all common standard and then hope that specialistic code will be brought by somebody else. Maybe, why not, some from the people currently just complaining that AROS does not work on their PC, that they had to buy (cheap, often already used) components, and maybe at the same time dream about buying that blazing, rare and uncommon $3000 hardware needed to run other operating systems (to basically do the same things, btw).

[SamuraiCrow]

Since Linux runs on most next-generation hardware in some form, I think the Arix kernel's ability to bridge between AROS software and Linux drivers is the most plausible solution for unifying the Amiga community.  All it would need (assuming the project is not delayed indefinitely) is some cross-compatibility bridges like OS4Emu on MorphOS to be able to run other applications AmiBridge-style as well.

My preferred solution to the driver scenario is actually to require everyone to give up on GFX cards that are incompatible with the Amiga chipsets and use FPGA technology to accomplish hardware compatibility.    After all, if we could get next-gen performance out of a classic model Amiga, why bother with all the graphics card kludges?

Not that there is much point to this.  Once unified, the Amiga community may still fall flat on its face.

[wawrzon]

Good! So please learn the needed coding, and start writing drivers for the hardware you own. I'm afraid even if everyone here (and I mean anyone reading this) will do the same, we won't see AROS supporting ALL available PC hardware anyway. There's too much hardware to support, and too little people writing drivers, so the best we can do is trying to support all common standard and then hope that specialistic code will be brought by somebody else. Maybe, why not, some from the people currently just complaining that AROS does not work on their PC, that they had to buy (cheap, often already used) components, and maybe at the same time dream about buying that blazing, rare and uncommon $3000 hardware needed to run other operating systems (to basically do the same things, btw).

i just thought about some possibility to improve the situation. one of the main issues is when the rtg hardware is not supported by gallium or any specific driver. it was discussed before but i think perhaps if the vesa driver was extended to accept screenmode change on the fly it could fill in the gap. is that possible at all? my interest in ths would be to have native aros driver for rtg cards in aris 68k esoecially for thise nit supported by p96drivers via uaegfx wrapper.

[7valleys]

Since Linux runs on most next-generation hardware in some form, I think the Arix kernel's ability to bridge between AROS software and Linux drivers is the most plausible solution for unifying the Amiga community.  All it would need (assuming the project is not delayed indefinitely) is some cross-compatibility bridges like OS4Emu on MorphOS to be able to run other applications AmiBridge-style as well.

My preferred solution to the driver scenario is actually to require everyone to give up on GFX cards that are incompatible with the Amiga chipsets and use FPGA technology to accomplish hardware compatibility.    After all, if we could get next-gen performance out of a classic model Amiga, why bother with all the graphics card kludges?

Not that there is much point to this.  Once unified, the Amiga community may still fall flat on its face.

Or Aeros, which allows you to run Linux apps as well. two different approaches, Arix hides the linux kernel, Aeros allows you to use it. To me having the ability to run Linux apps makes me want to dedicate hardware to it.

We all want different things, it would be hard to see one OS providing everything we want.

[fishy_fiz]

Nope, ARIX doesn't use the Linux Kernel, but rather a shiv.
Aeros is an interesting oddity in my opinion, but given the Linux hosted AROS side is what is amiga-oid about it, it fits the description of Linux distro more than anything, rather than an additional OS.

[Fats]

I must admit, I'll be highly impressed with Hyperion if they can successfully implement smp and memory protection while remaining compatible to current apps.

There are those who claim it's impossible, and famously even Apple tried and failed with Copland.

One of the main things that is a problem is that Forbid() is not SMP friendly. When a task calls Forbid() it expects no other process will run at the same time also not on another CPU. Currently this function is used a lot both in the OS libraries as well as in programs themselves.
So one of the things being done is to replace Forbid() locking in the OS functions with other means of locking. Likely this will break compatibility with some programs that expect the exact Forbid() behavior. This in turn will be enough for some forum whiners to claim the result is a not 100% compatible system but for more pragmatic persons it may be good enough as most of the programs will still run without problems and also giving you the advantage of SMP.

This still leaves the programs that themselves are heavy Forbid() users. This can likely be solved by penalizing the performance of these programs by rate limiting Forbid() calls so non-heavy Forbid() users are not much impacted and run (almost) at full speed. Probably enough material again for some people to complain loudly.

[amigadave]

Nope, ARIX doesn't use the Linux Kernel, but rather a shiv.
Aeros is an interesting oddity in my opinion, but given the Linux hosted AROS side is what is amiga-oid about it, it fits the description of Linux distro more than anything, rather than an additional OS.

I will have to check out Aeros more closely to see if it emulates, or copies the "Look & Feel" of the original Commodore AmigaOS3.1 computers for my taste.  I don't personally care if it is a Linux distribution or what name it has applied to it.  If it can run all of the old Amiga software seamlessly by using UAE in a way that makes it almost transparent, or at least very easy, but not transparent, and I can also run new AROS native software, plus the huge library of Linux software, without requiring a reboot, or restart of the system each time I want to run software from a different platform, it will probably satisfy my needs and desire to run an Amiga Inspired platform. Has Aeros been ported to the X1000 already?  I would use it on mine, instead of any alternative Linux distribution.

@Fats,

Similar to what I just wrote above about Aeros, if AmigaOS4.x needs to lose all ability to run AmigaOS 68k binaries and only rely on using Run-in UAE as the only method to run old 68k Amiga software, so that they can implement SMP and real Memory Protection, I would vote YES!  Do it ASAP and dump the partial binary compatibility that Petunia provides, if it will give us real SMP and Memory Protection.  I have a feeling that this is not the case and there are other things that are holding them back from providing SMP and Memory Protection, or they most likely would have done it already.

[amigadave]

Genesi used to sponsor developers with free hardware but many just took free hardware, sold it and then quit. Some developers did develop something and then quit. Only few lasted longer so personally I dont see it viable option. Even when developers have good intentions it gets easily wasted, like with Spotify.

Bounties work better but someone must get committed to update software regularly.

Bounties are a good solution for funding some software projects, but as you pointed out, they don't guarantee that the software created will be maintained in the future.

With our needs for new software being so huge, I believe that any and all means to support and encourage new software development should be used, including bounties, sponsored commercial projects, and maybe even a few Kickstarter projects, along with donated hardware and the creation of sites like the AmiStore or other online services which make it easier for programmers to sell their work and continue programming for our platforms.  There is no single solution and I guess we will always be struggling to get more and better software for our platforms, until such time when we are large enough to make it more financially desirable to program for any of the Amiga inspired platforms (if we ever reach that point again is doubtful).