One unified OS for the future?

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

[amigadave]

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.

Yes, I know very well that many MorphOS Dev. Team members also create new, or port existing software to MorphOS.  My point was that if they slow down or stop working on ports of MorphOS to new PPC Mac models which are not currently supported, it will leave them with even more time to continue work on more software for MorphOS to run.  In that way, running out of more PPC Mac models to try to support can be a good thing for MorphOS users, not a bad thing, like the "End of the Road", that some might perceive incorrectly.  As itix also pointed out, it will take years before lack of new hardware becomes a real problem for MorphOS.  Perhaps by then, cheaper PPC systems with acceptable performance might be available from ACube or A-Eon, as I see no reason why the MorphOS Dev. Team can't port to new hardware if they believe that it is a viable hardware choice, or no other choices are available and the switch to a different architecture is not ready to happen.

Using old Mac PPC hardware should remain an acceptable choice for a few more years, unless they begin going to recycle facilities or land fills, instead of eBay and Craigslist at reasonable prices, like it is now.  I think my PPC Mac computers will last long enough for me to continue using them, until an architecture change is made by MorphOS Dev. Team members, or until they find other alternative PPC hardware to port to.

My comment was about Trevor Dickinson and Matthew Leaman of A-Eon and AmigaKit respectively, not Hyperion, and the recent efforts to help programmers, plus A-Eon's/AmigaKit's sponsorship of software projects, such as the Libre Office port, and others.  Hyperion appears to have more programming work than they can accomplish quickly, just trying to complete AmigaOS4.2.  I was commenting on A-Eon's & AmigaKit's increase in focus toward supporting more and better software to run on AmigaOS4.x, now that hardware availability is not the problem it was, prior to ACube's SAM boards becoming available and A-Eon's X1000.

I hope that all flavors of Amiga and Amiga inspired platforms will soon enjoy increased software development, for various reasons, and that was the main point I was trying to express.  New content could be the best thing to happen for us in a long while, now that we have a fairly large number of hardware models to choose from.  Even the Amiga 68k users and programmers appear to be getting new hardware soon, and hardware has never been a big concern for the AROS users and programmers, as their choices have been fairly wide for a long time already.

I just hope that enough programmers are still alive (we keep losing old Amiga users and programmers to natural causes and old age) and/or still interested in our community, and that some of our younger users will take this opportunity to learn how to program on one or more of the Amiga & Amiga Inspired platforms (I am going to improve my own meager coding skills within the next few years, so maybe even I will be able to produce something useful or fun in the near future).

[spirantho]

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

Yes, that's a good description of when to use bytecode (final app) and when not to (the guts of it) - and illustrates how we need both quite well.

[dammy]

To the  topic, it is much too late for a "unified OS" because there are both  technical, legal and emotional reasons why this will never happen. What I  personal hoped for was that the camps would agree on a common  infrastructure to avoid unnecessary double work and speed up development  and make it easier to crosscompile. Common are (in my view)  PCI-support, USB, most of the system libraries and GUI system. The  sources should be opensource. All user-related components like desktops  and addons that are new and specific could have stayed closed. But I  understand now that even this idea is unrealistic. So people should  concentrate on what they have and help there.

+1.  Let Darwinism do it's thing.  It would be nice if some code can flow between projects, but such is life if it can't.

[itix]

My comment was about Trevor Dickinson and Matthew Leaman of A-Eon and AmigaKit respectively, not Hyperion, and the recent efforts to help programmers, plus A-Eon's/AmigaKit's sponsorship of software projects, such as the Libre Office port, and others.

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.

[Fats]

The only .so files you find is the onces ported from Linux. And having .so file support most defiantly helps poring over software like QT, hey if you don't like software that is ported from Linux your free to stick to only MUI and Reaction software, but chances are that even they contain linux libs ".a" files that have been linked into it.

I don't have problem with porting Linux software. I have a problem with run-time linking which makes program startup non-instant which in my eyes is not Amiga-like.
When I start a browser on my A1SE it takes a few seconds to start up.
You should also find more info on this site and on the AROS dev archives on why I think that everything where they use .so now for - including plugins - can be done using amiga style shared libraries using compile time linking.

Simply put "shard object" support is a compromise.

In my eyes a bad compromise: it trades off user experience for developer comfort.
Of course all in my idealized definition of what an Amiga OS should be.

[Fats]

The "Look and Feel" justification is one of the easiest differences to point to though, so it is often mentioned.  I just hope it is not really true that users are making their choice on the "Look & Feel" factor, when it can be adjusted so easily on either OS to "Look and Feel" any way they like, even almost exactly like the other OS they are turning away from by making that decision.

It's very difficult to really put the finger on it and it's likely more than just look & feel but the whole behavior of the system. And yes I did try to change the look (it was already a year or so ago so not the recent MOS version). If it really can be done it is not as easy as you seem to try to point out.
One example of look I can't get used to is the button style interface to switch between multitabbed shells; I did not find a setting to transform that in tabs as GUI element.
All said I do enjoy using MOS less than using OS4, although I hardly use any of the two lately. You may find it irrational and I have to admin it is subjective. I am also one of the guys who thinks DirectoryOpus went the total wrong way with version 5.
If you want to call me ignorant because of this I think we have to disagree.

