BIT-ROT!

[richmond62]

Well, as my late father said when I asked him what his favourite thing to do in his free time was, "Bang my head against the wall."

And why, forbye?

"Because it feels great when it stops."

I just hope, before I die, I manage to attain the level of wisdom and inner peace that he did!

I am planning on retiring in 2-4 (at 67 my GB pension kicks in: having paid contributions for years), and God know what I will do after that (probably start a cottage industry making fairy chess pieces): but as far as I am concerned the likes of Cook and the Hairstyle guy whose name I can never remember can take their Rosetta 2 and shove it where it should be shoved.

Everyone round these parts will NOT live forever, and there will come a time when all of us are on the shelf, as will be xTalk: dammit it has had an extremely good run as computer languages go: only real fruitcakes are still programming in PROLOG and ZILOG.

AND the level of 'sweatiness' round these parts seems slightly disproportionate . . .

[richmond62]

Apple are requiring that users of Sequioa (sic) manually download Rosetta2

Oddly enough, until one of my sons, in a fit of generous insanity, bought me a 2018 Mac Min, I did fine with a machine running MacOS 10.6.8 and another running MacOS 10.7.5.

I am in the process of scraping together the moolah to buy a 'trashcan' Power Mac from whenever in case the iMac I have (second hand, finded by generous donors to an appeal) goes wonky (certainly slowing dow something rotten). I am trying to thing of why I should buy an ARM Mac, and why anyone but a bunch of fashionistas would either.

[OpenXTalkPaul]

Personally if it was a choice between running OXT Windows Engine in a WINE-skin wrapper or running some web xTalk interpreter in a Web Browser engine that's wrapped in a desktop app dressing, I'd go with the later.

You could still extend the WINE-Windows version, but only so far as you can with Win engine already, by using libraries built for Windows (at least FluidSynth and HID API could still work). Windows too is linked against some old APIs (how long will Win32 be around?) and also expects an Intel x86-based CPU (RISC-V CPUS anyone?)

But the Web Engine is pretty much guaranteed to run on Apple Silicon OR Windows 11 ARM versions.

I don't really understand the problems reported about OXT on BigSur+, it ran quite well for me on BigSur (on a 6th gen Core i7 laptop with M2 SSD and 40GB ram )

We could go with a different engine entirely, there are several to pick from that could, in theory, be worked on to extend them for compatiblity with the OXT engines, but I would expect that would never reach 'entirely compatible' state.

StackSmith is not really stable and Uli has not updated it in some years, but it did compile from source for me quite easily on MacOS 10.14 Mohave.

Most of us have already had to convert old xTalk stacks from HC, or SC into MC, RR, LC stacks, so that again.

To me it's about the xTalk scripting language, and the 'live' / R.A.D. part. I'm engine agnostic.

[Skids]

I am trying to thing of why I should buy an ARM Mac, and why anyone but a bunch of fashionistas would either.

I believe that they are quite good for video editing.

In my case I wanted to take advantage of the advanced de-noise routines built into DxO Photolab and have them run in seconds rather than minutes. Also my 2013 laptop was showing signs of failing, a bit like me!

S

[richmond62]

That makes sense, as 12 years for a Mac laptop is pushing things a bit.

[tperry2x]

Hmmm, so much for my idea.
Instead of:


It's more a case of:

output.png (594.12 KiB) Viewed 5492 times

It's pretty much had it.

[richmond62]

It has only had it if you confine yourself to the goals you and others have outlined.

There are so many other areas where its strengths can be put to good use.

[OpenXTalkPaul]

The question of why use an ARM-based processor? Maybe ask your phone which has probably been powered on for 10s of hours.

I'm kind of fascinated with idea of RISC-V being open-source hardware platform.

