Please note that a "80.0" of ixemul.library has been uploaded to Aminet. This version is incompatible and cannot be installed on MorphOS.

The version number (80.0) is no indication of advancement or features of the library. This library is based on 48.1 of the ixemul.library and thus skips 26 years of development that has been put into MorphOS ixemul.library. That is: Even though the version number is higher than what MorphOS ships, this library would be a downgrade in functionality.

It was a great idea to have MOSSYS:Libs precisely so a MorphOS system couldn't easily be broken by bad libs.

As for 68k users, I wouldn't recommend the use of it for them either. Not only is the version number hyperinflation not a good sign, stuff written using AI is almost invariably trash.

[ Edited by KennyR 20.09.2026 - 16:54 ]

Ixemul and superhigh version number?

Where did I hear that before.....

https://www.amiga-news.de/en/news/AN-2009-11-00032-EN.html

*klatsch*

It makes no sense to release an "updated" version of a MorphOS component unless it is done my a member of the MorphOS team itself.

Doing this with even using a higher version number can be treated as sabotage.

Same goes for other stuff we have to release as source due to the license. That is why we have the MOSSYS: barrier to prevent installers from overwriting the stuff within.

> It makes no sense to release an "updated" version of a MorphOS component
> unless it is done my a member of the MorphOS team itself. Doing this
> with even using a higher version number can be treated as sabotage.

The ixemul-80.0-m68k package is clearly targeted at OS3/m68k (emphasis mine):

"Architecture: m68k-amigaos [...]
Requires: AmigaOS 3.x [...]
ixemul.library provides a BSD/Unix runtime environment for AmigaOS. [...] This release represents a substantial update of ixemul.library, with [...] improved performance on m68k systems. [...]
Requirements
- AmigaOS 3.x or a compatible system
- Motorola 68000 or later [...]
The archive contains files for both the AmigaOS system partition and the Geek Gadgets development environment. [...] The system files should normally be installed on the AmigaOS system partition, usually the Workbench partition. [...] Version 80.0 includes [...] targeted performance improvements for m68k systems. Important areas updated in this release include: [...] support for 68000 through 68060 processors [...]
When reporting a problem, include the following information: AmigaOS version [...]"

The readme does not contain even one single reference to MorphOS.

Quote:

And we all know that users will follow the rules, especially when a version change is as insanely high, than here.

>>> It makes no sense to release an "updated" version of a MorphOS component
>>> unless it is done my a member of the MorphOS team itself. Doing this
>>> with even using a higher version number can be treated as sabotage.

>> The readme does not contain even one single reference to MorphOS.

> And we all know that users will follow the rules, especially
> when a version change is as insanely high, than here.

I still fail to see the release of "an "updated" version of a MorphOS component" (ixemul was there long before MorphOS) and how the release of this package "can be treated as sabotage" when MorphOS isn't even mentioned.

Quote:

Sorry! I totally forgot that you are the person who dealed already multiple times with bug reports of a totally unchanged and stock system and that you spend tons of hours trying to reproduce issues that only exists, because the reporter changed one component months ago and forgot.

>>>>> It makes no sense to release an "updated" version of a MorphOS component
>>>>> unless it is done my a member of the MorphOS team itself. Doing this
>>>>> with even using a higher version number can be treated as sabotage.

>>>> The readme does not contain even one single reference to MorphOS.

>>> And we all know that users will follow the rules, especially
>>> when a version change is as insanely high, than here.

>> I still fail to see the release of "an "updated" version of a
>> MorphOS component" (ixemul was there long before MorphOS) and
>> how the release of this package "can be treated as sabotage"
>> when MorphOS isn't even mentioned.

> Sorry! I totally forgot that you are the person who dealed already
> multiple times with bug reports of a totally unchanged and stock system
> and that you spend tons of hours trying to reproduce issues that only
> exists, because the reporter changed one component months ago and forgot.

That's the fault of the "reporter" then who sabotaged his own MorphOS installation and then wasted your time. It's certainly not the fault of someone who releases an non-MorphOS update of an open source software that MorphOS happens to maintain its own fork of. And as is common with open source software, anybody can fork ixemul and release own versions with whatever version number he/she likes. Someone who installs such a build on his MorphOS system because of version number 80+ would do so with any version number higher than the one of the MorphOS ixemul.
What you are demanding (else it's sabotage) is essentially that nobody can release his/her build of an open source software with a higher version number than the official MorphOS build of that software for any platform MorphOS can run executables of. That's completely nuts. Maybe you should remove MorphOS' m68k emulation from future MorphOS releases, then foolish users wouldn't any longer try to overwrite/override MorphOS system components with 3rd-party m68k builds ...or maybe they would anyway ;-)

There already is a sort of blacklist for some known broken 68k components that are known to crash the system no matter what (the list is definitely non-exhaustive, mostly it includes some historical Commodore era AmigaOS binaries that are so broken that they will just outright hard crash the system if run). This is not some ideological list but practical one. What we cannot do is to update it to already existing installs. This is the reason for my post.

> [...] This is the reason for my post.

