Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

Are We Just Nostalgic Or Should the Amiga Advance?page  1 2 3 4 5 6 7 8 9 10 11 12 13 

Kamelito Loveless

Posts 259
30 Jun 2019 12:23


User friendly programs patch OS functions call by using the function SetFunction() so in theory you could prevent patching but I don’t think it is a good idea. Best Thing to do if you don’t like 3rd party programs that patch the OS is to do not use them.


Michael Borrmann

Posts 140
30 Jun 2019 12:37


Getting Amiga OS into modern territory was tried with MOS and AOS 4.1.

In the end, there are just not enough coders around to compete with Windows, Mac OS or even Linux.

Deal with it.


Nsklaus -

Posts 63
30 Jun 2019 12:47


@kamelito
it wouldn't hurt to let the users choose that for themselves, on demand  ?

i mean, as long as user can re-enable patching when they want it.

once the system finished booting, all the desired patch already being applied, (cgfx, picasso, birdie, and so on) at the end of user-startup, having a command execute "toggle-patching off".
the system could runs in that patched state, while refusing to run software that want to apply more patching. unless user say, yes i want to re-enable patching, and runs "toggle-patching on".

all non-system-friendly programs should be prohibited too imho.
amigaos and clones should enforce strict system-friendly apps only policy. maybe this could be another toggle/flipswitch command.

only with that kind of strict rules you can guaranty what's going on under the hood, and disallow unapproved behavior.
if you think about it, it could also be appealing, security-wise, which is kind of non-existent on amigaos and clones.

we are lucky there's not much people interested in doing viruses for amigaos. otherwise it's free for all on this kind of OSes.



Nsklaus -

Posts 63
30 Jun 2019 12:56


@bormann
   
    this is not the best attitude towards a given problem.
    by the way morphos 4 will have memory protection and other modern mechanisms unless i'm mistaken, while retaining the good sides of being what it already is an amiga lookalike OS, small, responsive, with clear filesystem hierarchy, file and directory structure, good amiga-ish looking desktop and so on. so never say never.
    maybe aros will reach that goal too, they already went researching into that direction more than once and still do.
   
    amigaos itself still see little improvements from time to time.
    like fight against memory fragmentation, kernel patches, better filesystem and such .. so why refusing to even think about that kind of things .. thinking doesn't cost much. you never know you might find a good idea.


Mr Niding

Posts 459
30 Jun 2019 13:12


"In the end, there are just not enough coder"

Its not really an attitude tho, its more a reality orientation :)


Nsklaus -

Posts 63
30 Jun 2019 13:28


there's enough coders for doing that on morphos, and aros and even amigaos, that's exactly the point of my previous post.


Steve Ferrell

Posts 424
30 Jun 2019 17:01


nsklaus - wrote:

there's enough coders for doing that on morphos, and aros and even amigaos, that's exactly the point of my previous post.

No, there aren't enough coders.  You need to go back to page 1 of this thread and read the 3rd post.  Classic Amiga apps access the hardware directly.  Every Amiga app would need to be re-written and re-compiled for an OS that implements memory protection and virtual memory.  Even if we had access to all the source code to every classic Amiga app, there aren't enough programmers on the planet to port that many apps over to this new OS.  The better option is to run said apps via an emulator or sand-box using an existing OS that already implements memory protection and virtual memory.



Stefan "Bebbo" Franke

Posts 139
30 Jun 2019 17:20


A possible memory protection for AmigaOS explained shortly:

  - each application gets its own memory
  - with each task switch the memory protection is newly configured for the current task (-> slows down)
  - each access beyond the own memory is checked: ok, or not (even slower)
  - and there is a white list for applications that can do everything
(stays the same - hooray!)

In a time, where there is no effective memory protection (RAM bleed and friends), you can do without it completely ^^




Tim Trepanier

Posts 132
30 Jun 2019 17:29


This has become another thread verifying that you can't add memory protection to AmigaOS and still be an Amiga. It's extremely difficult to do and even if we mustered up the resources to do it the result would give us the crawl along speed, bloatedness and lack of system flexibility of other systems.

So instead, we need to focus more on ways to help developers produce good quality code.



Steve Ferrell

Posts 424
30 Jun 2019 17:41


Stefan "Bebbo" Franke wrote:

