HaikuOS and AROS

[PurpleMelbourne]

This might sound like a strange question. But hear me out 

I've been wondering what modifications would be needed that HaikuOS https://www.haiku-os.org/ could run Amiga software.
Ultimately the purpose would be to run on multi-core 68K FPGA softcpu.

With parts of AROS code, perhaps HaikuOS could be made into an Amiga GUI, which can then also be used for Atari on the same desktop. The Atari people have a FOSS OS with POSIX complaint memory protected and pre-emptive multi tasking called SpareMint http://sparemint.org/

Its been a long time since I looked at the details of what makes the Amiga tick underneath. But with some AROS kickstart code melded with Atari code inserted into the Haiku kernel, then it should be well on its way to becoming both Amiga and Atari compatible.

Later on perhaps 68K Mac could also be added, but that might be a more difficult job due to Apple keeping prying eyes away from how to hack their systems.

With the development of the Apollo 080 softcore CPU, its possible for the Amiga to become modern hardware again. Given our limited software library base, it would seem to make sense to combine several small ponds together into one larger pond with access to each others software libraries.

Imagine MS Excel for Mac, Atari Falcon music software, Amiga Deluxe Paint and Scala MM400 all on the same screen at the same time talking to each other via ARexx. Or something like that. 

[XD3l]

I am sure that in time, as Haiku develops and matures, that it will attract a lot of Amiga users as BeOS did back in the day.

Personally, I'd love to see AROS integrated with Haiku like how it is said can be done with Linux currently, though I've yet to find a guide on that subject...

Anyhow, I have a machine dedicated to Haiku and am eagerly watching as things slowly progress.

[Samurai_Crow]

Perhaps a hosted AROS on top of the SpareMint distribution of FreeMint would be a better first step because the EmuTOS setup for Atari has already been adapted for Vampire and the Vampire 500+ has been put into an Atari ST or STE (I forgot which) and are all 68k architecture.

Haiku takes a minimum of 1 GiB to run most software while the other OS's you want to merge will run on less than that.

[aurabin]

Brilliant Ideas!

[PurpleMelbourne]

The Haiku crowd are currently stretched, as are all the other projects outside Linux. Resources need to be increased rather than diluted.

Resources can be increased with synergy, or they can be increased with more coders. Any change is disruptive to the short term. But if its more coders then that will be an advantage in the longer term, and synergy between existing disparate resources could also work better in the medium term.

There is currently a political need for a new computer system which is not controlled by the Silicon Valley globalist leftist idealogue culture-warriors (SJW's). Tim Cooke's statement last week about it being "SINFUL" for big companies to NOT censor was the latest 'red pill' wakeup call. Android belongs to Google, the censor-in-chief and even the Linux kernel development has recently been rocked by SJW attack to force Linus Torvalds to walk away from Linux kernel development! This is all an opportunity for outsider Amiga/AROS/Atari/Haiku (AHAA?) as whatever hurts its competitor helps Amiga. Atari and 68k-Mac are not Amiga's competitor anymore. They can be our best friends.

For that non-computer reason, there is now a chance to bring a lot of fresh programmer blood from outside the existing Amiga/Atari/Haiku coding communities if there is a viable plan. A computer system which simply stands non-political, resisting efforts of the political left to suck it into the culture-war political storm. No need to be on the right, just refuse to be part of the left.


Amiga is a superior architecture to all except QNX and 'big-iron' mainframes. Now the only similar thing out there is an LG television which runs WebOS (Be>Palm>HP>LG>WebOS). If things worked out differently Amiga could have been in place of Mac. But now after 25 years past Commodore there is a new demand window opening for non technical reasons. This is an opportunity to advance the system with integration of developments from elsewhere just like the Apollo have done by integrating MMX into their Apollo 68080 soft-core CPU.

Haiku is very good. But Amiga has a few features which it lacks. As Rexx is now FOSS, ARexx could upgraded to ObjectOrientedRexx or NetRexx (extended from OORexx with Java).
There have been efforts to port the current version, but I don't know what progress was made.
https://www.haiku-os.org/blog/mmu_man/2016-07-11_story_arcs_and_arch_stories/

Carl Sassenrath's (who wrote the original Amiga exec) small and powerful Rebol network scripting language may also be included if its not redundant by OORexx/NetRexx or the very popular Python.

NetBSD kernel already exists on Amiga, Atari, 68k-Mac. Adoption of that kernel would allow later importing advances of OpenBSD and FireflyBSD (created by notable Amiga programmer Matt Dillon) for later progression towards low power massively parallel system using RISC-V phallanx CPU system.
http://fpga.org/wp-content/uploads/2016/05/grvi_phalanx_fccm2016.pdf

We could create a system which scales from a cheap Rasbery Pi type device for poor third world people right up to a many chip PRISM system for a mini-mainframe for business.
https://en.wikipedia.org/wiki/Apollo_PRISM

[Samurai_Crow]

@PurpleMelbourne

Let's take off our political hats and put our engineering hats for a minute.  The time it would take to merge all of those operating systems would take so long that the second coming of Jesus will have already happened by the time we would have finished such a project.  (Does a religious hat count as a political hat?)

AROS is uniquely equipped to run hosted on top of a POSIX compliant OS such as Linux, BSD or if we stretch ourselves, FreeMint or Haiku.  The choice between FreeMint or Haiku depends on your choice of CPU.  If you want 68080 it's FreeMint, if you want x86_64 it's Haiku.

[PurpleMelbourne]

Hello Samurai_Crow and others :-)

