@kolla

Quote:

kolla wrote: @NutsAboutAmiga The part I don't get is... why would I want OS4? ...

You do understand that there are other people in the world, and that they do not all think the way you do?

You might not care about AmigaOS 4 because you're already bored with it. I don't care about it because of all the Hyperion and A-EON association. But there are others that do care about it. And there are also many people who would buy it tomorrow if they could get an entry-level AmigaOS 4 compatible PPC system for less than €500.

While there isn't much new software development for AmigaOS 4, there is certainly more going on there than for Amiga OS 3.
When someone tells me they're using their AmigaOS 4 system as a daily driver, I can almost believe them. When someone tells me they're using their Amiga OS 3 or AROS 68k system as a daily driver, I call bullshit.

And yes, the obvious thing for Hyperion would be to port Amiga OS 4 to ARM. But it seems that outside the courtroom Hyperion have given up on tough projects, so the easier and quicker port would be to target emu68.

Which is all just trading in hypothetical scenarios, because Hyperion are most likely using what few resources they have to cash in with Amiga OS 3.3 in the not too distant future.

I too am looking forward to ARIX, but @michalsc will not have that ready for a while yet.

Last edited by agami on 01-Sep-2023 at 02:50 AM.

_________________
All the way, with 68k

Thank God that people prefer different things 😊
I'm very okay with Hyperion putting efforts into 3.x, it might hopefully bring a small economic relief that may let them do something bigger going forward. One can only wait and see.

Regarding ARIX I'm curious about what it could bring, sounds like descent try for a next step.

Regarding the sub €500 AmigaOS4 compatible hardware, I'm interested in testing such a system but I'm confused over what's available to buy and so on. May you give me a hint on what to look for, if you have any recommendations.

@agami

Quote:

And yes, the obvious thing for Hyperion would be to port Amiga OS 4 to ARM. But it seems that outside the courtroom Hyperion have given up on tough projects, so the easier and quicker port would be to target emu68.

Why do you take it for granted that it is quicker to port OS4 from PowerPC to 68k than PowerPC to ARM (or more specifically, RaspberryPi 4, for example?)

Quote:

Which is all just trading in hypothetical scenarios, because Hyperion are most likely using what few resources they have to cash in with Amiga OS 3.3 in the not too distant future

True. And at some point Ben most likely will have to "hand over" the whole OS3/m68k activity over to Cloanto... except for those bits and pieces that really are back-ported from OS4 (and not just reimplemented), and of course ReAction, TextEdit, RAWBinfo and ASyncIO/ReAction-edition (Good riddance!)

Last edited by kolla on 31-Aug-2023 at 02:06 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@zidz

Quote:

zidz wrote: ... Regarding the sub €500 AmigaOS4 compatible hardware, I'm interested in testing such a system but I'm confused over what's available to buy and so on. May you give me a hint on what to look for, if you have any recommendations.

There aren't any.
There was once a well founded expectation that the A1222 would be the sub €500 system board, and many an Amigan waited for too many years only to be told that it's going to be twice that, and then some.

Of the Amigans anticipating the arrival of the A1222 as their first AmigaOS 4.1 (Enhancer 2.x) machine, more have given up on the planned purchase than remain in line after finding out about the increased price.

Some of these already have a sub €500 PowerPC system in an Apple G4/G5 equipped desktop or laptop running MorphOS, and I'd venture there are between 35-50% of them that do not have, nor have they ever had an Amiga-inspired NG system running on PowerPC. All in all, standarised market models tell us that there would be upwards of 5x more customers for AmigaOS 4 than presently engaged, if the price were right.

But as fate would have it, we've come to the end of this chapter in our cursed journey. There are no more planned PowerISA-based boards for our hyper-niche market, in large part as there are not enough developers to work on the AmigaOS 4 porting effort. Yes, for each new board we've had over the past couple decades, there has been a varying non-insignificant amount of AmigaOS 4 porting effort to adapt the OS.

