I know, I know… before anyone comes in here with “just use OCLP…”, I’ma stop that line and say, “Sit tight with that suggestion.”
My lament comes from a turnover, even if one long-planned by design, of ever-mounting kludges and security fixes required to keep internet services (whose core functions don’t fundamentally change) running on devices deemed, somewhat arbitrarily, as “obsolete”.
In part, some of my lament also extends to the remedial need to push out security patches for hastily-deployed OSes whose lifespans are now comically short (for which it’s been quite a long while since any version of macOS was given the care, support, and time it needed to mature into a rock solid foundation).
My lament is for needing to make less-than-stellar planning decisions on how one can, should, and/or will use their Early Intel Macs for at least the rest of, well, this decade. I know Silicon Mac adopters may roll their eyes over this. That’s OK: I don’t care. I’m a weirdo: atop well-executed and open software, I also prefer well-designed and well-built hardware, able to handle the rough and tumble of everyday usage, and able to be repaired without jumping through Byzantine hoops or dealing with giant headaches in order to do so.
My specific lament, the one to prompt this post?
As of Signal Foundation’s announcement last month, come March, one may no longer use an iteration of macOS able, simultaneously, to run 32-bit software alongside secure, internet-based services like Signal (and, I’m sure there are many others). Though my handheld phone is the source on which that desktop client relies, I treat Signal more as a texting platform. This means using the desktop client. As such, typing replies on a physical keyboard is, always, more intuitive and, always, less annoying than doing the same on any glass interface in existence.
Likewise, although offset by @wicknix ’s wonderful project, SeaLion, Mozilla Foundation’s support for Firefox also terminates later this year for the last versions of macOS able to, again, also handle the 32-bit stuff. (Dropping Mojave did come as a minor surprise, honestly, in that it was the first major version to set the groundwork for the current trio of Apple-supported macOS builds — Metal baseline support, foremost, coming to mind.)
For the “just use OCLP…” subset of folks I’ve asked to sit tight until after this post, virtualization is not a workaround, especially around audio/MIDI-related demands. No amount of running VMware Fusion or Parallels on a late Intel Mac with Sonoma as its host OS can navigate entirely around those limits. There’s a place for singular-focus tools and another for Swiss Army knives. I’ve always tended to keep the latter around, as they’re far more indispensable.
I doubt there will be a way to work around, say, the Signal support issue — no way to trick Signal to rely on security protocols and patches for an OS lacking them. So this may mean, for me, at least, needing two classes of Early Intel Mac models running as daily drivers (instead of merely one) — one with Mojave (and also, well, a second partition with Snow Leopard, because obviously), and another with, probably, Monterey (as, arguably, the least troublesome of the 64-bit-only, post-macOS 10.x builds).
This shift may, at long last, be what finally nudges me toward migrating more and more of my work to some kind of a Linux-based OS destination (I know, perish the thought: “this is the year of desktop Linux!”), but even that doesn’t resolve using Internet services without relying on using some kind of VM setup — even if the guest OS is what runs the Linux portion.
So, my lament for a fantastically long run of versatility workarounds which make the Early Intel Macs (and the PowerPC Macs) forums the scrappy, wonderful places they’ve always been. It is my lament for a run shortened by synthetic, planned obsolescence which few, other than shareholders, really ever pine for.
And a happy new year to all.
My lament comes from a turnover, even if one long-planned by design, of ever-mounting kludges and security fixes required to keep internet services (whose core functions don’t fundamentally change) running on devices deemed, somewhat arbitrarily, as “obsolete”.
In part, some of my lament also extends to the remedial need to push out security patches for hastily-deployed OSes whose lifespans are now comically short (for which it’s been quite a long while since any version of macOS was given the care, support, and time it needed to mature into a rock solid foundation).
My lament is for needing to make less-than-stellar planning decisions on how one can, should, and/or will use their Early Intel Macs for at least the rest of, well, this decade. I know Silicon Mac adopters may roll their eyes over this. That’s OK: I don’t care. I’m a weirdo: atop well-executed and open software, I also prefer well-designed and well-built hardware, able to handle the rough and tumble of everyday usage, and able to be repaired without jumping through Byzantine hoops or dealing with giant headaches in order to do so.
My specific lament, the one to prompt this post?
As of Signal Foundation’s announcement last month, come March, one may no longer use an iteration of macOS able, simultaneously, to run 32-bit software alongside secure, internet-based services like Signal (and, I’m sure there are many others). Though my handheld phone is the source on which that desktop client relies, I treat Signal more as a texting platform. This means using the desktop client. As such, typing replies on a physical keyboard is, always, more intuitive and, always, less annoying than doing the same on any glass interface in existence.
Likewise, although offset by @wicknix ’s wonderful project, SeaLion, Mozilla Foundation’s support for Firefox also terminates later this year for the last versions of macOS able to, again, also handle the 32-bit stuff. (Dropping Mojave did come as a minor surprise, honestly, in that it was the first major version to set the groundwork for the current trio of Apple-supported macOS builds — Metal baseline support, foremost, coming to mind.)
For the “just use OCLP…” subset of folks I’ve asked to sit tight until after this post, virtualization is not a workaround, especially around audio/MIDI-related demands. No amount of running VMware Fusion or Parallels on a late Intel Mac with Sonoma as its host OS can navigate entirely around those limits. There’s a place for singular-focus tools and another for Swiss Army knives. I’ve always tended to keep the latter around, as they’re far more indispensable.
I doubt there will be a way to work around, say, the Signal support issue — no way to trick Signal to rely on security protocols and patches for an OS lacking them. So this may mean, for me, at least, needing two classes of Early Intel Mac models running as daily drivers (instead of merely one) — one with Mojave (and also, well, a second partition with Snow Leopard, because obviously), and another with, probably, Monterey (as, arguably, the least troublesome of the 64-bit-only, post-macOS 10.x builds).
This shift may, at long last, be what finally nudges me toward migrating more and more of my work to some kind of a Linux-based OS destination (I know, perish the thought: “this is the year of desktop Linux!”), but even that doesn’t resolve using Internet services without relying on using some kind of VM setup — even if the guest OS is what runs the Linux portion.
So, my lament for a fantastically long run of versatility workarounds which make the Early Intel Macs (and the PowerPC Macs) forums the scrappy, wonderful places they’ve always been. It is my lament for a run shortened by synthetic, planned obsolescence which few, other than shareholders, really ever pine for.
And a happy new year to all.