Edit: This is in no way an attack on people who do enjoy using MOS over OS4. I can fully understand that and please do enjoy it; just realise other people may think differently and you will never understand them

[OlafS3]

@OlafS3

You mention something which would be very useful, actually.
I can see that for many parts, there are similarities rather than differences, but for some bits such as the PCI and USB that you mention, the APIs are quite different. If they were standardised across platforms it would make driver development much easier across platforms. Even graphics APIs are separating more and more now.

We should celebrate the differences in the underlying OS between MorphOS, AmigaOS and AROS, while striving to keep software flowing on all the OSes... but as the APIs move away from each other this will get harder and harder.

Ideally I would like there to be an independent "Amiga-like" council which would define APIs - each OS would contribute submissions via RFCs to the multi-platform council which would then ratify or deny that submission before it became standard.

This could never happen, though, because each of the OS owners would say "Why should we? We're a different OS - we're not responsible for the other OSes. We'll do what we like, thanks".... plus in my experience there would be precious little agreement about how the APIs should work - but it would be nice.

I think the OS devs make there a big mistake. From my outside view (you can correct me) that is expecially the case for the AmigaOS devs. I know that Aros and MorphOS are very similar and highly compatible to AmigaOS 3.X whereas I know for several projects who had problems to support AmigaOS. Biggest problem for Aros is still MUi-support (Zune) if that is solved most applications work. I see that when I test applications on Aros Vision where I could add MUI38. AmigaOS seems intentionally go in a different direction and force developers to decide for or against AmigaOS. That works as long most devs are only supporting one platform and not really interested in crossplatform development, as soon this changes (f.e. a commercial market is again slowly developing) that will strike back and then there will be no chance to correct that without breaking all software. What do you think?

[spirantho]

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

[OlafS3]

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

You think the changes are SMP-related? I more thought they were done because of no interest what the others do. There are a number of cases where they reimplemented something but not compatible (neither to 3.X nor Aros/MorphOS).

Latest with 64bit nothing will run anymore so recompiling of everything would be necessary. The only camp where they are testing with SMP officially is Aros (Arix), if MorphOS or AmigaOS are heading in that direction yet is unknown. I read that the MorphOS devs would do 64bit and SMP in case of a ISA change and if I see it right (from outside) they have not yet decided where to go so they are propably concentrating on improving the existing base.

[OlafS3]

Besides as I understand it SMP is promised for decades (I think I read a announcement from 2003) but for 4.2 they only promised MESA/Gallium-support. 4.2 was paid by X1000 users so they will certainly concentrate on fullfilling the contract and features like SMP will have to wait. Another thing, will AmigaOS users accept a solution like Amibridge existing in Aros in AmigaOS? If not they have a serious problem with SMP.

BTW what do you think of my idea of a standardized Amiga class library?

[spirantho]

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.

Already we're seeing some of the fruits of their labour (e.g. the Extended Memory system for >2GB RAM which is one of the main benefits of 64-bit architectures). This sort of thing would have been much harder without the API changes.

I think many of the misconceptions surrounding Hyperion developers is that they're idiots. They're not. There are reasons why they do what they do (but they're not always obvious to the end user). They don't create work for themselves just for the heck of it. It's not in their interests to do nothing except break APIs - they need to keep pushing the OS forward otherwise they'll never sell another copy, and they're well aware of this.

[itix]

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

From MorphOS developer point of view I have not seen any changes in AmigaOS 4 that would support SMP.

[OlafS3]

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.

Already we're seeing some of the fruits of their labour (e.g. the Extended Memory system for >2GB RAM which is one of the main benefits of 64-bit architectures). This sort of thing would have been much harder without the API changes.

I think many of the misconceptions surrounding Hyperion developers is that they're idiots. They're not. There are reasons why they do what they do (but they're not always obvious to the end user). They don't create work for themselves just for the heck of it. It's not in their interests to do nothing except break APIs - they need to keep pushing the OS forward otherwise they'll never sell another copy, and they're well aware of this.

I did not write "idiots", I wrote "not interested". The difficulty of adding SMP is if applications automatically benefit of it or only if they are adapted to use it. SMP (how it is tested on Aros/Arix) is designed to automatically use several cores and that is much more complicated than a kind of PowerUp solution. That will not work without major changes on the system and that breaks 68k compatibility. For Aros no problem, MorphOS would make a break too but what will AmigaOS user say when that happens. 68k integration (in difference to using emulation) was a major reason to use PPC (and not another ISA).

[spirantho]

I wasn't referring to you, particularly, more to the whole feeling I get from other people on forums like this. Usually the same people who accuse AmigaKit of making lots of money on the X1000, as though they're all driving Ferraris or something (but that's a different argument for another day ).
SMP has to be transparent, otherwise it wouldn't be SMP. The difficulty will be getting SMP working without breaking binary compatibility, as you say. I suspect the solution would be to have "SMP-enabled" binaries and "legacy binaries" which can only run on the one core. I don't really know, though, I'm just guessing there.

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