So even if someone could produce a sub €500 system board in the small quantities justified by our market, the time and money required to port AmigaOS 4 would pretty much be the same as picking an off-the-shelf ARM-based mini-ITX board with PCIe slot which is already below €500.

Last edited by agami on 02-Sep-2023 at 06:46 AM.

_________________
All the way, with 68k

kolla Quote:

Why do you take it for granted that it is quicker to port OS4 from PowerPC to 68k than PowerPC to ARM (or more specifically, RaspberryPi 4, for example?)

I can think of several reasons why the 68k would be an easier target than ARM for PPC AmigaOS 4.

o There were supposedly early versions of AmigaOS 4 which still worked on the 68k. Unless 68k support using C code conditional preprocessor directives and build scripts was arrogantly removed, building for the 68k may be partially possible with minor changes. The PPC developers would never arrogantly ignore the much larger 68k market after all (Ben gets it but Trevor ignores reality).

o The "68k interpretive emulator" in the PPC Exec kernel (still a microkernel with an emulator likely bigger than the whole 68k AmigaOS kernel?) could be removed instead of replaced with an ARM version. This is likely not as simple as a recompile for ARM.

o A port to the 68k would have no endian issues as PPC is big endian too. A proper port of the AmigaOS to ARM would use the native little endian byte ordering. ARM CPUs with older Thumb ARM ISAs had better support for big endian but that support is deprecated or limited to small low power CPU cores while the new AArch64 is little endian with limited support for big endian memory accesses. Big to little endian conversion issues are to be expected, 68k emulation is likely to be more difficult and less efficient and 68k AmigaOS compatibility is likely to suffer.

I know many Amiga fans want AmigaOS 4 on ARM thinking super cheap hardware will expand the Amiga user base but I don't believe the pasture on the other side of the fence is as green as it seems. The super cheap hardware often has weak CPU performance for emulation of the 68k+OCS/ECS/AGA and there would be only recompiles of native ARM Amiga software which many developers may not be interested in doing until there is a large enough user base. This is a similar situation as x86-64 AROS (and soon x86-64 MorphOS?) but they have stronger x86-64 CPUs for 68k Amiga emulation, some native software already and a more mature platform. I expect an ARM Amiga platform will just disperse Amiga users and developers to more platforms instead of focusing on one to make it the best. The x86-64 SBCs aren't nearly as cheap as ARM SBCs with integrated graphics and often poor documentation but, if a higher performance desktop like graphics card is desired, are more likely to come with adequate PCIe slots, power supply and fans. The total system cost is still a fraction of the cost of AmigaNOne systems and the cheapest x86-64 CPUs in SBC SoCs are outperforming old PPC CPUs. There is higher performance desktop like ARM hardware but an AmigaOS 4 port to ARM would be competing with a more mature x86-64 AROS and MorphOS, x86-64 desktop hardware has a better selection and higher performance than ARM designs, the most popular alternate OSs like Linux and Windows are better supported on x86-64, etc. There is Apple ARM hardware which may be competitive in performance with x86-64 hardware but it is not open and expensive. I believe this is game over for the semi-desktop AmigaOS 4 as it has nowhere to go (emulated 68k hardware is a joke) but it doesn't have to be the end of the Amiga.

Isn't ARM taking over the world and it will wipe out x86-64 CPUs too? History often repeats itself. RISC hype predicted that Alpha, MIPS, SPARC and PPC would take over the desktop, workstation and server markets too. Motorola and Intel both believed it. Motorola gave up on trying to retain the 68k as the microprocessor workstation king which killed the minicomputer and its position on the desktop to join the PPC AIM alliance to at least make a unified platform instead of many divided RISC platforms. Their biggest desktop customer, Apple, was on board so they could at least retain part of that business (Amiga and Atari were buying embedded CPUs and had deteriorating financially conditions). Intel had a larger position on the desktop due to the PC clone market standardizing on x86 hardware. They realized the importance of x86 compatibility and that many of their customers would be lost if they did not retain it. Intel bet a huge amount of money on a VLIW CPU solution as it was possible to retain better compatibility than with RISC but this turned out to be an Itanic mistake as general purpose performance was challenging. The x86 CPU market was still strong and profitable for both Intel and AMD and AMD decided to create the AMD64 ISA and CPUs instead with their profits which gained them market share especially for the lucrative workstation and server markets. AMD64 was just good enough for a 64 bit ISA but more importantly backward compatible forcing Intel to adopt it calling it x86-64 and the high performance CPU race was on with absurdly large budgets and CPU cores but now a mostly standardized ISA with backward compatibility for a huge software library that no RISC platform could compete with.

