AmigaOS 3.2 released!

[boemann]

I think Thomas just answered everything above. I have nothing to add.

[Minuous]

Originally Posted by Ras Voja

Please include latest MUI5 in next OS 3.3, even as extras install, like with OS 3.5.

MUI was not in OS3.5. And will not be in OS3.3, of course.

[boemann]

No one is preventing you from installing MUI if you like, No one is preventing users to install on a PFS partition. You have the freedom.

Why you would want to install OS on a RAD: is beyond me. Obviously you can just do that, but the interesting thing would be to copy your installation to a rad: sometime at every first boot.

And most importantly why being so agressive. You are clearly angry about a lot of things. Your comments I must admit sound like you don't have complete insight into how things work. Yet you make demands with an attitude as if you know how everything works. That is no way to conduct a constructive dialog.

[Thomas Richter]

Originally Posted by Ras Voja

In short: Its great you think of low end users where OS 3.2 crawls

Actually, I don't really see anything crawling here on my A1200 with its current ACA 1211 (68020 card) installed. The GUI system of the Os is gadtools, and it's quite lightweight, it also became font-aware and scalable with 3.2, so it does everything you need for a slim lightweight GUI. The entire (or the major part) of the Os is gadtools. Prefs is gadtools, HDToolBox is gadtools. Mounter is gadtools. Intellifont is gadtools.



If you need a more complex design, boopsis are part of the intuition system and integrate well into the rest of the design. They are not alien to the rest of the system as MUI is, but are intuition first-class citizens. However, flexibility costs, and it costs for MUI as it does for boopsis, just that boopsis are closer to the system and better integrated into the system.

Originally Posted by Ras Voja

It does not. In 2023 I can show more sw using MUI then Reaction.
Since OS 3.5 this is standard. I know you are just near 3.3 ...

That's probably the reverse on my system, as MUI is for my purpose just too bulky, but well, if you like it, nothing stops you from installing it.

Originally Posted by Ras Voja

Please offer some working method of quick OS install to RAD: that works, beside usual mount RAD: after hdd install, copy all to RAD:, soft reset, pick RAD: from EAB. There is enough RAM on modern accels, I even tested plain and minimal OS 3.1 on 8MB A1200 and its was great experience.

I'm sorry, but which kind of problem you actually want to solve here? Loading Os components so they survive a reboot? That's LoadModule. It's not a RAD:, but it has its own RAM-resident mechanism for that. It needs to, and it cannot be a file system since the ROM-resident mechanism (kicktags) work differently than a file system. However, LoadModule has an interface that allows other components to make the loaded components as ROM-like as possible.

Originally Posted by Ras Voja

You really refuse the support most modern and fast FF that used to be paid and is now free? Sheesh, what about JXFS and other craziness?

But it is supported. You can install it, like any other file system, with the HDToolbox. Actually, the Os is completely flexible on the choice of the file system.

Originally Posted by Ras Voja

HDToolBox improved to be more like Gparted?

If somebody from the Os team picks it up... sure. HDToolBox is pretty old rotten code, and there is lack of time and lack of manpower to do it. Actually, the whole thing should rather be rewritten, but it does what it does.

Originally Posted by Ras Voja

I see rationale in this, but in 2023 I doubt anyone will downgrade from 030 to 080 to 000.

Use case: I have two Amigas. A 68060 in Berlin, a 68030 system in Erlangen, were for testing SoftIEEE I currently installed a 68020 in it. Guess what? It is all exactly the same installation. I did not have to exchange any binaries when swapping the accelerator card. I swapped the 68060 card in my A2000 last summer just to write a driver for the GVP EGS 110 graphics card, and I did not have to touch the installation at all.


That is a *good design* for an operating system. What you are proposing causes quite some trouble in this case.

Originally Posted by Ras Voja

Having option of critical OS parts beeing 030 to 080MMX optimised would be great and paid. VASM can do.