If Haiku were running on a NetBSD kernel then it wouldn't be such a big deal to alter the existing Atari, Amiga and 68k-Mac NetBSD kernels, then put Haiku on it.

The first thing to do would be to get Atari software running. It'd seem to be the easiest. Haiku as is probably has all the existing features plus a whole lot more, so nothing required on the Haiku side.

Amiga has a lot more to offer with things that Haiku lacks. So melding these together would take longer, and it could benefit the whole Haiku community.

A very valid half way measure is what you suggest with hosted AROS.
Though it would not backflow any new features, it would be good for running Amiga software.

The same could be done for Mac if its too difficult to build compatibility.

Hardware wise, I'm thinking both FPGA upgraded legacy hardware, and new hardware. What I'm thinking would have HaikuBSD runing on Arm (Rasberry Pi, Samsung Tablets, etc), 68k and x86/X64. As well as any other convenient ports. Maybe MIPS and SPARC? Put Haiku on your old SGI ;-)

I'm thinking Haiku as a new major platform.

As for religious hats... the political left would nail you to a cross if you dared put one of those on! ;-)

[Samurai_Crow]

@PurpleMelbourne

Haiku is great on multithreaded PCs.  That means it would suck like a vacuum cleaner on a single threaded system like an Amiga.  Likewise, Amigas have little to offer on a modern multicore system.  The only advantage Amiga had back in the day was that the chipset ran independently of the CPU in parallel.  Nowadays even the CPU runs in parallel to itself.

It'll be interesting to find out what the SMP support adds to AROS on ARM7 and AMD64-bit systems.  It's not available on 68k yet because there are no multicore Amigas.  Presently the experimental SMP is available on the nightlies of the 64-bit Intel/AMD but has very little software that supports it.  Dr. Schulz is working on the ARM version for the RasPi and is trying to bring parallelism to that machine as well.

As for NetBSD, it won't run on the Vampire because the 68080 has an incompatible MMU with the earlier 68k models.  There's a lot of arguments coming from complainers that the 68080 should be compatible to the old stuff but there are other machines like the MiSTer that can do things backward compatibly.  Personally, I think that if the 68080 gets a good OS that supports its capabilities it will start to dwarf the per-clock performance of even modern systems.

The roles of a traditional MMU are split between two units in the 68080.  Memory protection will be provided by a dedicated memory protection unit (MPU).  The MPU has byte-level addressing which makes it much better suited to lightweight memory protection that other operating systems don't offer because the old-style 68060 MMU had only 4K and 8K page sizes to choose from.  The second unit is a more primitive MMU than the 68060 had but because it doesn't shoulder the load so much as a traditional MMU it is only needed to rearrange the memory map for the Atari compatibility.  Hopefully somebody familiar with FreeMiNT can get its kernel customized to take advantage of the 68080.

