@pavlor

Yes, instead of chasing hardware, the OS4 developers should rather focus on improving OS4 on emulated environment - their largest audience. They could even bundle OS4 with a PPC emulator, Qemu works on all relevant platforms.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

They could even bundle OS4 with a PPC emulator, Qemu works on all relevant platforms.

Yeah. So long as the bundled emulator is optional; I would rather use the version of Qemu in the Debian repository, since it (presumably) gets timely security updates, and a bundled version might not.

The Amiga community is not really tuned in to security much, probably because a) It's small, and not a likely target, and b) The OS is like swiss cheese, so what's the point.

Last edited by bison on 11-Aug-2018 at 04:33 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@pavlor
Quote:

pavlor wrote: @cdimauro Quote: Actually it's only composition which is missing on WinUAE, right? Sloooow network, sloooow disk I/O, slooooow FPU (well, Tabor is in the same boat...), slow GFX (2D), no 3D, no compositing, max RAM limitation (cca 640 MB is safe boundary, not much luck with more RAM).

Regarding the RAM, it's strange. AFAIR it should be able to use 1GB or even more RAM. Maybe you can ask on EAB.

For the rest, is it in your opinion everything "mandatory" / to have, or do you think there's a subset of features/things that are really important (to have / be fixed)?

@kolla

Quote:

kolla wrote: @pavlor Yes, instead of chasing hardware, the OS4 developers should rather focus on improving OS4 on emulated environment - their largest audience. They could even bundle OS4 with a PPC emulator, Qemu works on all relevant platforms.

A QEmu-only version should be better: no full Amiga to emulate, and no slow communications between Amiga and PPC board.

@bison

Quote:

bison wrote: @kolla Yeah. So long as the bundled emulator is optional; I would rather use the version of Qemu in the Debian repository, since it (presumably) gets timely security updates, and a bundled version might not.

*
Quote:

The Amiga community is not really tuned in to security much, probably because a) It's small, and not a likely target, and b) The OS is like swiss cheese, so what's the point.

Amiga and security are oxymora...

@matthey
Quote:

matthey wrote: I agree. Full AmigaOS compatibility is *not* possible with modern features but I wonder if some loss of compatibility and modern features is acceptable. AmigaOS 4 introduced memory protection over a decade ago but likely couldn't use it fully because of compatibility.

AFAIK OS4 only catches accesses over non-allocated / free memory (not really all free memory. I assume that they are free/unallocated pages).

Certainly better than nothing, but still far away from a modern o.s..
Quote:

Part of the problem may be wanting to turn features on completely (all or nothing). If AmigaOS allowed to turn certain security settings up, then new programs could be designed and tested using higher security settings and some people using only newer software would eventually be able to run in a more protected AmigaOS. Security Prefs Memory Protection o none (best performance, no memory usage, best legacy compatibility) o low (high performance, low memory usage, high legacy compatibility) o medium (medium performance, medium memory usage, medium legacy compatibility) o high (low performance, high memory usage, low legacy compatibility) Resource Tracking o off (no memory usage) o on (low memory usage) Multi-user o off (no memory usage) o on with low security (no inactivity logouts, GID ignored) o on with medium security (inactivity logouts, GID) o on with high security (inactivity logouts, GID, annoyances) Supervisor/Interrupt Code o allowed (best legacy compatibility) o not allowed (reduced legacy compatibility) This offers scale-ability from low end to high end systems, modularity and maximum compatibility.

I don't think that it can work. If you think at the worst case (enabling all protections), you end up having a very different operational work for the o.s., which doesn't resemble the Amiga one.

And imagine this new implementation where you have to change the o.s. behavior on-the-fly, according to what the user wants: it's a nightmare for the o.s. developers and runtime execution.

However the biggest problem here is that you don't know the applications behavior. You don't know if an application matches (works) on one of the above (new) configurations, so you don't know how to set the o.s. behavior accordingly. But once you find some working configurations for it, then you can run another application which might not be compatible with those configurations; hence you can run only the first or the second app. And so on: you can imagine that handling all different behaviors at the same time is practically impossible.
Quote:

The Amiga may not be able to match the security features of other modern operating systems but I think it would have trouble competing in the high end anyway. Windows can't compete on the low to mid performance CPUs with the AmigaOS for performance and memory usage. All that security and abstraction gives a steep penalty to performance. I had a Pentium M Windows XP laptop with faulty fan dropping the clock to 800MHz and making it less responsive than my 68060 Amiga (the Pentium M is many times faster).

Try Windows 10.
Quote:

Security is nice but how much performance and compatibility are users willing to trade?

Security is one of the most important (if not even the most) things to have for a modern o.s. nowadays, especially if you think to the kind of people which uses an o.s..

So, the question here is quite simple: what would be the target/audience for a "modernized" Amiga o.s.? "O.s. for the masses" (cit.) or for the small niche of post-Amiga fans?
Quote:

If moving to a 64 bit little endian ISA, it makes sense to break all compatibility and start over. This is what AROS x86_64 is doing although poor MMU support is holding up the memory protection.

Not really. AROS x64 breaks compatibility, yes, but only against AROS x86 binaries, because:
- the ABI changed (v1 vs v0);
- there's no 32 & 64 bit applications support (michaelsc talked about it into another thread).

One of AROS goals, from the very beginning, was/is to have source-level compatibility with the Amiga o.s. 3.1, and binary compatibility only for the 68K flavor.

So, AROS x64 didn't really broke any compatibility: it's a legit AROS flavor.
Quote:

AROS does have SMP and partial resource tracking.

Only SMP AFAIR, and it's still an experimental branch.
Quote:

I don't see AROS being successful for the x86_64 because of stiff OS competition which has more features and software.

True. In fact, it's an hobby o.s., with no claim to become / battle with mainstream o.s.es.
Quote:

Gaining software support and developers is an uphill battle without selling mass produced hardware.

x64 is the most sold hardware in the desktop market segment, so we already have mass produced hardware, and there's no need for new hardware (unless you want to support another mass produced hardware: ARM).

@Hypex

Quote:

Hypex wrote: @bison It's the in thing. AmigaOS is written in the in language of the day. Which is now C++. However I gave a few other choices. My point was that even in '93 or so Commodore added things that needed an OOP language. Instead it was hacked into C which looked messy as well as not making sense when I read the autodocs (having no concept of OOP at the time). It was obvious they need to use a real OOP language for the job. The tradition of hacking OOP methods into a C interface continues today. They did a better job of it. But still failed to migrate the messy OOP functions over from datatypes or BOOPSI.

I've already talked about in my previous reply to you, but let me add another thing.

An o.s. usually gives (or should give) a nice set of APIs for handling graphic/UI objects (controls, widgets, gadgets, ... whatever you want to call them), and those are mostly "primitive" objects. The interface, as said, should be exposed in C, which is the current "lingua franca", but the implementation can be realized in C++, Object Pascal, or what you want.

So, this is the base set of UI objects which are exposed by the o.s., albeit without an OOP interface/behavior (C has no objects support). And here is and should be were the o.s. stops its work.

If you want more, realizing a real OOP hierarchy, then you wrap those basic / "rough" objects into a framework which might be written in some OOP language, providing the usual OOP behavior usage which all we know, and providing also support for OO inheritance and polymorphism.