ARM CPUs came from Acorn Computers who decided to design their own CPU in 1983. They looked at the CPU options available and thought they could do better using RISC principles after learning how easy it is to design a simple RISC core. Compared to a 68000 CPU, up to 1/3 of the transistors could be saved by eliminating the microcode and the savings could be used to add a 3 stage pipeline improving instruction level parallelism and allowing higher clock speeds which improve performance. They also stripped the ISA and CPU for a general purpose register load/store architecture kind of like Chuck Peddle had done to the 6800 for an accumulator architecture to create the 6502 (GPR load/store architecture decreases memory traffic and is better for compilers). They were able to improve interrupt timing by saving less data but this limited addressing to 26 bits causing software incompatibilities later. The 68000 was nicer in many ways with often more powerful instructions requiring fewer of them like hardware multiply and divide, more addressing modes, better code density and even less memory traffic but the first ARM CPU was higher performance overall and used less than half the transistors. CISC CPUs later adopted the useful RISC principles like pipelining while many of the RISC principles were abandoned like elimination of microcode, few and simple instructions and addressing modes and shortest possible cycle time and highest possible clock speed to improve performance. Comparing the newest ARM AArch64 ISA and CPUs to the 68060 ISA and CPU has the 68060 looking significantly significantly simpler and slimmer. The only significant difference left is that not so RISC AArch64 uses load/store memory accesses and the not so CISC 68k uses reg-mem (more complex but lower instructions counts, less memory traffic and better code density). Ironically, Motorola kept the reg-mem accesses for their cut down lower end embedded 68k architecture which they then described as "variable-length RISC ColdFire architecture". For about a decade, the 68k and ColdFire had a larger share of the 16/32 bit embedded market than ARM which had weak performance cores and big code with their original ISA. They adopted Thumb encodings which improved code density to roughly that of the 68020 ISA after licensing Hitachi's SuperH ISA poorly copied from the 68k and more RISCy. This allowed for cheaper embedded designs and better CPU performance on cheap hardware with low memory bandwidth allowing them to gain the 16/32 bit embedded market finally. They gave up the code density and advantages on low end hardware to gain more performance with desktop like RISC ISAs like x86-64 made extinct but with some improvements and new for ARM ISA standardization that has hardware requirements that very much limit how low it will scale (along with barely better than PPC code density which also limits scaling down to their bread and butter low power embedded market). Instead of many RISC ISAs dividing the market, there is now one unified RISC ARM AArch64 ISA that can compete on the desktop and can scale down into much of the embedded market too. The embedded market is not as profitable as the desktop and server markets but ARM has become an expert at leveraging economies of scale from the sales volume.

Intel tried to compete with ARM in the mid-performance mobile embedded market using x86(-64) but they gave up because they were losing money. The Atom CPU line couldn't gain enough market share for economies of scale and Qualcomm had effectively locked them out of the mobile market.

https://www.extremetech.com/computing/227816-how-intel-lost-the-mobile-market-part-2-the-rise-and-neglect-of-atom