I'm CPU agnostic, but since I just today rebuilt my circa 2017 Intel i7 laptop, I'll likely be sticking with Intel x86-based computing for a few more years at least (it's been about 20 years since I switched over from PowerPCs).

[tperry2x]

I'm CPU agnostic, but since I just today rebuilt my circa 2017 Intel i7 laptop, I'll likely be sticking with Intel x86-based computing for a few more years at least (it's been about 20 years since I switched over from PowerPCs).

I'm largely CPU processor agnostic - although with certain provisos*

For me, it's what gives good performance, factoring in outright costs, and what is available. Plus there's the huge amount of software I already have across Windows, Linux and MacOS which is intel. I've been here before with the PowerPC transition of course, back when I was "mac or nothing". Even if Apple were to scrap Rosetta2 tomorrow, there's no way I could afford an Apple ARM mac - (I don't even think I'd really want one - I don't have many reasons that would justify getting one if I'm honest).

It's actually a bit of a backwards step, as ARM macs can't be made to boot Intel ISOs (yes, there are attempts to boot Arm Linux on them, to break them out of the Apple walled garden ) - and while their progress has been amazing, they aren't completely there. (Grab a copy of everything, because if Apple decide to squash it, they absolutely could). Don't know why I'd buy an ARM mac to be locked into that ecosystem again.

*and there's the provisos: I wouldn't buy a chip with hardware lock-in, or one with Microsoft's CoPilot subsystem baked in either. Multicore Intel chips with integrated GPUs can be just as fast as the M1/M2 chipsets[ref - (maybe not M2 Pro/Max, or M3) but then if I'm honest - what do I need that level of performance for? AMD? - well, by the time you'd bought an "AMD Ryzen 9 9950X" for over £600, you might as well have bought an M3 mac mini* (with lock-in).

Interestingly, Microsoft have been developing WSL for Linux (so you can run Linux apps in Windows), although (I'm not really sure why you wouldn't just boot into a linux distro there).

But then, all this is perhaps missing the point as far as an IDE is concerned.
It's not about what hardware YOU or I am running, it's more about "Is the IDE available on the OS I've chosen". Is it available in a truly hardware agnostic way? - That's probably only going to be close via a browser (and even then, there will be differences in the way things are reported & variables returned) - it's not the 100% magic bullet either, because there's not a lot ready 'today' that has an xTalk-savvy syntax. Even less so that is ready to use.

[tperry2x]

If someone wants to try OpenXTalk and is truly "platform agnostic", then they could always try the live ISO of OpenXTalk Lite on a DVD or a memory stick.

• (not if you are on an intel mac running MacOS 10.9 through to MacOS 13 - it works like it should already).

• (not if you have an ARM mac - as this won't boot)*

*more options on this on my post further down.

While I mention that, something interesting I found.
OpenXTalk will run absolutely fine on Linux without GTK2 being installed.

openxtalk-lite-synaptic.png (109.56 KiB) Viewed 5438 times

Looking at the build process, when compiling the engine, it pulls in GTK2 libraries inside of itself (kind of like a mini appimage in effect) - so even if it's not available on the target system, it'll still run.

So as long as I keep all my dependencies for compiling, and dependencies for running it - then the engine is not dead "Reports of My Death Are Greatly Exaggerated". It still compiles on Windows and Linux and can still be improved. (albeit with controls that don't match GTK3 or GTK4 versions) - but that's no different to Windows (windows 10 controls in Windows 11) and MacOS (MacOS Catalina controls in Big Sur+).
All three platforms aren't showing controls consistently at this point (if you have a GTK3 theme on Linux installed), but better than having nothing. - Reading up on GTK3, it's not all that great anyway. Would be better to go GTK4.

Just to give you an idea with timeframe of that alone:
have a look at this Gimp news page.
Work started in Gimp, to update GTK2 to GTK3 on the 6th of November, 2020.
They didn't finish that until the 9th of July, 2023. Bear in mind, there's a whole team of people working on Gimp. Over here, not so much - so I have no plans to try and replace the GTK2 with GTK3/4 in the engine source. Especially while GTK2 libraries are embedded in both the engine and the standalones at build time.

(The example above shows the live distro I mentioned, of OpenXTalk Lite. GTK3 only installed, and the engine functions and IDE runs fine).

openxtalk-lite-liveCD.png (151.34 KiB) Viewed 5438 times

The Bit-Rot is real, but moreso for MacOS (14+) - same as it's always been, so not much has changed effectively.

[richmond62]

If the Live ISO downloads what it needs 'on the fly' doesn't that come at quite a price in terms of start-up time?

[tperry2x]

Who said anything about the iso downloading anything?
Once you've got the iso, you can run with no internet.

Do you mean about the compile process? That's where the prebuilts and libraries come in. They are already added at the compile stage, so the engine is almost linux agnostic. How it behaves after it starts up is purely down to the way stacks are scripted. Point is, you don't need any extra dependencies/requirements (unless you get into video/sound and speech playback - which we've already covered elsewhere, if I could only find it...).

[richmond62]

Who said anything about the iso downloading anything?
Once you've got the iso, you can run with no internet.

That's about as near to magic as you can get.

Can one save preferences?

[tperry2x]

Um, yeah - if you install it to your computer.

Alternatively, If you run off a DVD, then everything is read only.
If you imaged and run off a USB, then things are saved as you work. As soon as you restart, it'll be gone though.

If you wanted to save stacks, keep them after a restart, but NOT install the ISO (let's assume you are testing)... you could just save stacks to an external USB device that you plug in.

I've set default (non-annoying in my-opinion) settings in OpenXTalk lite - but can't please everyone.

You might ask how you install it - so you can use it as a full OS, that's [menu] > Control Centre > Disks > "Install AntiX Linux"

to-install.png (64.73 KiB) Viewed 5405 times

[richmond62]

Aha: so this is NOT just an ISO image containing a Linux build of OXT Lite: it is an ISO image of a whole operating system with OXT Lite installed.

So: were I to clone that ISO image to a USB stck I could boot from it and install that on that 'spare' PC thingy I have over there in the corner . . .

HOWVER: before that I am about to do something I think everybody else who has a warped sense of humour (err: in this case it 100% is 'Humor') should do:

A binge session of 'Police Squad' (which I missed in 1982 as was then living on an island in a house without the questionable benefits of electricity.

No need to do any 'naughty' pirate stuff either:

https://archive.org/details/PoliceSquad

The 3 films will also keep me out of trouble while my wife is away in Scotland.

[tperry2x]

Aha: so this is NOT just an ISO image containing a Linux build of OXT Lite: it is an ISO image of a whole operating system with OXT Lite installed.

So: were I to clone that ISO image to a USB stck I could boot from it and install that on that 'spare' PC thingy I have over there in the corner . . .

Indeed you could. Making it machine agnostic, kind of (as long as you have a 64 bit intel computer) - NOT for 32-bit machines.

[richmond62]

Slightly extravagant at £50:
-

FREE.jpg (132.87 KiB) Viewed 5393 times

[tperry2x]

Yes, an i3-6100T is indeed 64-bit.
With 8GB of RAM and 500GB storage, should work quite nicely.
(I assume that's a spinning hard disk, not SSD for £50?)

I see they've got a few optiplex machines on there. They are more than adequate to run this live ISO, but that particular brand do suffer from the "yellow light of death", where the RAM needs reseating occasionally.

For 149.00 BGN (£63.75) - with a 256GB SSD - that's not really too bad at all, all things considered, even if the one I found is 12 years old now. I think your model in that picture would probably have been made around 2017. It would tell you in the BIOS.

I did add a system requirements note:

You will need at least 512MB of RAM. (1GB is probably recommended).
You also really need a screen with at least a resolution of 800x600: I've added an icon to the toolbar to adjust your screen resolution (AandR).

That's in the "Read me first.txt" - along with a bit more info if you need it.

Bear in mind that the OXT Lite engine is compiled on 13 year old hardware for the Linux and Windows build (both with up-to-date OS versions) Windows 10 (build [whatever is the latest one on the 'stable' channel]) and Debian Linux 12.9.
Nothing wrong with old stuff if they can still do what you want. The Windows version of the engine is also 64-bit, just like the Linux one. When windows 10 ceases support this year with Microsoft, I might have to move to Windows 11 to compile - but I've already got that set up and ready to go if/when needed.

[richmond62]

Actually I feel sorry for that guy: I managed to convince him to send his son to my school.

Very bright boy at that!

Seriously, he's kept my school going computer-wise these last 20 years.

[tperry2x]

Continuing the digital obsolescence theme...
I think I may have found a way we can run our present engine in MacOS.
Kind of emulated... ish. In a minimal way, bear with me.

Emulated... kind of. No more than what Rosetta 2 is doing (except Rosetta 2 automates the process). If Apple were to drop Rosetta 2 tomorrow (or in their next OS release), I think this might give us a backup plan.

• Rather than having to pipe the output of a linux docker container (Docker isn't free, right??), to then load on the target Mac....

• Rather than having to run a full-blown copy of Asahi Linux (meaning you have to boot an entirely different OS)...

• Rather than having to run QEMU/VirtualBox/Parallels,

• AND rather than having to run an ARM build of Wineskin and emulating the Windows version of OXT inside an ARM mac, I think there might be a fifth way.

The creators of Asahi also have this tool called MUVM. That can be installed on MacOS (could be part of the OXT installer), then this runs something called Sommelier (tar.gz archive) - which runs it through an x11 window into Fex-Emu (that's where the emulation part comes in).

This could all be set up and (in theory) configured into a MacOS pkg installer.
Here's the rough idea if I understand it right:

1. Install MUVM
clone and build MUVM with this (I think, - I think this makes Git behave ):

Code: Select all

git clone --recursive https://github.com/AsahiLinux/muvm.git
cd muvm
make

2. Set Up and start MUVM

Code: Select all

./muvm run --rootfs rootfs.ext4 --network

Once inside MUVM, set up your GUI so it can open applications that aren't just shell scripts. We do this with Sommelier.
3. Install and Configure Sommelier
Sommelier works like an X11/Wayland 'proxy', so Linux GUI apps can communicate with macOS’s XQuartz.
First, install XQuartz on macOS:
(You'd need to install brew - which again, the pkg installer could do for us)

Code: Select all

brew install --cask xquartz
open -a XQuartz

Make sure "Allow connections from network clients" is enabled in XQuartz Preferences. Again, this is scriptable.
Then Inside MUVM, launch Sommelier with:

Code: Select all

sudo apt update && sudo apt install -y sommelier x11-apps
sommelier -X &
export DISPLAY=:0

This effectively does the same as the docker approach, but just without docker.

If we need Wayland support:

Code: Select all

sommelier -X --scale=1.0 --glamor &
export WAYLAND_DISPLAY=wayland-0

4. Install and Run a Linux x64-intel GUI App on AppleARM64 (what a mouthful!)
We now set up fex (more googling) and I think this should do it:

Code: Select all

git clone https://github.com/FEX-Emu/FEX.git
cd FEX
./scripts/install_dependencies.sh
mkdir build && cd build
cmake ..
make -j$(nproc)
sudo make install

We can now run:

Code: Select all

FEXInterpreter ./openxtalk/openxtalk_x86_64/openxtalk.x86_64

It should appear as if it was running natively on Arm.

MUVM gives us the Linux environment (transparently), Sommelier forwards our GUI app of OpenXTalk.
XQuartz displays the Linux GUI apps on macOS, and lastly - FEX-Emu runs x86-64 Linux binaries on AArch64 macOS as if they were 'native'.

When we quit, we just close the FEX, Sommelier and then MUVM processes to exit.

That's my thinking. Just needs putting all together.