The only part where this would be of advantage would be some picture datatypes. However, in such a case the datatype should have a dynamic dispatcher that runs the best code for the model it currently runs on, same as the math libraries. I'm just skeptical binding the Os to the 68EC080 platform too much as I have reservations on the long term strategy of its owner, but that's just me, and it is a decision the Os team should do, not me.

Originally Posted by Ras Voja

Is there any Vamp support in it? Hype boys have seen Angela at some meeting in OS 3.1.4 days, but he/she now promotes ApolloOS only and screams DDR songs to anyone metioning OS 3.2

Does there need to be any support in it? Frankly, the Os is flexible about third party components. There is a mechanism called "autoconf" that allows such components to register itself to the Os, and load driver components for it. You just need to make use of it. Its maker didn't want that. Not the Os team. So it is more a deliberate decision of Gunnar and friends not to get Os support than a decision the Os team takes. One of the reasons why we don't have 1MB roms is because Gunnar uses the lower ROM for his own purposes - instead of Autoconf, or (failing that) the debug-ROM aka F-ROM area.


It is much less a decision of the Os team. It is much more a strategy decision of a particular hardware vendor not to play by the documented rules of the Os. Actually, the rules you find written down and documented in the RKRMs.

Originally Posted by Ras Voja

Plese, provide VASM or in other way crucial 030 to 080 MMX crucial binaries and selection or detection during install. If really benefits OS in speed. Let this be new scalability.

Not my decision (though I'm fine with it), and not even necessary. Really. See above. Your average Os component would not benefit from it, with some rare exceptions.

Originally Posted by Ras Voja

Its a shame no Vamp, 030 to 060, PFS, AHI, MUI support in 2023?

Huh? The 68060 is perfectly supported by the Os, there is nothing missing. CPU libraries are there, boot support is (now) there. The math libs, and the long-integer support within utility support it all fine. They scale with the processor (yes, really! Different versions of the code are used depending on which processor is found).



PFS is perfectly supported by the Os, such as any other file system, you can boot the system all fine from it, as from any other file system. MUI you can perfectly install yourself if you like that. I fail to see where 68EC080 support would be beneficial, with one exception which I noted above. But I'd rather leave this decision to somebody else.


One way or another: You should probably understand that an Os is something different than a software distribution. The Os delivers the bare-bone components to get the system up and running. It is like a blank sheet of paper, waiting for you to write on it. Don't expect it to be a distribution which provides all sorts of software for all sorts of applications that come to your mind. AmigaOs is not Linux. AmigaOs does not mean "everything is there from day one". AmigaOs means "all the interfaces are there, waiting for components to be used". That some vendors ignore them is more the problem of particular vendors than that of the Os.



What the team probably needs to look into in the future is a somewhat better integrated RTG system, but the interface was already improved a bit during 3.2 development. These are just the tiny nitty-gritty details the average user does not notice, but which make the life of the software developer easier because the low-level interfaces got cleaned up quite a bit.

[tygre]

Originally Posted by Thomas Richter

Don't expect it to be a distribution which provides all sorts of software for all sorts of applications that come to your mind. AmigaOs is not Linux. AmigaOs does not mean "everything is there from day one". AmigaOs means "all the interfaces are there, waiting for components to be used". That some vendors ignore them is more the problem of particular vendors than that of the Os.

+1

But it's hard for people to understand that, even CS/SE students who should know better , because Android, Linux, and Windows "do" everything, from being OSes to providing all kinds of "stacks" (e.g., TCP/IP, Bluetooth, Miracast...) to bundling user interfaces and, of course, applications, like Web browsers...

PS. Although, the last ones were clearly anti-competitive, nothing similar happened for stacks or UI...)

PPS. Funny, isn't it?, how some vendors muddle the water by using a same name to refer to different things: as if "Windows" was one whole thing rather than layers built upon one OS...

Take care!

[Michael]