In a few words: look at the work which Borland did with its wonderful VCL framework (written in Delphi, but "consumed" by Borland's C++ IDE as well).

TL;DR: introducing OOP at the o.s. level is NOT recommended.
Quote:

On a similar note, I once asked somebody, familar with Windows API, if there was an OpenWindow() or similar function for Windows. It's called Windows, of course there would.

CreateWindow: https://msdn.microsoft.com/en-us/library/windows/desktop/ms632679(v=vs.85).aspx
CreateWindowEx: https://msdn.microsoft.com/en-us/library/windows/desktop/ms632680(v=vs.85).aspx
Quote:

But I was told it didn't exactly. It has this MFC thing for a Microsoft Foundation Class and it derived from there. Now at this point I still had no idea of what OOP was. Only knowing about proecedual. So I didn't understand what this class thing was about. Nor how it worked without an OpenWindow() routine.

MFC is an example of what I've written just before: it's a framework built on top of the o.s. Win32 ui objects & APIs. But it's NOT part of the o.s.: it's provided by a company (OK, it's Microsoft) and supports a specific language (C++). VCL (which is/was my favorite) is another example.

That's what should happen at the user land: custom OOP frameworks built on top of the o.s. (not OOP) APIs.

EDIT. Just saw now this:
@gregthecanuck

Quote:

gregthecanuck wrote: @Hypex Quote: On a similar note, I once asked somebody, familar with Windows API, if there was an OpenWindow() or similar function for Windows. It's called Windows, of course there would. But I was told it didn't exactly. It has this MFC thing for a Microsoft Foundation Class and it derived from there. Now at this point I still had no idea of what OOP was. Only knowing about proecedual. So I didn't understand what this class thing was about. Nor how it worked without an OpenWindow() routine. Your source wasn't familiar with the Windows API. The base win32 function is called "CreateWindow". One of the inputs is the class (window, button, listview, etc...). https://msdn.microsoft.com/en-us/library/windows/desktop/ms632679(v=vs.85).aspx All class libraries in the end call CreateWindow. MFC, .Net, Borland VCL, ...

Which is what I was talking about.

Sorry for the duplicate...

Last edited by cdimauro on 11-Aug-2018 at 06:46 PM.

@bison
Quote:

bison wrote: @hth313 I never made it up the learning curve on Haskell, so I'll have to take your word on that. I agree that the maintenance factor is important. I don't have any real preference between perl and python when writing new code, but if I have to work on someone else's code, I would much rather that it be python.

"Python is executable pseudocode. Perl is executable line noise." (cit.)

@cdimauro

Quote:

x64 is the most sold hardware in the desktop market segment, so we already have mass produced hardware, and there's no need for new hardware (unless you want to support another mass produced hardware: ARM

I do like the idea of using RPi3 as an "Amiga," even though it's kind of under-powered for a desktop system (although likely no worse than Tabor as far as CPU -- Tabor would have more RAM). It would be nice for developers to have a single system to target. With x86_64 you end up with millions of combinations of hardware. I've been using Linux for 20 years, and every time I install on a new system there's always some weird hardware thing I have to resolve.

The other nice thing is that the RPi3 uses the Cortex A53, which is immune to Spectre and Meltdown.

https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown

Last edited by bison on 11-Aug-2018 at 07:24 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@cdimauro

Quote:

Regarding the RAM, it's strange. AFAIR it should be able to use 1GB or even more RAM. Maybe you can ask on EAB.

Probably limitations of Z3 space when using several Z3 and PCI devices.

Quote:

For the rest, is it in your opinion everything "mandatory" / to have, or do you think there's a subset of features/things that are really important (to have / be fixed)?

Mandatory, I fear. Slow GFX and disk I/O are least desired for any UI. Waiting to download files is annoying. FPU/3D are necessary for any avid gamer like myself - well I can probably stay with 2D games, so the last one has lower priority.

Quote:

cdimauro wrote: AFAIK OS4 only catches accesses over non-allocated / free memory (not really all free memory. I assume that they are free/unallocated pages).

I expect it protects and catches zero page hits also. In my experience, these are more common than reusing deallocated memory. ThoR's MMU libraries on the 68k protect and catch zero page hits also. Protecting code sections should have good compatibility as well. These are high compatibility, high performance and low memory protection but are already quite effective. I couldn't find much info online on what AmigaOS 4 protects.

I wonder how much of AmigaOS 4's lack of memory protection is due to 68k compatibility. Supporting two architectures of code and executables certainly increases the complexity of trying to add more complete memory protection. Sadly, I don't think AmigaOS 4 can afford to drop 68k compatibility but moving to a little endian architecture (AArch64 or x86_64) would practically force them to.

Quote:

I don't think that it can work. If you think at the worst case (enabling all protections), you end up having a very different operational work for the o.s., which doesn't resemble the Amiga one. And imagine this new implementation where you have to change the o.s. behavior on-the-fly, according to what the user wants: it's a nightmare for the o.s. developers and runtime execution. However the biggest problem here is that you don't know the applications behavior. You don't know if an application matches (works) on one of the above (new) configurations, so you don't know how to set the o.s. behavior accordingly. But once you find some working configurations for it, then you can run another application which might not be compatible with those configurations; hence you can run only the first or the second app. And so on: you can imagine that handling all different behaviors at the same time is practically impossible.

The low memory protection setting could work as I stated above. ThoR's MMU library is doing all but protect code sections as read only which could be moved to medium memory protection if there were too many incompatibilities. The medium memory protection setting might require the sections/hunks to have flags for the memory protection type like read only, no execute, r/w, etc. Without the flags, the executable will not run and pops a requester stating why. Yes, all old Amiga software would *not* run in this mode but existing software hunks could have the flags added by patching from knowledgeable developers. The high memory protection would probably require major OS changes and quite some thinking through. It would probably not be available at first and I don't know if it would include a new API for shared memory message passing (I expect shared memory message passing is less of a security threat than a CPU which is vulnerable to Spectre).

Developers of new software would have a target to aim for and test on. It would take a while to make the AmigaOS compatible with higher security settings. A reboot and/or password may be required to change some security settings. I don't think it adds too much complexity to the executable loader. I think it costs less than having a whitelist/blacklist of compatible executables. It would provide complete compatibility and support the smallest footprints. Anyway, it was a good idea to try to get developers thinking about what is possible.

Quote:

Try Windows 10.

I have heard that it is faster than Windows 7 but I doubt it is faster than XP. I have also heard that many people don't like it. It's funny that Windows "security" doesn't include gathering the users information and spying. A friendly protected OS which doesn't collect personal data and tries to protect the user from Big Brother would probably have appeal.

Quote:

So, the question here is quite simple: what would be the target/audience for a "modernized" Amiga o.s.? "O.s. for the masses" (cit.) or for the small niche of post-Amiga fans?

A friendly OS is for the masses of course. The Amiga niche failed. It's kind of like a stadium where the trend is to have a smaller size and charge more. As the stadium gets smaller, the mass appeal drops until finally there is little demand for the high priced seats. The team can no longer afford good players and the appeal drops more. More fans leave and the situation gets worse with the death spiral. That is where the PPC Amiga is now.

Quote:

Quote: If moving to a 64 bit little endian ISA, it makes sense to break all compatibility and start over. This is what AROS x86_64 is doing although poor MMU support is holding up the memory protection. Not really. AROS x64 breaks compatibility, yes, but only against AROS x86 binaries, because: - the ABI changed (v1 vs v0); - there's no 32 & 64 bit applications support (michaelsc talked about it into another thread). One of AROS goals, from the very beginning, was/is to have source-level compatibility with the Amiga o.s. 3.1, and binary compatibility only for the 68K flavor. So, AROS x64 didn't really broke any compatibility: it's a legit AROS flavor.

AROS x86_64 did *not* break compatibility with AROS but it did break binary compatibility with AmigaOS 68k. This is likely what would happen with moving AmigaOS 4 to x86_64. I don't think AmigaOS 4 can stand on its own any more than AROS x86_64. Losing 68k binary compatibility would be especially painful as this is where most of the software for AmigaOS 4 comes from (another sign of the failure of the PPC Amiga after all these years).

Quote:

Quote: AROS does have SMP and partial resource tracking. Only SMP AFAIR, and it's still an experimental branch.

AROS has partial primitive resource tracking.

http://aros.sourceforge.net/documentation/developers/app-dev/resource-tracking.php

It's not very useful when it can't release resources on a crash but it is a start. Memory protection is needed with resource tracking for proper crash recovery.

Quote:

Quote: Gaining software support and developers is an uphill battle without selling mass produced hardware. x64 is the most sold hardware in the desktop market segment, so we already have mass produced hardware, and there's no need for new hardware (unless you want to support another mass produced hardware: ARM).

It is possible to do something different rather than become and compete with them. The further you are from them the more freedom there is for creativity and a unique product. There is no unique for those assimilated by the darkness.

Quote:

bison wrote: I do like the idea of using RPi3 as an "Amiga," even though it's kind of under-powered for a desktop system (although likely no worse than Tabor as far as CPU -- Tabor would have more RAM). It would be nice for developers to have a single system to target. With x86_64 you end up with millions of combinations of hardware. I've been using Linux for 20 years, and every time I install on a new system there's always some weird hardware thing I have to resolve.

The Raspberry Pi does have an Amiga feel (minimalist, efficient, standardized hardware for the masses). Other than it being little endian and already having too many operating systems, it would be a good target for an AmigaOS. The Tabor CPU is probably more powerful per core per MHz integer performance but the Pi3 has twice as many cores and full FPU and SIMD units.

Quote:

The other nice thing is that the RPi3 uses the Cortex A53, which is immune to Spectre and Meltdown.

The A53 is a simple in order energy efficient 64 bit ARM CPU. It is immune to Spectre because it is simple. The performance is nothing spectacular but that didn't stop millions of people from buying it. It certainly has more to offer than the Tabor for the price. I'm pretty sure the Tabor and x5000 CPUs are vulnerable to Spectre (NXP says to contact them but it is likely all of their current PPC CPUs are flawed and unlikely to ever be fixed). Pretty much every PPC after the G3 and a G4 variant or two are likely vulnerable. Meltdown is Intel specific and nothing for the AmigaOS to worry about.

@matthey

Quote:

Other than it being little endian...

I think it has a bit that can be set by the OS at run-time to change endianess, doesn't it?

Quote:

...and already having too many operating systems, it would be a good target for an AmigaOS.

No such thing.

_________________
"Unix is supposed to fix that." -- Jay Miner

Quote:

bison wrote: I think it has a bit that can be set by the OS at run-time to change endianess, doesn't it?

Yes, but the SETEND instruction to change "data" endianess is or at least was deprecated in ARMv8/AArch64.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/BABEGIJE.html

I believe SETEND still works in most ARMv8 CPUs but it may go away in the future. ARMv7 compatible CPUs need it for compatibility but I wouldn't be surprised if it disappeared in AArch64 only CPUs. Many of the RPi operating systems still operate in 32 bit ARMv7 mode for compatibility with earlier RPis. Thumb2 really helps with the limited memory of some RPi variations which could have as little as 128MB of memory for the CPU. Some people complain about only having 1GB of memory on the newer models (a 68k AmigaOS with 1 GB would be a dream in comparison).

Quote:

Quote: ...and already having too many operating systems, it would be a good target for an AmigaOS. No such thing.

From a user perspective, yes. From an OS provider perspective trying to penetrate the market, no.

I would like to see AROS ARM improve for the RPi. It might get interesting if the SMP support was enabled. The price would be right. It makes more sense if giving up 68k compatibility and going little endian. Otherwise it is kind of a hack to use the deprecated SETEND to maintain big endian compatibility when it could disappear. This is a good example of where it is nice to have custom hardware to control your own destiny. ARMv7 allowed this kind of customization but ARMv8 took it back in the name of standardization (which has advantages as there were too many variations of ARM before).

@bison
Quote:

bison wrote: @cdimauro I do like the idea of using RPi3 as an "Amiga," even though it's kind of under-powered for a desktop system (although likely no worse than Tabor as far as CPU -- Tabor would have more RAM).

Yes, it's underpowered for "desktop".
Quote:

It would be nice for developers to have a single system to target. With x86_64 you end up with millions of combinations of hardware. I've been using Linux for 20 years, and every time I install on a new system there's always some weird hardware thing I have to resolve.

The problem with x64 is related to the chipset, and not to the processor/ISA.

But if you compare the two ecosystems, ARM is in a much worse condition from this point-of-view: there are far more combinations of hardware. Consider that, if I recall correctly what I've read some years ago (and you can imagine how the situation can be now), the amount of code for ARM support on Linux is TRIPLE in size compared to x86/x64. Torvalds was literally pissed-off (which isn't a surprise ) for this situation...
Quote:

The other nice thing is that the RPi3 uses the Cortex A53, which is immune to Spectre and Meltdown. https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown

I wouldn't consider security issues for comparisons: all hardware platforms are, more or less, affected for their out-of-order implementations. And at least for x86/x64 there are patches available.


@matthey
Quote:

matthey wrote: The Raspberry Pi does have an Amiga feel (minimalist, efficient, standardized hardware for the masses). Other than it being little endian and already having too many operating systems, it would be a good target for an AmigaOS. The Tabor CPU is probably more powerful per core per MHz integer performance but the Pi3 has twice as many cores and full FPU and SIMD units.

The Amiga o.s. is intrinsically single core/thread, so you'll not use the extra cores.

And SIMD isn't used as well.
Quote:

The A53 is a simple in order energy efficient 64 bit ARM CPU. It is immune to Spectre because it is simple. The performance is nothing spectacular but that didn't stop millions of people from buying it. It certainly has more to offer than the Tabor for the price. I'm pretty sure the Tabor and x5000 CPUs are vulnerable to Spectre (NXP says to contact them but it is likely all of their current PPC CPUs are flawed and unlikely to ever be fixed). Pretty much every PPC after the G3 and a G4 variant or two are likely vulnerable.

Interesting information. Thanks.
Quote:

Meltdown is Intel specific and nothing for the AmigaOS to worry about.

Of course: the Amiga o.s. itself is fully open, and doesn't need Meltdown for accessing the kernel memory.
Quote:

matthey wrote: I would like to see AROS ARM improve for the RPi. It might get interesting if the SMP support was enabled.

It might require specific code for ARM compared to x64, but maybe michaelsc can give some insider information here.
Quote:

The price would be right. It makes more sense if giving up 68k compatibility and going little endian.

An o.s. should be endianess-agnostic.

68K compatibility can come as usual: due to an emulated environment/sandbox, and Icaros already provided it (albeit I never checked, and Hypex says that it's not working).
Quote:

Otherwise it is kind of a hack to use the deprecated SETEND to maintain big endian compatibility when it could disappear. This is a good example of where it is nice to have custom hardware to control your own destiny. ARMv7 allowed this kind of customization but ARMv8 took it back in the name of standardization (which has advantages as there were too many variations of ARM before).

Well, the point is that, whether we like or not, little-endian clearly "won" here, and such aggressive processors features are vanishing for good reasons.

Having specific instructions for endianess conversion is much easier/cheaper, and it's enough for emulation and networking purposes.

@pavlor

Quote:

pavlor wrote: @cdimauro Quote: Regarding the RAM, it's strange. AFAIR it should be able to use 1GB or even more RAM. Maybe you can ask on EAB. Probably limitations of Z3 space when using several Z3 and PCI devices.

I've managed to get around 1.7GB of memory with my more advanced WinUAE configuration (with 128MB of UAE RTG memory). Of course the emulated PowerPC board will take some space here, but I don't think that it consumes so much address space.

Maybe you need to tweak a bit your configuration to get more memory.
Quote:

Quote: For the rest, is it in your opinion everything "mandatory" / to have, or do you think there's a subset of features/things that are really important (to have / be fixed)? Mandatory, I fear. Slow GFX and disk I/O are least desired for any UI. Waiting to download files is annoying.

I think that directly using QEMU will improve the I/O and networking performance.

Fixing slow GFX requires the direct (tunneled, in reality) access to the graphic card, and for this maybe a bounty is needed.
Quote:

FPU/3D are necessary for any avid gamer like myself - well I can probably stay with 2D games, so the last one has lower priority.

Well, Tabor has a poor FPU, so I think that at least this QEMU feature we can be put on hold, right?

I don't know how many 3D games are available for OS4, and if it makes sense to have 3D support. To be more clear and direct: are there killers apps/games (e.g.: NOT available on other o.ses like Linux, Windows, etc.) which deserves 3D support?

@bison

Quote:

The Amiga community is not really tuned in to security much, probably because a) It's small, and not a likely target, and b) The OS is like swiss cheese, so what's the point.

Indeed, and I would add c) ignorance :)