Intel was having fab issues which limited how much they could invest to try to gain market share and the profit margins were lower than their desktop and server markets anyway. The desktop market is shrinking as the mobile market grows so advantage for ARM for now, at least until Intel gets their act together as AMD has been out competing them too. We looked at how low ARM AArch64 could scale so lets look at how low x86(-64) can scale since that is what the Atom cores were attempting. Intel or AMD could always reenter and try to penetrate that market again. The first Atom CPU launched in 2008 was the lowest power attempt Bonnell microarchitecture. The designers went back to the P5 microarchitecture which is the 32 bit superscalar in-order Pentium microarchitecture that competed with the 68060. The circa 2009 Intel Larrabee GPGPU also went back to the P5 microarchitecture to minimize the x86 core size and power requirements for scaling with more parallel cores, including to handle flexible GPU workloads (it could do ray tracing before most ray tracing gfx cards). The early P5 pipeline only had 5 stages (68060 had a more practical 8 stage pipeline) which the Atom Bonnell microarchitecture extended to a long 16-19 stages.

https://en.wikichip.org/wiki/intel/atom Quote:

Unlike P5, which only had 5 stages, Bonnell has 16 to 19 pipeline stages. The longer pipeline allows a more even spreading of heat across the chip with more units. This also allows a higher clock rate.

That's not good when so many stages are added to more evenly spread heat considering extra stages are more active transistors that add heat and "the branch-misprediction penalty is 11 to 13 cycles" which is not good for general purpose or embedded use and requires more expensive branch prediction hardware which also generates heat. Instruction fetch is 3-5 stages for the Bonnell pipeline and a 4kiB instruction boundary marker cache is used to reduce this by 2 stages for L1 cached code compared to the 2 cycles of decode for the 68060 pipeline, no need for a boundary marker cache generating heat and the 68060 has about 20% better code density (RISC-V research showed that RVC " fetched 25%-30% fewer instruction bits, which reduces instruction cache misses by 20%-25%, or roughly the same performance impact as doubling the instruction cache size.") The 68060 pretty much destroyed the P5 Pentium in Power Performance Area (PPA) which is what is wanted for scaling purposes and for the embedded market.

Pentium@75MHz P54C, 3.3V, 0.6um, 3.2 million transistors, 9.5W max
68060@75MHz 3.3V, 0.6um, 2.5 million transistors, ~5.5W max*

* estimate based on 68060@50MHz 3.9W max, 68060@66MHz 4.9W max

The Bonnell and Larrabee designers could only dream of starting with using 42% less power with similar performance like the 68060 advantage over the P54C Pentium. A single core Bonnell is also using 47.2 million transistors so this core is anything but small when trying to minimize the size for scaling purposes (18.8 times the size of a 68060 core). Later Atom family cores ditched the lower power in-order superscalar design for the more typical micro-oped OoO x86-64 design for better software compatibility as wanted by customers who had mostly moved on from x86 (unlike 68k software). The OoO Atom cores were obviously many times larger with larger caches, there are no more TDP values listed in mW, chip processes were shrunk, prices went up and GPUs were included as SoCs to improve value but most needed fans now (more than ~10W per CPU core needs a fan). The performance of the Atom Bonnell cores was competitive with ARM though. The in-order Bonnell core significantly outperformed an OoO Cortex-A9 with 2.5 DMIPs/MHz/core performance which is better than the popular in-order Cortex-A53 of the Raspberry Pi 3 given as 2.3 DMIPS/MHz/core. The Bonnell core has to be clocked higher causing it to use more power but the power used to do a similar workload (performance/W) is nearly competitive with the power efficient OoO Cortex-A9, beats the newer and higher performance but less efficient OoO Cortex-A15, beats an in-order Cortex-A7 and beats an Intel i7.

https://www.extremetech.com/extreme/188396-the-final-isa-showdown-is-arm-x86-or-mips-intrinsically-more-power-efficient