A possible memory protection for AmigaOS explained shortly:
 
  - each application gets its own memory
  - with each task switch the memory protection is newly configured for the current task (-> slows down)
  - each access beyond the own memory is checked: ok, or not (even slower)
  - and there is a white list for applications that can do everything
  (stays the same - hooray!)
 
  In a time, where there is no effective memory protection (RAM bleed and friends), you can do without it completely ^^
 
 

Now you are simply describing an OS that implements memory protection.  It does nothing in regard to allowing apps that write directly to RAM and/or the custom chips (AKA classic Amiga apps) to continue doing so in order for them to run properly.  This breaks those apps. 

Implementing a whitelist or allowing some apps to bypass memory protection defeats the entire purpose of memory protection and would allow those programs on the whitelist to corrupt memory and bring down the entire OS, which brings us right back to where we started....memory fragmentation, memory corruption, and an unstable OS....this is classic AmigaOS...love it, or leave it.

 




M Rickan

Posts 177
30 Jun 2019 18:42


We can all come up with grandiose schemes for preserving the past or embracing the future but this is not a technical problem.

Unless you want to ditch the IP and branding, the legal issues need to be addressed before any real progress can be made.


Stefan "Bebbo" Franke

Posts 139
30 Jun 2019 18:53


Steve Ferrell wrote:

...
 
  Implementing a whitelist or allowing some apps to bypass memory protection defeats the entire purpose of memory protection and would allow those programs on the whitelist to corrupt memory and bring down the entire OS, which brings us right back to where we started....memory fragmentation, memory corruption, and an unstable OS....this is classic AmigaOS...love it, or leave it.

So on your systems no software is running as root?
Because using root defeats the entire purpose of ...




Steve Ferrell

Posts 424
30 Jun 2019 19:02


m rickan wrote:

We can all come up with grandiose schemes for preserving the past or embracing the future but this is not a technical problem.
 
  Unless you want to ditch the IP and branding, the legal issues need to be addressed before any real progress can be made.

Those legal issues have already been addressed quite well by the AROS project.  AROS is a re-implementation of the classic AmigaOS that doesn't use any of the original AmigaOS source code in order to avoid all the legalities.  It is API-compatible with classic AmigaOS and the 68K version of AROS even runs classic 68K Amiga apps without the need for any recompilation or modification.

In answer to the calls for memory protection, virtual memory and SMP, the author of AROS, Michal Schulz, has been working on ARIX.  ARIX is AROS that uses a Linux kernel for its underpinnings.  Since ARIX still uses the same API as classic AmigaOS, one would only need to re-compile the source code of their classic app to get that app up and running with all the benefits of memory protection and virtual memory.  If the source code is no longer available, the app can be run under UAE for AROS/ARIX.  ARIX is a work-in-progress that began around 2012 or 2013.  I was an initial beta-tester and the results were very promising, but Michal is just one person who has a family and a job to manage and lately his focus has been on the ARM version of AROS, not ARIX.


Steve Ferrell

Posts 424
30 Jun 2019 19:04


Stefan "Bebbo" Franke wrote:

   
Steve Ferrell wrote:

    ...
     
      Implementing a whitelist or allowing some apps to bypass memory protection defeats the entire purpose of memory protection and would allow those programs on the whitelist to corrupt memory and bring down the entire OS, which brings us right back to where we started....memory fragmentation, memory corruption, and an unstable OS....this is classic AmigaOS...love it, or leave it.
   

   
    So on your systems no software is running as root?
    Because using root defeats the entire purpose of ...
   
   
   

   
Now you are confusing system permissions with memory protection. They are in no way related.  But on classic AmigaOS, essentially every app runs as as a root application with the ability to access  the hardware directly and to modify the OS internals, meaning that any app can break the OS and crash the system.
 
You cannot have memory protection without a hardware abstraction layer.  AmigaOS will never have such a layer because to add such a layer would break every classic app, because every classic app  must write directly to the hardware.  To get beyond this problem, a NEW OS would have to be written and the old apps must be re-compiled for this NEW OS or these old apps will need to be run under an emulator on this new OS.  This has been made clear time and time again, not only in this thread but on other forums for years. I cannot help you with your failure to understand.  You must take up the gauntlet and break out the books, or go back to school if necessary to learn about memory protection and hardware abstraction.  Unfortunately, we cannot bridge your lack of understanding on this lowly forum.


Nsklaus -

Posts 63
30 Jun 2019 19:27