Well, comparing synthetic performance of FPU only libraries with universal system libs shows some huge margins for some tests while most of the operations are exactly the same, the totals do add up.
If you wish to use cpu specific libs on universally bootable media, you have to take care how to arrange this or face the consequences, using universal libs is much less headache for general user.
How does it effect real life performance is questionable, need a nice test case that can prove it.

v46 v v47 for 68060

mathffpTest
Total time for 1000000 iterations: 16.72 s x 1.42
Total time for 1000000 iterations: 23.84 s

mathieeedoubbasTest
Total time for 1000000 iterations: 17.46 s x 1.17
Total time for 1000000 iterations: 20.48 s

mathieeedoubtransTest
Total time for 1000000 iterations: 81.12 s x 3.76
Total time for 1000000 iterations: 304.76 s

mathieeesingbasTest
Total time for 1000000 iterations: 13.52 s x 1.13
Total time for 1000000 iterations: 15.28 s

mathieeesingtransTest
Total time for 1000000 iterations: 82.44 s x 3.61
Total time for 1000000 iterations: 297.8 s

mathtransTest
Total time for 1000000 iterations: 88.74 s x 3.81
Total time for 1000000 iterations: 337.96 s

[Michael]

Originally Posted by Ras Voja

MUi5 in MOS has none of metioned troubles.

Please, serve us your list

As said, see above. The issues are not effecting fast systems.
And MOS is much faster then fastest classic 060/RTG systems,
that start to choke, and slower systems are totally unusable slow
when simple scroll dragging jumps and system temporary freezes
to complete redraw operation.

[Thomas Richter]

The mathieee libraries are, in the presence of an FPU, just simple wrappers around single instructiosn, so something must be seriously wrong in your setup. The only exception that comes to my mind is Pow() in the doubtrans-libraries, but there are numerical reasons why that is not a simple exp/log. That is a bit different for mathffp which is CPU only, but it is a different number format, and not exactly a good one if you want to do numerics. It's mostly obsolete and only present for historical reasons.

[Michael]

Originally Posted by Thomas Richter

The mathieee libraries are, in the presence of an FPU, just simple wrappers around single instructiosn, so something must be seriously wrong in your setup. The only exception that comes to my mind is Pow() in the doubtrans-libraries, but there are numerical reasons why that is not a simple exp/log. That is a bit different for mathffp which is CPU only, but it is a different number format, and not exactly a good one if you want to do numerics. It's mostly obsolete and only present for historical reasons.

Some tests are identical, but some really fall out, like eg:



IEEEDPPow (1, 9)
Elapsed time: 0.5 s v Elapsed time: 5.3 s
The result should be 9 and it is: 9

IEEEDPPow (2, 0.9247)
Elapsed time: 0.84 s v Elapsed time: 6.2 s
The result should be 0.855070089999999 and it is: 0.855070089999999

IEEEDPPow (0.306, 491.582)
Elapsed time: 4.72 s v Elapsed time: 21.72 s
The result should be 6.66236416397317 and it is: 6.66236416397317

IEEEDPAcos (0)
Elapsed time: 0.42 s v Elapsed time: 5.66 s
The result should be 1.5707963267949 and it is: 1.5707963267949

IEEEDPAsin (0)
Elapsed time: 0.42 s v Elapsed time: 5.48 s
The result should be 0 and it is: 0

IEEEDPAsin (0.5)
Elapsed time: 2.64 s Elapsed time: 10.1 s
The result should be 0.523598775598299 and it is: 0.523598775598299

[Steady]

@Ras_Voja

MUI was never in 3.9 either. Reaction is the main UI stack supplied as part of the OS in 3.5, 3.9 and 3.2. MUI was never a part of the OS as mentioned earlier and if you want it you can install it separately.

[aros-sg]

Originally Posted by Thomas Richter

If you need a more complex design, boopsis are part of the intuition system and integrate well into the rest of the design. They are not alien to the rest of the system as MUI is, but are intuition first-class citizens. However, flexibility costs, and it costs for MUI as it does for boopsis, just that boopsis are closer to the system and better integrated into the system.