Compared to the in-order 32 bit x86 Bonnell core, an OoO 32 bit Cortex-A9 core is probably about half the size and an in-order Cortex-A53 is about 1/4 the size. I would love to see updated benchmark data with a Cortex-A53 and newer high performance ARM OoO cores where I expect the ARM CPU cores to have improved in performance for the OoO cores but not necessarily in power efficiency when using the same chip process as can be seen with the Cortex-A15. Limited OoO can improve power efficiency as seen with the Cortex-A9 while aggressive micro-oped OoO wastes power and power efficiency often declines. If a superscalar in-order core can improve performance to compete in power efficiency with limited OoO cores, then there is a potential for transistor/area savings but x86 had too much baggage and lost its compatibility advantage for mid performance cores. It still shows an in-order superscalar CISC CPU can outperform many limited RISC OoO cores but x86 has too much overhead to compete well in power efficiency and huge aggressive micro-oped x86-64 cores are worse. Too bad the 68k has no representation as the in-order superscalar 68060 had P5 Pentium like integer performance and could scale lower than x86 for high end mobile/embedded and lower than AArch64 for lower end 16/32 bit embedded. The amazing 68k ISA scaled from low end 16/32 bit embedded all the way up to workstations which no other ISA has been able to achieve including AArch64 and x86(-64) but ARM is trying to scale farther with AArch64 than x86-64 can achieve.

kolla Quote:

True. And at some point Ben most likely will have to "hand over" the whole OS3/m68k activity over to Cloanto... except for those bits and pieces that really are back-ported from OS4 (and not just reimplemented), and of course ReAction, TextEdit, RAWBinfo and ASyncIO/ReAction-edition (Good riddance!)

If Ben has to "hand over" the whole OS3/m68k "activity" then he will likely have to hand over the profits from 68k AmigaOS 3.x which he has likely already spent on the lawsuits and Hyperion can't pay. Trevor may want to bid on the Hyperion IP from Hyperion's bankruptcy lawyer but that would be a legal minefield, especially if the 2009 agreement is terminated due to either violating the non-compete termination clause or due to an illegal contract from intimidation and coercion of a business in financial duress to sign the contract. Trevor's fixer would be out of the way, AmigaNOne would be gone without the AmigaOS and Trevor's desktop fantasy for the Amiga would be over (Trevor could license AmigaOS 4 from Amiga Corporation but I expect AmigaOS 4 would have an added "lawsuit" tax for him). I just wish legal roadblocks didn't take so long as there is an opportunity to raise investments and the 68k Amiga to compete in the small footprint retro, hobby, embedded markets with mass produced hardware.

Last edited by matthey on 04-Sep-2023 at 11:15 PM.
Last edited by matthey on 03-Sep-2023 at 02:01 PM.
Last edited by matthey on 03-Sep-2023 at 02:18 AM.

@agami

Quote:

Probably better if Hyperion just ported AmigaOS 4 to emu68.

How would that help? I mean, doesn't it represent itself as a 68040? I'm not aware of 68K knowing it is special or if it has UAE style hooks to native functionality.

Quote:

Let?s face it, the PPC folk who are not on MorphOS are keen to move to System 54. AmigaOS 4 on emu68 would be a new market for Hyperion. And they would make more money than releasing Amiga OS 3.3 for slow 68k.

Well. System 54 still needs OS4 to run. Or it will. So they can't get out of it. To be solo they will need to do an AROS4 so to speak and fully write their own OS4 cover version from the ground up. But what would they do that? Two Amiga based OS full of bugs would be worse than the one OS4 full of bugs we have now.

Even if they did. It wouldn't make sense to run it on the same CPU again and endian. They need to switch CPU or endian. And in this day and age it makes sense to do both. PPC has made a kind of comeback with Linux. It's back on Ubuntu with a port. Headless server by default and like ARM most common builds are for servers. But there are desktop packages and a recent Firefox.

PPC/64 BE Linux has the worse Radeon support. On par with MorphOS. OS4 has the best support but it's not free and extra on top of OS4. That is using a modern card and by modern I mean an R or early RX series. PPC64LE has the best Radeon support since has no endian issues. Apparently the s390x is big endian and also had drivers. But I don't know if they work correctly. I take it anyone with an s390x isn't using it like a G5 quad desktop . I've gone off topic slightly...

@Hans

Quote:

Good idea. If I were in charge of the AmigaOS 4 project, then I'd be considering something similar. Using a stripped down Linux kernel is one option. The other would be some kind of Linux compatibility layer (like FreeBSD uses for porting Linux drivers).