of course memory protection is possible on amiga.
  (btw, even atari found one way to have it)
      little minds only thinks it is not possible.
      why ?
      because they want to gain memory protection feature without changing nothing and retain compatibility. that is not reasonnable.
      even the original team did break compatibility several times in order to bring new features. and compatibility break was also planned for future updates.
     
      wanting to keep backward compatibility at all cost is what sank amigaos. that and the horrible leftovers of what once was a great community.
     
      break the damn compatibility, 3.1 api is not sacred. it's a terribly outdated thing that was great long ago, but not anymore.
      keep the spirit, some good ideas and bring new features, make modifications where needed and run the old stuff in emulation or isolated/virtualised boxes. doing that will not cause a time paradox and erase amigaos3.1 from history. it is there it will not disappear. just make a 3.2 with modern feature instead of praying the dead. aros and morphos got the right idea. everyone should get behind aros and unite efforts, and create a 'modern branch. a classic branch 99% compatible with 3.1 for the 'purists' that want to stay stuck in 199X for life, and another different branch with the modern stuff for those wanting to run a good trustworthy OS, problem solved hello 21century.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
30 Jun 2019 19:41


nsklaus - wrote:

  just make a 3.2 with modern feature instead of praying the dead.
 

 
Sorry but I think you see this wrong.
 
Can I ask you a question?
How good do you know the internals of AMIGA OS?
Did you write AMIGA OS programs using AMIGA OS structures?
 

What you propose and believe to be good is _your_ very personal opinion.
Its not necessary what every body on earth thinks is good.

The truth is that your proposal will kill a portion of the "spirit" of the OS.
Maybe the AMIGA features this will kill are not important to you?
But for some people it might kill what makes Amiga an AMIGA.


Samuel Crow

Posts 424
30 Jun 2019 19:44


Re:Old vs. New

64-bit and memory protection will break AmigaOS.  AROS has 64-bit and SMP on the way but still will not support full memory protection.  These will all break backward compatibility.

Since the option to stay old will not allow the use of 64-bit addressing nor SMP nor memory protection, there is an AROS feature that hasn't been listed yet:  a hosted operating system.

AROS 68k is backward compatible to AmigaOS and unlike AmigaOS, can be adapted to run on top of another OS kernel.  Is the real question whether the new OS should be Amiga-like or is the real question should the new OS be even source compatible to the original Amiga.

As long as Janus-UAE, EUAE, WinUAE or some equivalent code can be made to leverage SAGA or MiniMig chipset cores it will be compatible enough to run the old software.  But in order to run 64-bit software with it the host environment will need to run a 64-bit kernel.

Let's look at some options:
  * AROS 68k hosted on Linux is easily done but slower than it should be because the Linux kernel is security minded to the point of a fault.  Also has the GPL license tied to the kernel.
 
  * AROS 68k hosted on Haiku is lighter weight than Linux hosted but still not ideal because the kernel was written on x86-64 and uses about 1 Gig of RAM minimum.  It's MIT licnensed so it can be distributed commercially without Haiku-based source.
 
  * AROS 68k hosted on ARIX is better than Linux because of the lighter weight kernel and better than Haiku because it still uses Linux compatible drivers.  ARIX was planned to be GPL licensed but MPL2 licensing is looking more likely at this point.
 
  * AROS 68k hosted on some 64-bit AROS derivative is lighter than any of the above options since the hosted environment can call functions directly from the 64-bit kernel with some glue code.  AROS public license is a rebadged MPL1.1 license which is not GPL compatible and therefore cannot legally use GPL drivers.  It is BSD licence compatible though, as is Haiku so all is not lost.  No memory protection is possible.


Steve Ferrell

Posts 424
30 Jun 2019 19:45