MUI is boopsi based too and you can use normal Intuition boopsi gadgets in it's GUIs, too.


The problem with Intuition/Reaction boopsi gadgets is that they are actually "integrated" too much into the system. It's a bad idea to have boopsi code running in input.device system task. Things like mouse pointer moving happens there. So if you have some complex boopsi gadgets and/or a lot of even very simple gadgets and/or a pretty slow system the layout/rendering and sometimes even just input handling causes what to the user looks like freezes (can even last a full second sometimes) or micro freezes. Mouse stuttering. Looks extremely ugly. Also visible with some datatypes in Multiview because datatypes are subclassses of Intuition gadget class.


That's why in Classact/Reaction they have hacks like deferred layout and rendering which make it work MUI-like by doing such things in application task. Which then makes them not real Intuition boopsi gadgets anymore, because it's then no longer "everything handled by system/Intuition in automatic/async way". Instead needs help from application task event loop to handle such defered tasks.

[Michael]

Originally Posted by Ras Voja

So HSMath in some cases can increase FPU ops 5x?

Who knows, we need some real life test, maybe the slower functions are never used by software or very rare, so the difference might be neglectable.
So far only one test in AIBB shows some differences when libs are changed, but even there its around 10%. Test cases welcomed. Maybe some LightWave rendering can show some difference? But that is complex to setup.

[Olaf Barthel]

Originally Posted by mfilos

That is great news Olaf!!! Thanks a lot for that prompt response!
So I guess with the new Ram-Handler I'd use the same hard-link but the IPrefs will correctly update the real file instead of the ENV version?

Can't wait

Once you access the file in "ENV:" for the very first time, ram-handler will copy it from from "ENVARC:" like it did before. But with the updated ram-handler it will no longer trust the name it picked up when it started copying the hard-linked file from "ENVARC:" for the copy created in "ENV:".

What happens instead is that ram-handler will try to use the file name which prompted the contents to be copied from "ENVARC:". Hence, if "ENV:sys/ScreenMode.prefs" was accessed, ram-handler will stick to "ScreenMode.prefs" even if the hard link in "ENVARC:" produces a different name.

[Thomas Richter]

ENV: on RAD: does not really buy you anything. Remember, the RAM handler is now smart enough to pull in data only when they are needed, which is pretty late in the system.

Why are you so obsessed with RAD:? That's not even a very good mechanism for reset-resident data. It always takes the full amount of RAM, no matter whether occupied or not.

LoadModule does not do that, and RAM: does not do that either. Both only take the RAM needed.

[Olaf Barthel]

Originally Posted by tomcat666

Suggestion: Make PFS3 the default file system for OS 3.3 And get rid of the validation problems once and for all.

Not another file system to maintain, please

We already have a lot of "fun" trying to make the old file systems work well enough within their built-in constraints (FFS, RAM-Handler, CrossDOS).

You'd be amazed, shocked and possibly depressed to learn how much of this part of the operating system can work both to the best of its abilities and at the same time being boxed in by constraints chosen between 1985-1987.

A better default file system should be available, but then you'll have to make sure it both satisfies the old constraints (very modest memory usage required, must fit into ROM) and handles every single FFS feature that ever was, including the quirks, bugs and what looks like bugs on first sight but turns out to be a feature.

This is a very, very, very tall order. I tried and kinda succeeded at that with the OS4/MorphOS FastFileSystem but that one fails one of the criteria needed for a replacement: it does not fit into the 68k ROM. It's also noticeably slower than the 68k FFS because it tries hard not to leave the file system data structures in a state which would render them inconsistent. You pay a price for these constraints one way or another.

Yes, we ought to have something better, but it's hard, on top of all the other challenges we already have been spending months on, such as HDToolbox (again).

[Olaf Barthel]

Originally Posted by Ras Voja

Since ENV: is so important, mapping to RAD: area ASAP Or new 512k Violatile ROM/EPROM

Some clever ideas how to simplify its use, backup, edit.