I totally understand the problem at hand and fully appreciate any countermeasures that are taken software-wise (blacklist) or otherwise (warning on MorphZone). Thanks for that.
What I don't appreciate at all, and which is something you Piru can be absolved of, is imputing intentions of sabotaging MorphOS to someone who simply develops his own fork of open source software for another OS without even having MorphOS in mind.

Piru’s reaction probably comes from the fact that they’ve spent hundreds, maybe thousands of hours getting MorphOS ixemul into shape, debugging all sorts of stuff and bringing it to the point where a Linux tool ported through ixemul is going to be stable in 99.999% of cases.

So if the guy who actually worked on that sees some AI-made software, and it’s not even based on the stable MorphOS version but, if I remember correctly, on the old 68k version with some AI-added hacks on top, then he already knows it’s going to blow up sooner or later.

Sure, it may work in 90% of cases, (probably not due to the time changes) but that remaining 10% is exactly the kind of stuff that will keep popping up over the next few months.

Same story with MUI5. MorphOS has a mature, stable version. The OS4/OS3 version is incompatible in places and not exactly rock solid. And then people can easily get the wrong impression that MUI itself is unstable, while in reality the problem is with that particular implementation.

btw. i love vibecoding, just not for system critical components :)

[ Edited by zukow 22.09.2026 - 22:47 ]

> Piru’s reaction

...is completely reasonable. Someone else's reaction is not.

> some AI-made software, [...] with some AI-added hacks on top

I don't think Piru's warning has much, if anything, to do with that.

> it’s not even based on the stable MorphOS version
> but, if I remember correctly, on the old 68k version

Yes, absolutely. I see no reason why it should be based on the MorphOS version, especially considering that Piru writes it is based on ixemul v48.1 from 26 years ago. Can current MorphOS ixemul v50.31 even be compiled for OS3/m68k and run there without significant changes?

> then he already knows it’s going to blow up sooner or later.

Only if installed on MorphOS by some fool ;-)

> Same story with MUI5. MorphOS has a mature, stable version. The
> OS4/OS3 version is incompatible in places and not exactly rock solid.

I don't get your point here. Did anyone really attempt to run the OS3/m68k version of MUI5 on MorphOS? I've never read of such thing. Does MUI5 for OS3/OS4 even have a higher revision number than the MorphOS version?
If you refer to running the OS3/OS4 version of MUI5 on OS3/OS4, then this is a very different story than the one Piru posted here, which is about (not) trying to run an (incompatible) OS3/m68k build on MorphOS.

And now you are wasting my time instead.

> And now you are wasting my time instead.

No, it's you who is wasting your time posting baseless drivel. I surely didn't ask you to post anything of that, quite to the contrary, and surely won't miss any time-wasting contributions you might feel compelled to add to this thread but (hopefully) don't have the time to.

Hey guys, let’s get back to more interesting things
Piru rightly pointed out the problem right away, and then there were a few misunderstandings in general, but there’s no need to drag this out forever especially since we’ve all figured it out now
Now we’ve all realized that we need to pay close attention to exotic versions that are now frequently found online and, for some time now, even in Amiga systems in general partly because of this abuse and carelessness in the use of AI - vibe coding

> there were a few misunderstandings in general

;-)

> we need to pay close attention to exotic versions

I think it's much easier than that:
Do NOT EVER overwrite/override any MorphOS system (MOSSYS:) component unless explicitly told so by the MorphOS team!
This is an easy to understand rule which takes a special level of foolishness to dismiss.

> that are now frequently found online

Now? That has always been the case. See Kronos' link in comment #3 for example or there.

> partly because of this abuse and carelessness in the use of AI - vibe coding

I don't see mention of that in Piru's warning. I'm pretty sure his warning wouldn't read one bit different if the incompatible software warned against was created without the help of AI.

Quote:

yes that is a problem that you can easily overwrite even critical components and in worst case destroy your installation. And in many cases there are several versions of a library around, sometimes installation programs simply overwrite a component with a older one. There is no easy way out as long you have no protection of critical areas. That is the case for all current amiga based/inspired platforms, expecially when 68k is directly integrated and not integrated by emulation.

But MUI has nothing to do with it in my view, nobody makes conclusions about MUI on MorphOS when using MUI on OS3. Both are very different. In my view it would not harmed MorphOS if they would have officially supported/supplied MUI on other platforms. That would have helped to avoid fragmentation and MUI would have kept its status as first choice for GUI when you want a program to work on different amiga platforms . But that is another discussion...

[ Editiert durch OlafSch 26.09.2026 - 06:37 ]

Wouldn't it be a simple hurdle against overwriting mossys: files to protect -wd them by default during installation. Of course no big hurdle, but maybe better than nothing. And of "no cost" and mossys: files should'd get deleted or overwritten anyway except by system updates.

[ Editiert durch Zylesea 26.09.2026 - 15:11 ]

I don't think any AmigaOS based installer would try to put stuff into MOSSYS: but installing it into the normal folder will give it priority...

Might stay unnoticed for years until it causes trouble with no easy way to debug from outside.