It is clearly a legal necessity, since code has been trickling down from OS4. Right?
Only under the premise that Cloanto & Hyperion don't find an agreement, or Cloanto wins a case.
Nothing wrong with that per se, but by nilly-willy pulling in OS4 components, the legal situation of the code gets even more entangled.
It depends. It is already complicated with the 3.1 code alone, and it unclear to me in how far this could be released to the public either. Besides, just using 3.1 only for 3.1.4 development wouldn't have made it much simpler. It is Hyperion, after all.
Unlike 3.9? Really. I don't find 3.5 and 3.9 to be very "radical" compared to 3.1, nothing fundamental was changed. With 3.2 there will be quite a few fundamental changes though, like system-startup, loading kickstart components from disk and setting up various devices pre-boot.
The GUI changed with 3.9 due to reaction, and it was the first Os that was 68020 only. 3.2 goes into a different direction.
And this bewilders me - IDEFix97 is named this for a reason - it came about in 1997 - it is more than 20 years ago. And support in other operating systems came along within a few years. And as it turns out, OS3.9 and OS4 also has had support all along... so, is it really experimental?
You surprise me. 3.1.4 has the same sort of "support" for it, as the scsi.device is based on the 3.9 version. Believe there must be reasons in 3.9 *NOT* to enable it by default. As the code I posted shows, it was probably due to an agreement between H&P and Oliver Kastl. The technical reason is likely that, without connecting a second drive, the gates of such adapters may be floating, and then may read whatever was on the bus, so the detection is unreliable and may return false positives.
One way or another, I do not know, and I haven't tested, and what has not been tested does not work.
And refrain from using emulators as test cases?? This is _exactly_ what makes WinUAE so extremely useful, it has pretty much accurate emulation of _tons_ of Amiga hardware - and then the OS developers refuse to touch it? I find this ridiculous!
In this case? Not at all. WinUAE is certainly fine as far as high-level emulation is concerned, but otherwise, it depends very much on models of the hardware that may or may not reflect reality. As for example for the four-way adapters, I'm quite sure it emulates them fine in so far as it makes the detection code happy, but that's not quite what I need. I don't need to test the code in the easy cases. I need to test it in real life, with the effects you get then - such as reading all sorts of nonsense if there is no drive connected.
Just to give you an idea: We couldn't test CDFS audio support either because WinUAE does not emulate it properly, but we had beta testers that could perform the testing. And CDXL support is still missing from it because we cannot test properly.
Yes, it means sometimes that features will go due to lack of hardware. If I get hands on the hardware, I can add support, but only then. As soon as it goes down to the real hardware level, emulation is a fairly bad advice.
Regarding the Reaction classes, I have two issues
* they are not the most efficient, nor the visually prettiest, often looking out of place
It is not efficient because boopsis are not efficient. They use a smalltalk-like dispatcher mechanism where every item on the hierarchy compares a method ID against the methods it supports, so one big lookup per level. The boopsi hierarchy can be pretty deep, so a lot of such dispatcher mechanisms are nested to each other. This makes it inefficient.
Yes, we know, and that's why the GUI is gadtools at this moment. So, it's a complexity that does not matter for you, or for any low-end machine, because it is not used. However, why is it so bad that reaction is delivered, as an option?
* more importantly - they are now considered Hyperion property and part of the "arsenal" against a better future.
Again, why all this hate against Hyperion? The same could be said about Cloanto. Both are commercial enterprises, and want to earn money, in one way or another.
No, "anyone free to have whatever anyone wish" is what I would prefer.
Ah, so once again: What is so bad about shipping Reaction? Don't use it, you're fine. You have a political agenda, and its against this agenda, but I'm talking about the technical aspects.
Old bugs that are _well known_ - which makes a huge difference.
Oh, really? So what's so great about knowing that graphics may trash my memory, and that trackdisk may trash my memory, and there is nothing I can do against it? This does not make me feel very comfortable.
Quite the reverse: With 3.x, such bugs will be addressed, and whatever bugs I get aware of. So what's better? An old rotten os, or one that is receiving updates?
And again I recommend to make a release candidate or two available in the wild for public testing at least for a month or two before burning and selling kickstart chips - it would _REALLY_ help a lot.
Yeah, right... so how would that work as commercial product? Not at all... So once again: Whoever wants to help testing is welcome, but no, it makes no sense to release ROMs to the public because then there is not much of a product left that can be sold.
I do not mind rebooting, I don't know why so many care so much, makes me wonder if their systems are so unstable that boot time is so important.
But you are not the only user. You are one of many users, and there were many voices that rebooting is troublesome. Not for me either, but that is not quite the point.
For me it is more important that systems are easy to debug, that they don't do unexpected things (like picking up some random ROM component from a filesystem that owner is using as download area)
There is nothing "random" at all. What is better? Not to upgrade components if you boot from another location, say a floppy? Or take the updates from another partition? You can easily "prevent randomness" by placing the right components into the boot volue.
Well, if you know different, then please feel free to elaborate.
No, I DO NOT know. That is exactly the point. I do not make promises I cannot hold, so I don't make any. There may or may not be an update, but it all depends on the spare time of the developers.
Necessary? Not at all - cool, but not necessary. But that was not what I was writing, was it - I was writing that what is presented here, with this 3.2 line, is much more of a change over 3.1 than what OS3.5 and 3.9 ever was.
No, not really. It is just a different direction. 3.9 was supposed to target "higher end machines", hoping for more to come. This did not become true. 3.2 is a different direction. Target all the hardware that is out in the wild, but do not add features that add complexity.
The "GUI" was not changed in 3.9 either, less so, as it was still good old 3.1 Intuition.
It changed pretty much for me.
Now we have Intuition.library v45 - based on original sources and rewritten from scratch, as the OS4 advert says... ![Smiley :)](https://forum.amiga.org/Smileys/default/smiley.gif)
I don't know which intuition Os 4 has, but the one we have has still all the original comments in it and is hence based on the original. It is just a very elaborate port of the greenhill C source of intuition, which could not compile "as is" on SAS/C due to some features the SAS does not offer.
Nothing - I welcome this. Too bad it will be entangled with Hyperion legalese.
And what's the "bad" part about it? This is exactly your problem. Hyperion is a commercial enterprise, Cloanto is another. If it would be under Cloanto, it would be "entangled by Cloanto legalese".
Well, I prefer this turned off, as it does not fit with my "workflow" where I often push windows to the screen border, or resize against a screen border. I would very much prefer to set qualifier that I can hold if I wish to drag windows off-screen. Also, without being able to have windows larger than screen, I really see very little use for it at all.
I may have forgotten that v45 implements a certain "resistance" of windows getting moved out of the screen. So you have to "push a bit harder" to move them.
It makes just as much sense as development of a retro-os on an original outdated CPU - sensewise, OS3 and OS4 are in the same boat.
I don't really see that. Os 4 started as obsolete Os on new hardware, hoping for more to come. At this time, the hardware is old, unpopular, expensive and outdated, without ever reaching the market penetration. 68K hardware is old, but has a history - like an oldtimer - that is worth preserving. The difference is the software collection - there is much more 68K software than PPC software that makes the 68Ks worth using.
And nothing prevents you. The point of AROS was to scratch an itch, not to offer a product, nor to please anyone else but the developers themselves. Not like your work has much more point.
Which itch? "We cannot do an Os either?" Yes, I see that, but what's the point?