The sad fact is that RAM: is working as intended and surprisingly many operating system features require it to work, specifically because of how it works. RAM: adjusts its own memory footprint dynamically (or at least tries to) and while it creatively lies about how much space it needs to store, it's sort of reliably faking the truth (could be better).

ramdrive.device provides volumes of a fixed size, and on top of that you have a file system with its own memory requirements. This bumps against memory constraints, especially at boot time.

As developers/maintainers, we are limited by these constraints and that leaves little room for choice.

[Thomas Richter]

Protect *from what*? Again, if this is for ROM-Modules, you have this at your fingertips. LoadModule loads modules and "protects them from a reboot", so you do not have to load them again. MuProtectModules provides them from getting overwritten.

What is the actual problem you're trying to solve? RAD: is in most cases not the right answer.

[Olaf Barthel]

Originally Posted by Ras Voja

Dont take easiest of roads, is death sentence in life and even IT

Legacy software maintenance/development has its own peculiar set of freedoms and constraints, I'm afraid...

Forget FFS, focus on PFS3 now. Leave fixes, PFS is already hard proven, even in MOS today.

While the license would permit this, it's just too large for the ROM. My own FFS reimplementation is smaller than pfs3 and it would not fit.

Just do Cross Doss, handlers, default buffers, Repair, Backup & Salv Tools FOR PFS3 AIO - whatever you need, instead of fixing existing (why no backport from oS4 here?)

What would be needed would be a miracle and a code review to identify any possible gaps in the supported API which must be covered so that it could become the default file system. What would the miracle part do? Find space for the FFS and pfs3 to both fit into a severely space-constrained ROM.

Technically, you cannot dispose of the FFS im ROM. You could only "demote" it and let a different file system become the default ROM file system. All of this would have repercussions for the system boot process.

How improved is HD ToolboX (High Definition Torture Room)

In AmigaOS 3.1.4 it was already sufficiently "mature" not to set itself on fire by accident, which was a major step forward. Support for storage devices with more than 2^32 logical block addresses is another significant enhancement. Current work is more like research so that we can get a better understanding of the constraints which HDToolbox would face when cooking up the RigidDiskBlock data structures for the partitions, as well as how far it would be able to make use of these data structures. What does it take to break HDToolbox?

The long term goal is to replace it, but there is also the need to document how to process and validate these RigidDiskBlock data structures, as well as how you would synthesize these based upon the drive parameters. The specifications are surprisingly thin on both accounts.

[Olaf Barthel]

Originally Posted by Ras Voja

Surviving crashes in non mem protected OS that does crash equals data protection plus speed better then Angelas faaaast schneeel MicroSD Cards on FastIDE

If the system crashes, chances are that any memory corruption might have resulted from the crash will affect RAD: and other presumably resident data structures.

Like ram-handler, ramdrive.device is completely oblivious to data corruption. If you are "lucky", then the file system mounted on top of ramdrive.device might detect damage in the metadata information, but if any of the data blocks are damaged, you won't know until something funny happens because of the undetected damage.

Like trackfile.device (an AmigaOS 3.2 addition), the AmigaOS4 ram-handler features optional runtime memory corruption detection via block checksums. Until such a feature is implemented in AmigaOS 68k ramdrive.device and ram-handler (and fits into ROM), you cannot expect your data to be safe

[mfilos]

Originally Posted by Olaf Barthel

Once you access the file in "ENV:" for the very first time, ram-handler will copy it from from "ENVARC:" like it did before. But with the updated ram-handler it will no longer trust the name it picked up when it started copying the hard-linked file from "ENVARC:" for the copy created in "ENV:".

What happens instead is that ram-handler will try to use the file name which prompted the contents to be copied from "ENVARC:". Hence, if "ENV:sys/ScreenMode.prefs" was accessed, ram-handler will stick to "ScreenMode.prefs" even if the hard link in "ENVARC:" produces a different name.

Thanks for the reply Olaf! I get it fully now.
Can we have a Ram-Handler module update to try before next update (3.2.2 etc)?