nsklaus - wrote:

  of course memory protection is possible on amiga.
    (btw, even atari found one way to have it)
        little minds only thinks it is not possible.
        why ?
        because they want to gain memory protection feature without changing nothing and retain compatibility. that is not reasonnable.
        even the original team did break compatibility several times in order to bring new features. and compatibility break was also planned for future updates.
       
        wanting to keep backward compatibility at all cost is what sank amigaos. that and the horrible leftovers of what once was a great community.
       
        break the damn compatibility, 3.1 api is not sacred. it's a terribly outdated thing that was great long ago, but not anymore.
        keep the spirit, some good ideas and bring new features, make modifications where needed and run the old stuff in emulation or isolated/virtualised boxes. doing that will not cause a time paradox and erase amigaos3.1 from history. it is there it will not disappear. just make a 3.2 with modern feature instead of praying the dead. aros and morphos got the right idea. everyone should get behind aros and unite efforts, and create a 'modern branch. a classic branch 99% compatible with 3.1 for the 'purists' that want to stay stuck in 199X for life, and another different branch with the modern stuff for those wanting to run a good trustworthy OS, problem solved hello 21century.
 

 
 
  Yes, which is exactly what I've been saying.  A new AmigaOS needs to be written that casts off backward compatibility and runs old apps in a sand-box or via emulation.
 
  But a new OS doesn't come with the snap of ones fingers.  It takes developers and years of coding and testing and the Apollo Team already has its hands full just keeping up with Vampire hardware, let alone writing a new OS.
 
  A Linux distro that is back-ported to the Vampire would be awesome or ARIX as well.  But then as Gunner points out, you've lost the essence of what makes an Amiga an Amiga.


Samuel Crow

Posts 424
30 Jun 2019 21:07


Steve Ferrell wrote:
But a new OS doesn't come with the snap of ones fingers.  It takes developers and years of coding and testing and the Apollo Team already has its hands full just keeping up with Vampire hardware, let alone writing a new OS.

Actually, open-source operating systems can be modified to run on a Vampire once a compiler exists to generate code natively for it.  What really hurts is that the new OS won't be backward compatible to the old Amiga software.  As I mentioned above, a hosted AROS can do it but there are more things to consider.

Since AROS is only source code compatible with other versions of AROS, everything new for it has to be open-source so it can be recompiled.  This means commercial viability is out of reach for good because, as cloud hosting firms have found out, writing open-source is an ego-boost for the author and potential means to show off.

Bytecodes like WebAssembly are a potential workaround since the bytecode is almost as low-level as Assembly itself.  There is another feature of AmigaDE that was often overlooked to the point that even WebAssembly doesn't implement it:  Dynamic Binding.

One of the two major speed advantages of the AmigaDE bytecode was that device drivers could be implemented using macros instead of function calls.  Hardware banging was injected into the application from the driver so that there was no calling overhead and even primitive caches could latch onto the hardware bangs easily.  This is exactly the same technique demo-coders use to implement fast code even today.

The other speedup feature of AmigaDE was AOT compilation.  Using the Wasmer engine, WebAssembly code is generated into the final machine language once at startup relieving the overhead of JIT compilation.  Unfortunately WebAssembly's bytecode uses high-level structured code constructs internally to make it an add on to JaveScript in a browser.  If we follow the bytecode path, non-structured branches should be used.


Nsklaus -

Posts 63
30 Jun 2019 21:20


what is it you all as a community that you don't understand ?
  the original team itself did break compatibilty few times during amigaos life. they also planned to break compatibility again for the next updates. read these sentences again.
  and finaly realize this is what need to be done of course.
  do it already, aros should be a good starting point.
 
  gunnar, you of all people should see that.
  what you're doing to revive the 68k on the hardware front (bringing modern features to the cpu),
  the same need to be done on the software front. it's so obvious.
 
  think about linux, imagine if in linuxians community they were all saying: yea let's stay at kernel 1.x
 
  or mac people saying macos8 is the holy grail and should stay fully compatible with that for ever .. this is madness.
 
  amigaos3.1 will never cease to exists, it is part of computing history. don't fear it will disappear, noone will go back in time to erase it. it is there forever. but, it doesn't mean it cannot be improved upon.
 
  if the original amigaos team were thinking like you, it would be stuck at amigaos1.0 forever. this is nonsense.
  they improved their designs, they broke compatibility few times, they released new versions, with more modern standards (at the time). they gave you the good example. this is what need to be done.
 
  for example, this is bad:
  2gb memory limitation,
  no unicode,
  no resources tracking
  no smp
  no memory protection
 
  you should all be thankfull aros team made all the fundation work, now join them an explore all kinds of new directions. keep some of the amiga good ideas and concepts then move on, improve upon them.
  this is forward thinking.
 
  wake up and smell the coffee already it's 2020 in a few months. what good is aos3.1 api nowdays ? it brings only terrible limitations.

i'm not saying apollo team has to do it, of course.
i'm saying as a community you should push toward modernizing aos3.1 api, and broadly adopt and support aros. amigaos should serve as inspiration. the rest will follow little by little. 

posts 244page  1 2 3 4 5 6 7 8 9 10 11 12 13