So a bit like what Apple did with OSX? Except Apple didn't run Mac OS on top of an OSX kernel like a Windows 3.1. They replaced Mac OS with OSX. And added bridge software so OS9 apps still ran and had some cross compatibility. Would you change AmigaDOS to be more Unix like like it was meant to be with CAOS? Apple also did that. Or would you keep AmitgaDOS as it is?

@Hypex

Has English all of a sudden become everyone's second language?

Nowhere did I even imply that Hyperion porting AmigaOS 4 to emu68 is what's best for our hyper-niche market/community.

It was a response to the proposition of including a QEMU derived PPC emulation alongside emu68 to then be able to run AmigaOS 4 (Classic) on PiStorm32.

Since Hyperion is only interested in the quickest of bucks, a port to emu68 (equal or surpassing the performance of Phase 5 PPC expansions) would be a good move, for them.
While System 54 uses AmigaOS 4 as its base, I'm not sure any new money flows to Hyperion per system/seat, if/when it becomes available.

In reality, Hyperion aren't porting anything to anywhere. AmigaOS 4 has for all intents and purposes reached saturation. Without a large injection of cash, it's likely the users won't even see the proper 4.2, let alone a little endian port.

_________________
All the way, with 68k

@Hypex

Quote:

So a bit like what Apple did with OSX? Except Apple didn't run Mac OS on top of an OSX kernel like a Windows 3.1. They replaced Mac OS with OSX. And added bridge software so OS9 apps still ran and had some cross compatibility.

Not really. The goal is to be able to use Linux drivers with almost no changes. Getting drivers written is an ongoing problem for AmigaOS, so being able to use drivers written by others (including the manufacturers themselves), would take a huge burden off our backs, and allow us to focus on other stuff. My preference would be a Linux compatibility layer for AmigaOS, similar to FreeBSD's LinuxKPI. If that's impractical, then I'd consider replacing the core of ExecSG with the Linux kernel. IIRC, that was considered back when Gateway owned the Amiga.

Quote:

Would you change AmigaDOS to be more Unix like like it was meant to be with CAOS? Apple also did that. Or would you keep AmitgaDOS as it

My preference would be a bash compatible shell.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Quote:

Hans wrote: @Hypex Not really. The goal is to be able to use Linux drivers with almost no changes.

Nice dream.

Quote:

If that's impractical, then I'd consider replacing the core of ExecSG with the Linux kernel. IIRC, that was considered back when Gateway owned the Amiga.

Considered and dropped, for many reasons, one the being obvious license controversy it would cause.

Quote:

My preference would be a bash compatible shell.

Only bash is bash compatible, and it is GPL, so… license issues again.

It sounds like what you really want, is (a somewhat aging) Linux with OS4 “environment” on top. Best way to such a goal, is OS4 drivers for virtio devices and Qemu, either with kvm on PowerPC or via system emulation on AMD64.

Last edited by kolla on 05-Sep-2023 at 05:29 AM.
Last edited by kolla on 05-Sep-2023 at 05:13 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

Nice dream.

Thanks.

Quote:

Considered and dropped, for many reasons, one the being obvious license controversy it would cause.

Considered and dropped by whom?

Quote:

Only bash is bash compatible, and it is GPL, so… license issues again.

The only issue I see with porting bash, is convincing someone to do the work. I made the suggestion before after getting frustrated with incompatibilities between bash and the *nix shell that comes with the AmigaOS 4 SDK. The response was basically "Aargh! Fork()!"

Quote:

It sounds like what you really want, is (a somewhat aging) Linux with OS4 “environment” on top.

Nope. I'm looking for a practical way forward. It's all theoretical anyway, since I'm not in a position to make any decisions.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Well, “bash” isn’t a standard, posix sh is - if you intend for your scripts to be portable, ensure they are posix sh compatible. Porting bash you say, well, which bash? Bash itself is incompatible between its own versions, which you since 4.3 finally could work around by using shopt compatNN modes (where NN is for example 32 or 41). Why do you want to climb down this nasty rabbit hole? What is lacking in posix sh for you?

