Hyperion: "Halloween special double-treat for the Classic AmigaOS"

[Gulliver]

What we have here is a straight recompile from the last 3.1 sources, so nothing else has been updated and no code from 3.9 has been integrated here. It is just a straight compile of the kickstart sources in the subversion.  Some of the fixes here are actually superfluous with 3.9. For example, the bug in the exec memory pools is typically patched over by SetPatch which replaces the rather simplistic pool algorithm in the ROM by a completely different and smarter algorithm.  Nevertheless, we have to see whether there will be a follow-up update. I still have a couple of fixes in the drawer, along with the newer shell and the newer layers.

I am wondering why didn´t Olaf Barthel include the already available 68k binaries that Hyperion had developed for OS4. There are a lot of components of AmigaOS 3.1 which could have been updated this way:

cpu 50.4 (that can detect  68060 and ppc processors)
iconedit 44.20 (that can edit glowicons)
playcd 50.5 (that can access cd databases online to identify discs)
ContextMenus 51.3 (a kind of non blocking configurable magicmenu clone)
Atapiismajik 52.1 (a kind of idefix97 clone)
 
And of course there are, between other things a couple of math libraries and scsi.devices that could have been pretty usefull.

So why didnt he include them if they are already compiled, tested, released, and property of Hyperion?

[Gulliver]

Finally, I doubt the wisdom in including such a large (it's one single file), complex assembly language implementation in the operating system. It's bad enough that we have to deal with the FFS and the scsi.device driver family, and even dos.library. There is a place for assembly language code in the operating system, but in my opinion the solution should match the problem at hand in terms of complexity and maintainability.

In the end who cares about maintainability when you havent released a single patch to fix all the shortcomings of icon.library in more than a decade.

Maintainability is of no use if no one maintains it (which is pretty much what you did). Which is casually the opposite of what PeterK has been doing for a couple of years, despite it is in assembler, despite he had no sources to start with, despite he hadnt earn a dime during that process, and despite he added lots of advanced features to it, he still maintains it and takes care of any bug reports.

Of course, using assembler, does not apply in all situations, like components which have been actively maintained by Thomas Richter. But in the particular case of icon.library, PeterK`s solution is indeed much better in both features and performance than your own implementation of icon.library 45.x which has been unmaintained for more than a decade.

Assembler is not the best solution, but it is certainly better than unmaintained,  buggy and slow C code.

[Gulliver]

Now this is starting to get weird:

Now both Hyperion and Cloanto are developing independent AmigaOS 3.1 continuation branches.
They are both actively selling kickstart licenses.
And have provided affordable disk versions.

So:
At least we got two companies developing the OS for Amigas.
Would this state of affairs fragmentate (yet again) the Amiga scene?
Seems, at last, they both realized money is available in the 68k world.

Food for thought.

[Gulliver]

I agree that hacking and patching are not tidy or desirable solutions for long term development, they are just a quick fix, nothing more.

Hopefully kickstart development can catch up with what 3.9 offered and grow from there. Because right now it is a little poor in that area, so we are still better of with the hacks&patches from 3.9 and third parties, which is not the ideal solution.

I also wonder why didnt Olsen integrate his Roadshow TCP stack with this release, as it could have made the update much more interesting, and I guess many people could have happily agreed to even pay a bit more for the workbench disks if it was included/added to them. After all, Roadshow is also the TCP stack of OS4, so I guess negotiations with Hyperion would have been pretty easy to acomplish since they have been already done for the OS4 version.

Furthermore, there is a lot of 68k material from Hyperion that could have been included to enrich this release, at no cost of development at all. It was just a matter of collecting it from OS4 releases and prereleases.

[Gulliver]

@olsen

Thank you, I now understand the desitions that went into this release. They sound reasonable considering longer term goals.

BTW, I am glad that you are planing on addressing current release bugs and thinking on a viable future.
All this sounds like comitment to me, which gives me confidence and hope. And of course, more importantly, makes me a willing customer