As for merging Haiku with a Unix derivative, forget it.  Haiku's main advantage is that it's more lightweight than the other POSIX platforms.  As soon as you install all the drivers from them, it'll be an immovable doorstop in terms of performance.  I have higher hopes for Haiku than the others but inevitably it will accumulate cruft and become slow just like Linux did.

One thing you fail to grasp though, software doesn't just magically work on different processors than what they started out on.  If Haiku is on x86_64 with a backward compatibility kludge for old x86 BeOS software, it will never run well on an ARM or a Vampire.  You'll need a JIT or full emulator to run the old code.  The only other way is to obtain source code and recompile everything, praying that there are no system-specific binary blobs or inline Assembly language.

The best way around it is to have a virtual machine bytecode that gets translated only after it arrives at the destination.  The most promising one of those is the WebAssembly bytecode used in modern web browsers.  JavaScript is more mature but due to the nature of its dynamic type system, will never be able to JIT compile cleanly as WebAssembly will when it is completed.  This still doesn't cure closed-source programs of the need to recompile the source code to WebAssembly but it's the best approach overall, IMHO.

I first proposed the idea of a statically compiled bytecode to the executives at Amiga, Inc. twenty years ago.  They produced AmigaDE as a result of it but they had their snags with some of my idea and my perspective proved right in the end:  They thought supporting the Classic Amiga platform was a waste of time and energy but the AmigaDE platform was never embraced by Linux coders they targeted because the virtual machine itself was closed source commercial software.  Windows users were happy to stay Windows users as a result because there was no definite way to migrate to anything else (thanks to Microsoft's strategy).  I still have my AmigaDE install disks for Linux and WIndows but I can't install them anymore because the copy protection was designed to "call home" to Amiga.com to a server that is no longer up and running.

As far as the left crucifying me for my religious views it was already like that 20 years ago.  When all I asked for my ideas at the Amiga '98 DevCon was that the people using them give glory to God and donate the proceeds to a Christian church, they said that they wouldn't do it.  My response to them was that if they wouldn't give credit to God, then nobody would get exclusive rights to any of my ideas and all they'd get would be a 6 month head start.  They wanted to hold some deadly force from a government agency over me but I always wanted to meet my maker on such sacraficial terms anyway so I wouldn't be bullied.

The net result is that there are multiple technologies that emerged from every idea I had.  LLVM is the compiler infrastructure that went into both WebAssembly and Mono (the open-source spinoff of Microsoft's .NET platform).  It became a non-profit recipient of much donated time and energy since the compiler aspects of Visual C++ generated no revenue anyway and Apple resisted using GCC once it became GPL version 3.  This funneled all the best minds in compilers into one project that many were based on.

I hope you get the point.  Combining operating systems isn't going to accomplish anything good.  The secret is having a good quality and well-adopted virtual machine technology to gain compatibility between the operating systems.  Also, as far as power-mongering leftist politicians being defeated goes, the best way to defeat them is to divide them up against each other.  Accountability is the one thing power-mongering dictators abhor so the best way to keep them from dominating anyone is to keep them at each other's throats instead of giving them a single, central target to attack.

[PurpleMelbourne]

@PurpleMelbourne
As for merging Haiku with a Unix derivative, forget it.  Haiku's main advantage is that it's more lightweight than the other POSIX platforms.  As soon as you install all the drivers from them, it'll be an immovable doorstop in terms of performance.  I have higher hopes for Haiku than the others but inevitably it will accumulate cruft and become slow just like Linux did.

Wont using a hybrid micro-kernel with driver modules resolve that issue? Though we want some of it to be able to support more hardware.

One thing you fail to grasp though, software doesn't just magically work on different processors than what they started out on.  If Haiku is on x86_64 with a backward compatibility kludge for old x86 BeOS software, it will never run well on an ARM or a Vampire.  You'll need a JIT or full emulator to run the old code.  The only other way is to obtain source code and recompile everything, praying that there are no system-specific binary blobs or inline Assembly language.

You make a good point. Perhaps its better to simply import components from Haiku. Later the new Amiga could be ported to RISC-V and hopefully be the default PRISM (Parallel Reduced Instruction Set Microprocessor) home mini mainframe computer running on something like the GRVI Phallanx CPU with its 1680 mini cores.

The best way around it is to have a virtual machine bytecode that gets translated only after it arrives at the destination.  The most promising one of those is the WebAssembly bytecode used in modern web browsers.  JavaScript is more mature but due to the nature of its dynamic type system, will never be able to JIT compile cleanly as WebAssembly will when it is completed.  This still doesn't cure closed-source programs of the need to recompile the source code to WebAssembly but it's the best approach overall, IMHO.

Does WebAssembly make NetRexx redundant?
I like the idea of being able to run anything from anywhere and put it anywhere. So your own personal mini-mainframe in the home. API-wrappers being smaller than an OS container.

As we move forward again though we will be wanting to use the new software which doesn't yet exist instead of hanging on to what little we currently have.

[Samurai_Crow]

Wont using a hybrid micro-kernel with driver modules resolve that issue? Though we want some of it to be able to support more hardware.

Does WebAssembly make NetRexx redundant?
I like the idea of being able to run anything from anywhere and put it anywhere. So your own personal mini-mainframe in the home. API-wrappers being smaller than an OS container.

As we move forward again though we will be wanting to use the new software which doesn't yet exist instead of hanging on to what little we currently have.

Firstly, Haiku is already a hybrid kernel.  Secondly, hosted AROS is about as thin of an API wrapper as you are likely to find in a ready-made state, though there's room for improvement.  Finally, WebAssembly's bytecode is more streamlined than the large Java Virtual Machine that NetRexx uses.  The current form of WebAssembly is set up for little endian byte ordering which will likely run slower on a Vampire but I thought it might be an idea to download the LLVM backend for WebAssembly and make it run on big-endian byte ordering using hosted AROS as the runtime engine.

AREXX was a useful interprocess communication language in the day but is getting old by today's standards.  On AmigaOS 4, the PowerPC-based replacement for AREXX is a plugin library for Python.  Python is a good scripting language but doesn't compile any cleaner than the JIT allows because Python can't statically compile.

One advantage of WebAssembly over Java and Python is that it's designed to run in a web browser as a static compilation extension to JavaScript.  It already has a version of Emscripten to transpile C++ down to WebAssembly's bytecode.  Since web browsers are quite large nowadays, having a thinner runtime might be desirable but there's probably no getting around the browser dependency.

[cdimauro]

Python can be statically compiled: http://nuitka.net But it's quite uncommon. Also http://pypy.org allows to statically compile a Python subset (called RPython), and it provides an alternative Python implementation with a very good JIT: http://speed.pypy.org


I agree the WebAssembly is the future for the web. Once it will be implemented on all mainstream browers, it finally allows to use any programming language (Python!  ) to replace the horrible Javascript.

Regarding the merge of o.ses., it doesn't make sense. AROS can already be hosted on mainstream o.ses or run on a virtual machine, and that's fine/enough for cross-developing or trying it.

[XD3l]

@PurpleMelbourne

Let's take off our political hats and put our engineering hats for a minute.  The time it would take to merge all of those operating systems would take so long that the second coming of Jesus will have already happened by the time we would have finished such a project.  (Does a religious hat count as a political hat?)

AROS is uniquely equipped to run hosted on top of a POSIX compliant OS such as Linux, BSD or if we stretch ourselves, FreeMint or Haiku.  The choice between FreeMint or Haiku depends on your choice of CPU.  If you want 68080 it's FreeMint, if you want x86_64 it's Haiku.

Jesus wasn't political, so I believe you're safe! As for FreeMint hosting AROS... really? Say it ain't so! I didn't know people were doing this!

[nikos]

Tried Haiku the other day. Installed to my internal SSD. Completly waste of time. Browser crashed all the time. Could not read my usb-drive etc. AROS feels much more mature than Haiku. Why in the world would we need them.

[PurpleMelbourne]

Starting to sound like simply plundering Haiku for code would be the way to go.

I'll have to run it and find out. But I'm wondering if the BFS has auto garbage collection by keeping track of where all the files came from, when have they been used lately and what's using them. Amiga is small enough to kind of be aware of what is what. But with all the modern OS additions of 3D and whatever... might not be so compact. SO I wonder if Haiku does or does not hold the solution to that one.