Last edited by kolla on 05-Sep-2023 at 02:41 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

Well, “bash” isn’t a standard, posix sh is - if you intend for your scripts to be portable, ensure they are posix sh compatible. Porting bash you say, well, which bash? Bash itself is incompatible between its own versions, which you since 4.3 finally could work around by using shopt compatNN modes (where NN is for example 32 or 41). Why do you want to climb down this nasty rabbit hole? What is lacking in posix sh for you?

Woah! Slow down there. I'm not interested in going down rabbit holes. I'm just sick having to go through multiple cycles of a script breaking on AmigaOS when I got it working on cygwin/Linux, and then braking on cygwin/Linux when I fix it for AmigaOS.

I'm no posix shell expert; I just want to be able to write scripts once, and have them work on all the systems that I need it to work.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Quote:

Hans wrote: I'm no posix shell expert; I just want to be able to write scripts once, and have them work on all the systems that I need it to work.

That’s _literally_ what POSIX was invented for, so maybe you should consider becoming a posix shell expert.

Next time you write a script for bash, add a “set -o posix” along with the “set -e” and “set -o pipefail” that you surely already have present in all your scripts.

Last edited by kolla on 06-Sep-2023 at 10:23 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Thread

CM4 modules seems rarer than I would hope they would be by now! This is especially true of the 2GB WiFi Lite model it seems! If you can find one for sub-£50 then buy it!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@kolla

Quote:

Next time you write a script for bash, add a “set -o posix” along with the “set -e” and “set -o pipefail” that you surely already have present in all your scripts.

Thanks. I'll try to keep that in mind next time I have to write a script.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@kolla

Quote:

Next time you write a script for bash, add a “set -o posix” along with the “set -e” and “set -o pipefail” that you surely already have present in all your scripts.

I just tried this, and was told it's an illegal option. Still having to work around differences (this time cygwin and bash on Ubuntu)...

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Sounds like you’re not using bash at all, but rather dash - the default /bin/sh on everything Debian, I presume also Ubuntu. If you specifically want to write bash scripts, then ensure this with “#! /usr/bin/env bash” as first line of script, and not just “#! /bin/sh” (which is supposed to give you a posix shell).

Last edited by kolla on 25-Sep-2023 at 07:58 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@agami

Why worry about ARIX when you already have ApolloOS? What else would ARIX offer?

_________________
Sent from my Quantum Computer.

@DiscreetFX

Quote:

DiscreetFX wrote: @agami Why worry about ARIX when you already have ApolloOS? What else would ARIX offer?

ApolloOS is awesome, but limited. ARIX will provide better driver support for more hardware flexibility. Moving to commodity ARM or x86 hardware and bridging between the 68k ISA and the next.

I remember when AROS started in the mid ‘90s and I have always been a fan of the project’s mission. Unfortunately, it wasn’t ready at key junctures to be considered in the plans of interchanging Amiga IP holders. Until 2009 that is.

In 2009, when Mr Dickinson was looking to put some money into newer PPC hardware for another Amiga-inspired system, he turned to the “legitimate” successor to Amiga OS 3 so the new system would have the necessary credibility.

He wanted to focus on hardware and have someone else focus on software, but since he didn’t care for x86, ideally he should have put money into AROS-PPC to bring it up to the level of AROS-x86.

The cost of AROS-PPC porting development would’ve been the same as what he spent on AmigaOS 4, but the open source ecosystem would’ve been boosted and A-EON would have had more control over its product delivery.

Alas, AROS entered into a slump over the past 5 years, with most of the activity occurring in AROS-68k and more specifically ApolloOS. This is great for the Apollo 080/SAGA systems but it doesn’t move the needle forward enough.

I’d really love for AROS to have the kind of engagement Haiku OS is having, but the chances of that are getting slimmer every day.
Though with ARIX, I see an opportunity for some forward movement. Perhaps it’s something that the AROS project should’ve seriously entertained in the early 2000s, especially seeing how well it worked for Mac OS X.

_________________
All the way, with 68k