Quote:

I guess this depends on the people you ask. I think there are more important issues like a proper word processor and other applications.

Speed is not an issue for me. I still use the good old Pegasos G4 with 1Ghz, even if I could use several much faster MorphOS systems sleeping around in storage here.

SMP, memory protection, 64Bit support, virtual memory will come with a price. Loosing the compatibly to all thirdparty PPC and all 68K applications, which aren´t in development anymore. It also will split the user/market once again. So a step like this should be made wise and preferable only once. And that is the point, where MorphOS swaps hardware. Such opportunity must also be used to drop insane and old crap the OS is filled with to keep it compatible with old Amiga and the old AmigaAPI simply is stupid in many ways.

In the result we would get a totally incompatible MorphOS system that is as fast as possible, shiny and clean for the future, but has no applications beside the ones provided by MorphOS developers itself.

To get there it would/will take years of development and testing. That is nothing one will do within a few months. Also keep in mind that parallel to cleanup and feature extension a complete new platform needs to be supported, which mostly alone takes a year at minimum as you all know from experience.

After all that work, you would have support for one board (probably some by then old x86 Mac) and nothing more and people will start screaming for more hardware to support, which somehow sounds familar.

Geit


[ Edited by geit 15.05.2013 - 12:53 ]

Quote:
Agree...

Putting aside hardware and application software issues, what's the motivation to create a new operating system? What is it going to do that isn't being done or being done well enough by Windows, OS X, Linux/BSD, Haiku or other?

For me that is quite easy. I don´t like to adapt my workflow into a static frame dictated by software.

E.g. on windows everyone knows you cannot move the main window once a file requester is opened. Or a video rendering application opens a small progress bar, which states 2 hours done, 4 to go, but you cannot use the system, because the fullhd sized main window is blocking the entire screen and pops in frequently.

With MorphOS I have the opportunity to deal with that quite easy. First of all. Such things like mentioned above are easy to avoid or don´t even happen, unless someone spend a lot of time to create annoying features.

Also the system is quite open, so I can configure most stuff as I like and want it. If some application is not working like expected, or things can be simplified, I can contact the developer in person and make suggestions. Try contacting m$ to add some option to IE. :D

On other systems like Windows and OSX I often feel limited. On MorphOS I don´t feel that way unless I need software which does not exist, but in that case I launch rdesktop and get the best of both worlds.

Geit

OSes and applications that think they know better than the user boil my piss are a bad trend but do OSes like DragonFlyBSD and Haiku have that problem? Those two are of particular interest to me due to the influence they've had from people with Amiga backgrounds.

How has AROS dealt with the single cpu and address space issues?

AROS has the same limitations until today.

I was alsa excited, when discovered Haiku, but... it was two years ago and almost nothing changed since that time. They do their work really slowly due to the fact, that they receive some ca$h, and Google also support them. Last time, when I tried it, it was very very slow on my laptop and after restarting the installed Linux was also very very slow. Just a battery removal helped.

>> How has AROS dealt with the single cpu and address space issues?

> AROS has the same limitations until today.

Does 32-bit AROS support 2 GiB RAM (like MorphOS and OS4) or 4 GiB?

It supports 4 GiB.

Yes, because it doesn't have to be compatible.

>> Does 32-bit AROS support 2 GiB RAM (like MorphOS and OS4) or 4 GiB?

> It supports 4 GiB.

Thanks. So that's one limitation less.

What are the downsides of ASMP?

I have had some thoughts abou ASMP for the G5.
Is the memory seperate per processor, 2gb+2gb or 4gb+4gb, or can it be made so?
Can Quark be set up to set aside a certain percentage of timeslices to other process' besides Abox?
A could process be set up in Abox to overlay information to a created MUI/Ambient window?

[ Edited by Jim 19.05.2013 - 14:21 ]

Yasu,
Quote:
Only explicitely AMP aware applications can take advantage of the additional cores. All other software can use teh main core only. On SMP the OS schedules all tasks/threads more or less well balanced to all available cores.

Zylesea,
Quote:

And that would be more than fine for us I think. Old legacy programs run happily with single core and more cpu hungry programs are still in development so they could be adapted. I don't think full SMP would give that much more in comparison to AMP in our case. Getting AMP would be big enough step here and probably possible before breaking everything :) Getting mplayer, reggae and similar stuff to use second cpu would be a good start...

jPV,

Quote:

I hereby agree...

Jim,
Quote:
I guess it might be doable, BUT at the time of task creation, there's no way to know which other tasks it needs to share memory with. Most often, that includes system tasks btw. which would restrict most tasks to "system running core".

jPV,
Quote:

I do not think this will happen. With the limited resources, there is no reason to waste any.

Better go for the right target instead of doing it wrong on purpose. Thats the same reason why no one will go the Cygnix way, too. It is a solution that in the end no one wants.

Geit

geit,
Quote:

Doesn't that depend on how hard it is to implement? Without knowing too much about programming, AMP does sound like a relatively easy way to get multicores until MOS changes architecture. I think you are right to say that doing it the right way from the start is the way to go, but we should not forget the existing hardware as well. If we would get multicore G5 working, our hardware would suddenly not be so far behind anymore. As a modern OS, MOS would gain a couple of more years before becoming too old for everyday usage.

+1 for ASMP support.
Even if it is unlikely, it would make a nice feature.

@Geit

Guess that depends on what is seen as "the right way".

The final goal should be a MorphOS running on none-PPC and PPC HW useing as many cores as availbale to run SW compiled against an Amiga-inspired legacy-free API (+ maybe some box to run old 68k stuff in one way or another).

On this route the 1st step could be to transform Quark into something with an SMP-capable API.

Make this API accessable from ABox (sind Quark won't be ready to support full apps including GUI, network etc from the start) and it would indead be seen as AMP from an ABox-perspective.

Still a lot of man-hours required, but assuming there actually is a plan to achieve "the right way" it shouldn't be much of a detour.

Kronos,
Quote:

Thanks Kronos,
As I intend to keep a PPC based system after the ISA change, I would like as many features as possible.

> the 1st step could be to transform Quark into something with an SMP-capable API.

I believe that Quark provides that already.

http://en.wikipedia.org/wiki/Quark_%28kernel%29#Design_goals

> Quark won't be ready to support full apps including GUI, network etc from the start

Will it ever? I mean it's just a kernel.

>> Quark won't be ready to support full apps including GUI, network etc from the start

>Will it ever? I mean it's just a kernel.

Micro kernel at that, so even more services than normal occupy user space.