It was somewhat amusing to see all those who were first concerned and then relieved as they learnt how Amiga systems were not really affected by Meltdown and Spectre.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

I've managed to get around 1.7GB of memory with my more advanced WinUAE configuration (with 128MB of UAE RTG memory).

Did you use PCI devices?

Quote:

I think that directly using QEMU will improve the I/O and networking performance.

I hope so.

Quote:

Fixing slow GFX requires the direct (tunneled, in reality) access to the graphic card, and for this maybe a bounty is needed.

Too distant future...

Quote:

I don't know how many 3D games are available for OS4, and if it makes sense to have 3D support. To be more clear and direct: are there killers apps/games (e.g.: NOT available on other o.ses like Linux, Windows, etc.) which deserves 3D support?

That would be quite lame excuse, don´t you think? Why use crippled emu, when real hardware does everything better and faster?

@matthey
Quote:

matthey wrote: I expect it protects and catches zero page hits also. In my experience, these are more common than reusing deallocated memory. ThoR's MMU libraries on the 68k protect and catch zero page hits also.

I agree. And this is cheap to have/implement.
Quote:

Protecting code sections should have good compatibility as well. These are high compatibility, high performance and low memory protection but are already quite effective. I couldn't find much info online on what AmigaOS 4 protects.

AFAIK they didn't turned on protection for code sections due to incompatibilities found with some applications. But I might recall wrong. It'll be good to have some reliable information here.
Quote:

I wonder how much of AmigaOS 4's lack of memory protection is due to 68k compatibility. Supporting two architectures of code and executables certainly increases the complexity of trying to add more complete memory protection.

It's reasonable to assume it.
Quote:

Sadly, I don't think AmigaOS 4 can afford to drop 68k compatibility but moving to a little endian architecture (AArch64 or x86_64) would practically force them to.

The same happens with 32-bit little-endian and 64-bit big-endian architectures (and that's why they cannot even move to 64-bit PowerPC).
Quote:

The low memory protection setting could work as I stated above. ThoR's MMU library is doing all but protect code sections as read only which could be moved to medium memory protection if there were too many incompatibilities. The medium memory protection setting might require the sections/hunks to have flags for the memory protection type like read only, no execute, r/w, etc. Without the flags, the executable will not run and pops a requester stating why. Yes, all old Amiga software would *not* run in this mode but existing software hunks could have the flags added by patching from knowledgeable developers. The high memory protection would probably require major OS changes and quite some thinking through. It would probably not be available at first and I don't know if it would include a new API for shared memory message passing (I expect shared memory message passing is less of a security threat than a CPU which is vulnerable to Spectre). Developers of new software would have a target to aim for and test on. It would take a while to make the AmigaOS compatible with higher security settings. A reboot and/or password may be required to change some security settings. I don't think it adds too much complexity to the executable loader. I think it costs less than having a whitelist/blacklist of compatible executables. It would provide complete compatibility and support the smallest footprints. Anyway, it was a good idea to try to get developers thinking about what is possible.

OK, but previously I was talking only about existing applications, and without patching their binaries adding flags or their sources adding some new code. So, the worst (and likely common) scenario.

It's fine thinking about new o.s. and new apps, but here I think that it's better to turn everything on. However new code without message passing is not trivial at all to implement, both at the o.s. and apps level: it's a radical, totally different implementation.

Regarding Spectre, there are patches and most of the systems are already working fine. Without message passing "ala Amiga o.s.".

Anyway, I don't think that the presence of Spectre can be used to justify the intrinsic insecurity of the Amiga o.s. and its application, where everything is public/shared. And that's something which is NOT acceptable nowadays for a modern o.s..
Quote:

I have heard that it is faster than Windows 7 but I doubt it is faster than XP.

Microsoft made a HUGE effort to optimize Windows in order to make it work/run on very low-end hardware platforms, like tablets and smartphones.

I've a Compute Stick with just 32GB of eMMC, 2GB of RAM, and a BayTrail CPU, which runs "good enough" for regular/common jobs.
Quote:

I have also heard that many people don't like it. It's funny that Windows "security" doesn't include gathering the users information and spying. A friendly protected OS which doesn't collect personal data and tries to protect the user from Big Brother would probably have appeal.

This isn't about security but privacy, and we're talking about ANONYMOUS data which are transfered.
Quote:

A friendly OS is for the masses of course. The Amiga niche failed. It's kind of like a stadium where the trend is to have a smaller size and charge more. As the stadium gets smaller, the mass appeal drops until finally there is little demand for the high priced seats. The team can no longer afford good players and the appeal drops more. More fans leave and the situation gets worse with the death spiral. That is where the PPC Amiga is now.

OK, I agree, but this requires also an o.s. with all modern features. Do you agree?
Quote:

AROS x86_64 did *not* break compatibility with AROS but it did break binary compatibility with AmigaOS 68k.

Well, this happens with ALL AROS variants except the 68K one of course.

As I said before, AROS goal is to have source-level compatibility for all variants, and binary only for 68K.
Quote:

This is likely what would happen with moving AmigaOS 4 to x86_64. I don't think AmigaOS 4 can stand on its own any more than AROS x86_64. Losing 68k binary compatibility would be especially painful as this is where most of the software for AmigaOS 4 comes from (another sign of the failure of the PPC Amiga after all these years).

Emulation is there for it.
Quote:

AROS has partial primitive resource tracking. http://aros.sourceforge.net/documentation/developers/app-dev/resource-tracking.php It's not very useful when it can't release resources on a crash but it is a start. Memory protection is needed with resource tracking for proper crash recovery.

This requires change to applications, whereas I was referring to the o.s. which manages itself resource tracking (like enabling SMP).
Quote:

It is possible to do something different rather than become and compete with them. The further you are from them the more freedom there is for creativity and a unique product. There is no unique for those assimilated by the darkness.

What do you mean with "darkness"?

Anyway, it's very difficult for a new ISA (or an old one which is updated) to enter the market. I've talked 5 years ca. with Jean-Louis Gassée (former Be Inc. CEO) about my ISA, and he clearly stated that it's very unlikely that this can happen, and venture capitalist (like him) find it extremely risky...

@matthey

Quote:

Losing 68k binary compatibility would be especially painful as this is where most of the software for AmigaOS 4 comes from (another sign of the failure of the PPC Amiga after all these years).

Are you sure?
My OS4/MorphOS systems are rather clean for 68k cruft, there really isn't that much "must have" 68k software that doesn't have some OS4/MorphOS equivalent, and what "must have" 68k software that does exist mostly doesn't work well on OS4 anyways, due to lack of Amiga chipset.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@pavlor
Quote:

pavlor wrote: Did you use PCI devices?

Not that I know. Do you need a PCI device?
Quote:

I hope so.

Well, currently you have to pass from PowerPC to 68K side for peripherals, which will not happen anymore directly running QEMU.
Quote:

Too distant future...

How long are you waiting for an affordable real hardware for OS4? And I'm not referring only to Tabor.
Quote:

That would be quite lame excuse, don´t you think? Why use crippled emu, when real hardware does everything better and faster?

Because that was what we were talking about? Using emulation to replace real hardware.

Once you use QEMU for OS4, you have already a (modern) o.s. where you can directly run Doom, Quake, and in general whatever 3D game which was PORTED to OS4, and with a MUCH BETTER experience.

So, what's the point on having those games running on OS4?

A lame excuse is, on the exact contrary, pretending to run them on OS4 when you're using an hosted environment: it doesn't make sense at all!

Last but not really least, this part of the discussion was about MANDATORY / NEED TO HAVE features for running OS4, as I asked before to you. If there's NO killer 3D app/game for OS4, then 3D support isn't anymore mandatory.

@kolla: I agree with your last messages.

@cdimauro

Quote:

Not that I know. Do you need a PCI device?

I use PCI sound and Ethernet cards in WinUAE config.

Quote:

Once you use QEMU for OS4, you have already a (modern) o.s. where you can directly run Doom, Quake, and in general whatever 3D game which was PORTED to OS4, and with a MUCH BETTER experience.

Point of "Amiga NG" is to use Amiga enviroment as much as possible, not as mere another application on host OS. The less the host OS is visible, the better.

Quote:

A lame excuse is, on the exact contrary, pretending to run them on OS4 when you're using an hosted environment: it doesn't make sense at all!

This is AmigaWorld, you get used to that things doesn't make sense at all. Logic, reason or common sense aren´t qualities one can expect form Amiga users. Pure passion, nothing less, nothing more.