Mountain Lion went a long way towards fixing Lion's problems, and Mavericks just about finished the job. Which is why I run Mavericks. The only remaining Lion things I really dislike are the Launchpad, the hidden Library folder, and some minor-ish aesthetic differences. I've patched some of these.
Hm. I've never written anything serious for Apple platforms but of course played around for a bit. But, I've always assumed ARC is implemented purely in the compiler, isn't it? I remember disassembling something I wrote and learning that the compiler inserted retain/release calls as necessary.
> Which is why I run Mavericks.
Actually, I ran Mavericks for several years after it was superseded. I was made fun of by some people (who complained about glitchy WiFi on Yosemite, lol). Had to finally update when I got a new job and needed to compile an iOS app, which required latest Xcode, which required latest macOS. Then I stayed on Mojave for like 2 more years, refusing to update to Catalina to keep using 32-bit apps. And then several months ago I bought an M1 Max MacBook, which means Monterey.
ARC does partially work on Snow Leopard, but only for 64-bit, and it's limited (namely, you can't use weak references).
Updating MacOS means I have to spend weeks:
1. Finding third-party utilities to replace what Apple took away.
2. Finding ways to disable the shiny new things Apple added that get in my way and are not officially turn-offable.
3. Finding workarounds for new bugs Apple introduced.
And recently,
4. Disabling all the new phone-home daemons Apple added.
MacOS has become a shitshow.
I didn't use any icloud stuff and was kinda shocked how much the OS called the mothership after installing little snitch ... Never properly gotten into finding what every daemon does and if I could disable it.
I typically have to spend some time bisecting this script to keep the few services I need (e.g. Messages) running. It's time-consuming because some services depend on others that have different names, so it's not as straightforward as simply re-enabling every daemon that contains the string "message."
Little Snitch [1] is also quite useful; it's probably easier to install LS with everything disabled and then gradually reenable the daemons you want. I use LS more than I use the above script these days...although LS still allows the daemons to run and consume CPU time, which the script stops. Probably best to use some combination of both approaches, and keep track of any edits you make to the script because Apple will likely reenable everything the next time you upgrade MacOS.
[0] https://gist.github.com/pwnsdx/1217727ca57de2dd2a372afdd7a0f...
Switching to other OS is not an option for me at this point. Everything else is even worse. Windows is a piece of malware at this point (in addition to being a UX consistency clusterfuck and Microsoft's insistence on making touchscreens a thing), desktop Linux is as much of a nightmare as it's always been.
And unity8 (now Lomri) is in perpetual beta, and written in Qt.
"You say that like it's a bad thing."
> And unity8 (now Lomri) is in perpetual beta, and written in Qt.
Is it now? I wonder if it's a descendant of Unity-2D then. That was in Qt and seems to be forgotten now.
Yes, it does seem mired in dev hell, and I wonder how much is really left to do.
Canonical got a lot of stick, especially on here, about Unity etc. (and still do over Snap).
https://news.ycombinator.com/item?id=14002821
I think it's undeserved. Unity was and is a damned good desktop, it's just different. Some people are neophobic. There's more to life than the Win95 desktop.
IMHO Canonical's only big mistake, really, was Mir.
Wayland remains controversial, and I'm not qualified to judge why. But like systemd, it is basically the new standard, and so going with it would have been pragmatic.
Trying to write a new WM _and_ a new desktop _and_ a mobile OS _and_ a new packaging format _and_ a new display server was a big stretch. Eliminating one big chunk of it seems like a win to me.
Apparently not to them: they pressed ahead and then abandoned the whole thing.
Damned shame. _Someone_ in the Linux world needed to address mobile/tablets. It is the entire herd of elephants stampeding about the room.
IMHO a few sketchy efforts based on GNOME and KDE are not really enough.
Wayland is going to have a hard time being "the new standard" if it continues down it's path of less hardware compatibility, less software compatibility and less overall functionality. I'm willing to point the finger squarely at GNOME here too, because they've intentionally gimped Wayland's development over the years under the guise that they're the lead implementation, while giving the rest of the community the pittance of wlroots. This has been disastrous to the development cycle of Wayland, and ended up splintering the wrong projects and blocking the right features. Stuff like app tray indicators have been completely depreciated on a system level solely because GNOME said they didn't want them. It's really petty, and it certainly isn't moving desktop Linux forward.
In general, everything GNOME-related after Unity has just been a really slow downhill decline. The freshness and uniqueness of the desktop is dead, all we're left with now is a lame Mac clone that can't even play nice with the rest of the community. This is probably a real "old man yells at cloud" moment by most respects, but watching their behavior in recent years frustrates and disappoints me. They used to be a pretty respectable group of maintainers; now it's just drip-fed patches, gutting old features and setting inane new precedents as "the standard" and getting mad at downstream maintainers when they don't adopt them.
I would quibble over:
> Frankly, I don't think Wayland has the functionality to support what people want to do on Desktop Linux.
The problem is that people don't want one single thing from desktop Linux. For some people, for instance, remoting the whole GUI over the network is really important, whereas TBH I suspect that for most people, it isn't important at all and in fact is not only irrelevant, it's actually a hindrance to stuff they want, such as (random examples) very high frame-rate 3D-accelerated true-colour graphics driven by a modern GPU.
And I suspect that you can't have it both ways.
Me, I want independently settable fractional scaling on multiple monitors. I don't give a stuff about frame rates, resolution, hi-DPI support, OpenGL, any of that, but what my 2015 Retina iMac does -- plug in a screen and whatever its DPI the OS just magically adjusts the display settings so everything remains the same size -- that is very important to me. I don't want to do it myself. I don't want or care about or need 3D or anything. I just want all my screens to be nice and sharp and show the same thing at the same size. Resolutions are a trivial implementation detail I don't care about.
My impression is that this isn't on the radar of any mainstream distro.
As for my desktop, I want to be able to place toolbars or panels on the edges of the whole desktop, across 2 or 3 or more screens, where I choose, not where the programmers chose. GNOME is not even able to think about this idea. You get what the designers chose because they know best.
KDE used to do it, badly. KDE 5 does it worse. I don't like it, either.
Oddly, for all the hoopla about Gtk $VERSION and weird stuff about refresh rates and stuff I don't care about, Xfce, the old-fashioned low-tech desktop does this best. Go figure.
All of them are rubbish compared to how macOS handles this stuff, and Windows 10 was only a bit better. Windows 11 is as broken as GNOME etc.
That's progress. Apparently.
It makes me want to go back to a text-only console sometimes. But I am very very old and opinionated, and then I blow the minds of all the xNix fans by saying that I don't actually like the xNix shell and never did. Any of them from `sh` to `fish`, they all annoy me. I preferred the MS-DOS and OpenVMS command lines, myself.
Since most other people who can remember before xNix ruled the waves are retired or dead, that is foul heresy to most techies alive today.
Aqua in OS X 10.9 and below are naturally designed with high contrast and tonal range in mind.