I love the Tiger through Snow Leopard era of Mac OS X, and I feel I could be productive on a G4, G5, or early Intel Mac for lightweight computing tasks, though I’d need to use another device for web browsing and for handling modern file formats.
I think one of the major challenges of using modern software on early versions of Mac OS X (and even on current macOS releases) is the fact that Linux has become the de-facto standard Unix-like operating system, and modern Linux with systemd, Wayland, dbus, and other technologies have deviated greatly from POSIX and other classical Unix technologies. Granted, the world has moved on since the last POSIX revision, and commercial Unix (e.g., Solaris, HP-UX, AIX, etc.) is not as commonplace compared to 20 years ago. Still, this has impacted the BSDs; their development communities are more conservative and some people have strong feelings about technologies like systemd and Wayland, but since Linux has a higher marketshare and an increasing amount of software is written for it without regard for the BSDs and other systems, then Linux has become the standard and the BSDs have to deal with a fragmented software base that once cared about portability among *nix systems.
I wonder, though, how difficult would it be to replace older versions of Darwin (the open-source BSD and Mach layers of macOS) with updated code while ensuring the proprietary layers running on top of Darwin still work? This might be a good approach for helping older macOS versions run newer software, as well as adding compatibility layers to deal with Linuxisms. I remember reading about experiments updating the kernels of NeXTstep and Rhapsody in a similar fashion.
> modern Linux with systemd, Wayland, dbus, and other technologies have deviated greatly from POSIX and other classical Unix technologies
Systemd is inspired by/imitating launchd; macOS did it first, to much less fanfare, and therefore much less awareness.
The evolution of Cocoa alongside GCD, XPC, and launchd would probably mean a lot of difficulty in backporting. Things shifting between kernel and userspace and launchd services with restrictive permissions won't be kind to a lot of software of reasonable complexity.
In the long run it might be more fruitful to build a FOSS true clone of the Mac desktop for Linux and the BSDs. It’s going to take a massive amount of work to produce something even as smooth as OS X 10.4, 10.6, or 10.9, though.
It’s something I’ve done a little bit of research into, and on top of the usual challenges posed by developing a DE you’d also be fighting the momentum of the two dominant desktop paradigms open *nix software is built for, which is Win9x-type (KDE, Cinnamon, LXDE, and kinda XFCE) or iOS-type (GNOME, Pantheon).
Perhaps the hurdle with the most visible impact is the global menubar, which is currently kind of doable with Qt-based apps, but is broken in GTK apps (plugin is unmaintained) and totally nonfunctional in Wayland. I think that perhaps the best approach to solving this is to build a proof of concept generalized approach for applications to expose their menubars to the desktop environment with and submit it as an XDG standard that hopefully the big guys eventually adopt.
There are two projects that you may be interested in:
- helloSystem (https://hellosystem.github.io/docs/) —- an OS inspired by macOS that uses FreeBSD as its base and uses the Qt toolkit for rendering UI elements.
- ravynOS (https://ravynos.com/) —- a more ambitious attempt to create a FOSS clone of macOS. FreeBSD is still the base, but it does not use X11 at all for windowing.
There is also the venerable GNUstep project, which aims to provide a FOSS implementation of the Cocoa API.
These are massive undertakings. I haven’t kept up with these projects in a while, so I don’t know their current status.
My main issue with these two (and don't get me wrong: I'm delighted people are trying) is that they hit the uncanny valley pretty hard. They get enough of it right that the small differences really stick out, particularly things like font and text positioning. It almost makes me wonder if a Aqua-esque window manager with window buttons on the left -- and stopping there -- would be more successful than trying to get all the quirks in.
At minimum, to escape the uncanny valley it’d be necessary to develop a new suite of standard utility apps that closely follow the older, more detailed OS X HIG[0]. Forking existing apps and modifying them could also work, but details are almost certainly going to be missed.
Have been keeping my eye on these too. The approaches taken by the first two aren’t how I think I’d go about it, but I don’t have a project yet so what do I know haha.
GNUStep is interesting but I don’t see it gaining a significant following with Swift sucking up the majority of air out of the room for apple-platform-adjacent projects.
For years I’ve wanted a FOSS macOS clone, but in recent years my interest has shifted away from that and toward what inspired NeXT (and the Mac) in the first place: the Smalltalk environment. I’ve dug down deep rabbit holes exploring Smalltalk, Lisp machines (particularly the Symbolics Genera and Xerox Interlisp-D environments), HyperCard, Apple’s Lisp-inspired work in the 1990s (Dylan, SK8), and the OpenDoc component-based software framework.
My dream OS would be something with malleable, component-based underpinnings (like a Lisp machine or the Smalltalk environment, but with everything we’ve learned about security, type systems, parallelism, and other concerns since the 1980s when Lisp machines and Smalltalk were in vogue), extensive support for programmability (everything is an object), and with an interface inspired by Mac OS 8 (I love Tiger, but from an interface point of view I prefer the classic Mac OS more). Unfortunately my free time is limited, so I haven’t done much work at all, but it hasn’t stopped me from dreaming and writing a few occasional documents.
I really don't understand why people keep pushing this misconception. GNOME certainly doesn't have to be for everyone, but this canard is needlessly dismissive and based on a childishly superficial apprehension of GNOME. Just because there is a full screen menu, and the desktop is uncluttered by extranious UI clutter so you can just focus on your task and use the keyboard to control windows and navigate, that makes it "iOS like"? At that point what does that even mean?
If anything, I'd say GNOME is far closer to a tiling window manager. Again, I'm not saying this workflow has to be for you, but it is a consistent, desktop class workflow of its own: a keyboard- and virtual desktop-centric workflow focused on filling the screen with applications via full screens or splits so you can focus on your work, with no extraneous UI elements made obsolete by virtual desktops that only stick around because people are used to them like taskbars, docks, and minimization buttons. The logic of this is excellent IMHO. There is no need for a taskbar to manage minimized or occluded windows if you can just banish windows to other virtual desktops to get them out of the way, but still see them immediately in a multidesktop expose view and fuzzy window search, and new desktops will be fluidly created for you as you fill them up; no minimization button for the same reason; no need for a dock or pinned application icons because an extremely powerful spotlight-style fuzzy application launcher (with built in app menu search, calculator, web search, file search, definition finder, etc) and a dock, combined with a very useful expose and workspace overview conveniently arranged there for you in a single screen, is a single click or key tap away, etc. It seems to me people just assume that since GNOME doesn't have things they're used to from UIs they associate with "work", it's must be a "toy."
I don’t disagree with you, but I believe I know why there is antipathy against GNOME. GNOME 3 isn’t directly inspired by iOS, but it came about during a time when some people thought that traditional Windows- and Mac-like desktops were outmoded and that the industry should move toward more mobile-friendly user interfaces. This led to Windows 8, Ubuntu’s Unity, and the gradual inclusion of iOS elements in macOS. Generally detractors of GNOME 3 are also detractors of these desktops.
Alongside other controversial changes in Linux such as systemd and Wayland, I think some of the antipathy toward GNOME 3 is caused by resentment and the strong network effects these projects have. If GNOME had little influence over other projects, these strong feelings would’ve been much weaker. However, GNOME is one of the most influential projects in the FOSS desktop computing ecosystem, with major consequences even for people who don’t use GNOME. For example, GTK over the years went from a generic toolkit to a much more GNOME-specific one, with consequences for developers and users of GTK-based software who were not fond of GNOME’s major changes beginning with GNOME 3. GNOME also drove the adoption of systemd and Wayland, which is also a source of consternation.
Yes, GNOME developers have the freedom to do what they want with their own software. But there is resentment by some users regarding GNOME’s influence and how the goals of GNOME, Red Hat, and other major players in the Linux ecosystem don’t always align with the Unix philosophy. Change is hard for some people to accept, especially changes people feel are for the worst, whether or not they are actually worse.
One thing that I think that Unity got more right than others was how not only did it not try to sweep its menubars into hamburger menus, but in fact leaned into menubars with its design and the HUD, which instantly made every program more keyboard-accessible even for those who didn’t know shortcuts. More DEs should copy that aspect.
Please excuse this incredibly long post. Your post was insightful and polite, so I wanted to respond as thoughtfully as I think it deserves! :D
---
The knee-jerk reaction to the new GNOME interface was, I agree, understandable at the time, given the Zeitgiest — if you're in a time when you're seeing a lot of interfaces move towards being less usable in your eyes, in favor of chasing largely wishful thinking, you might well react strongly to the smallest sign of it in other places. However, I think this reaction was ultimately misguided at the time, and is even moreso now, more maintained by resentment that has long since reached the point of being self-sustaining than anything else, which is what I felt I was responding to originally.
The concessions to touch oriented devices in the design in GNOME 3 are mostly superficial, skin deep changes that are perfectly usable on the desktop and also perfectly explicable by other means then focusing on mobile, and more than made up for by a focus on keyboard navigation (a uniquely desktop-oriented trait).
For instance, if you're scrolling through your applications looking for one, you're not going to have your attention on anything else in the screen, so why does the menu need to take up a small amount of the screen, instead of taking up the whole screen and being able to show you more results?
Or, similarly, if we look at title bars, all GNOME did was essentially merge the tab bar, action button bar, and title bar into one — a move that necessitated larger title bars to maintain button sizes in line with those in the application window itself, which makes sense, since they now ARE application buttons, but in return unified a number of often stacked UI bars with overlapping purposes into a single cohesive entity, probably overall decreasing the amount of space taken up by the header area of many applications overall. In light of this change, moving menus into a hamburger also makes perfect sense: if every application now has an action bar, all the common menu bar actions will be covered there, arguably more discoverable and convenient than before, so being forced to make room for those action buttons by putting the rest of the menus behind a universally understood, common icon (adding at most one click, and likely actually being a wash, since hamburger menus in GNOME tend to be flatter), is a small price to pay, especially since, again, it also helps merge two bars into one, actually saving space.
The network effects criticism seems like a much more reasonable one to me, but I still don't find it particularly convincing, and I suspect it often serves as rationalization for self perpetuating resentment and fear of change.
First of all, I don't see the problem with having various projects take advantage of each other's functionality where it makes sense, and in fact I think one of the major things that was holding the Linux desktop back is the heretofore all too common focus on making everything a completely generic and replaceable component that doesn't really integrate well with anything else or fully use the features of anything else. Instead, I think it's a very good thing to have a relatively unified, well integrated Linux platform all the way from the kernel up to the DE, as long as it does allow for things to be switched out within reason, has a unidirectional flow of dependencies downward (so no kernel depending on window manager), each platform component is managed as a separate entity with relatively defined interfaces, and allows for alternative platforms to exist. Indeed I think the fear of a unified platform stack being merely extant or popular, as if its mere existence will make dependency chains invert and our systems completely brittle and unyielding, or as if that will erase the existence of alternative Linux distributions that use different stacks (how could you put a stop to that anyway? I think the Gentoo and Void people are far too hardy a breed for that <3), is I think based on paranoia and conspiratorial thinking.
In fact, secondly, I also think the network effect is greatly overstated — it's pretty clear that the lower level systems in the FreeDesktop stack can work perfectly well without the higher level ones, meaning as you approach closer and closer to the parts of the system that actually affect users, modularity grows more and more; and even the higher level ones can often work perfectly well without the lower ones — for instance, Wayland and GNOME both work perfectly well without systemd as far as I know, considering that they both run fine on for instance Void Linux. So the FreeDesktop stack does indeed meet the criteria I mentioned in the first point.
Thirdly, I think the opposition to the specific programs that make up the FreeDesktop (let's call it) stack is mostly based on hidebound traditionalism and fear of change, an almost cargo cult like devotion to the "UNIX philosophy" (most strongly to be seen amongst the suckless crowd, who judge the quality of software by how few lines it contains, irrespective of its problem domain and features, and set themselves arbitrary line limits). Conversely, I tend to believe that "doing one thing well" is oft-misunderstood by that crowd, since IMO it often requires completely and holistically solving a problem from first principles, instead of writing a beautiful, minimal art piece in C that solves only about 80% of the problem (myopically defined) and does so by relying on a zoo of tools that only half work for that solution (like relying on shell scripts for an init system) and leaves the lost 20% of edge cases and nice to have features and the rest of the surrounding problem unsolved so that you have to cobble together a whole another zoo of tools to solve it, and the fear of doing this is mostly just a cargo cult devotion to a just one out of many great software traditions. In essence, I subscribe more to the "GNU philosophy", and agree with Rob Pike when he said that the Unix philosophy is dead and Perl killed it.
Fourth, even if there was a tight interconnection between those platform components, that doesn't really constitute a network effect, just a dependency chain: a network effect would be some means of keeping distro maintainers or users — depending on which perspective you take — on that stack as opposed to any other, but as far as I know there's not really much of that at all, it just so happens that that stack is the most polished and featureful for users, and the most powerful and easy to maintain for distro maintainers and system administrators. It seems perfectly possible to switch to an entirely different one if you so choose, as demonstrated by distributions like Void Linux (a real best of breed for its type if distro imo, it looks pretty damn nice if you wanna graybeard it IMO).
[Aside: this is especially the case since someone who objects to one part of the stock is likely to object to all of them, and so having to give up the others in order to give up the one they most strongly object to isn't likely going to be any big misery for them. Someone who doesn't like systemD or Wayland probably wouldn't want to use GNOME anyway, at most they probably be using MATE.]
So really it doesn't seem like this complaint is about network effects at all, but about the very idea of dependencies between things, which just goes back to my comment before about this obsession with modularity to the detriment of making a featureful, reliable system that is actually capable of taking advantage of its own strong points. For instance, why shouldn't an init system take advantage of the unique features and capabilities of its kernel? The idea that everything should be written in is generic manner is so strange to me. Complaints about that, and just about the fact that the free desktop platform dominates the Linux world, but that's more a function of its quality and the amount of work that goes into it, in my opinion.
Thank you for your response. As someone who leans more traditionalist in my computing preferences, this is one of the most thorough and thought-provoking defenses of the GNOME and modern Linux ways of designing systems I’ve read.
“iOS like” is not meant to be an insult. I’ve spent a considerable amount of time using GNOME and I find that iPadOS is its closest analogue — to me, it feels like what you’d get if someone were tasked with taking iPadOS and making it workable for desktop usage. There are a great deal of similarities between the two.
Fair enough! I've never used iPad OS so I wouldn't really have any means of evaluating that it, but the way you frame it seems perfectly reasonable, since it seems like you're granting that GNOME is at least adapted for desktop use. I definitely have seen that statement leveled in a dismissive way, though, quite possibly by people who have never used iPad OS or even regular iPhone OS, so I was assuming it was that again :P
> commercial Unix (e.g., Solaris, HP-UX, AIX, etc.) is not as commonplace compared to 20 years ago.
Other than macOS, you mean? It remains a licensed Unix.
I've rarely run into difficulty running FOSS software on macOS, although I've mostly stopped trying with anything with a GUI; not because Linux-oriented GUI programs don't work but because they subvert too many of my expectations, and I prefer to use something Mac-oriented and ideally Mac-native.
Just to confirm that, I downloaded GIMP, it loads fine, scribbled around on a canvas. Went to close it and it popped up one of those dialogue boxes telling me to either save the file or lose my work. I've grown rather accustomed to programs just behaving correctly, which is to close down, and open up again exactly as I left them. But it does seem quite functional in the usual sense.
There are some tools which are entirely Linux specific, rr comes to mind.
> I wonder, though, how difficult would it be to replace older versions of Darwin (the open-source BSD and Mach layers of macOS) with updated code while ensuring the proprietary layers running on top of Darwin still work?
This is something I've thought about a lot and would love to see pursued.
The Hackintosh community did a lot of kernel hacking and custom kexts early in the Intel transition. It would be great if those people pivoted to PPC backporting or sharing their experiences once Apple drops x86 support in the near future.
> though I’d need to use another device for web browsing and for handling modern file formats
Have you tried running something xquartz and have, say, firefox running on sone other computer on the network? As long as you’re on a fast lan with low noise (basically cable gigabit ethernet?) it should be mostly okay? You’d have to redirect audio as well though…
X11 (no forwarding, it’s really meant to be that way - originally at least) would be the simplest and lightest. If you’re on a private lan you might also turn off cryptography… the powerpc cpu probably either has no crypto acceleration or acceleration for old cyphers.
Other solutions might work… guacamole could work but would use a whole other desktop (whereas x11 would still have some resemblance of integration).
If you’re okay with remoting the whole desktop, xrdp and vnc are also options…
I’ve found that modern X11 toolkits are more bitmap-oriented, so they benefit from ssh’s forwarding with compression enabled, even in gigabit LAN scenarios.
Best setup, specially for browsing, would be ssh or any other way to enable compression, but with null cipher.
Oh man, despite its technical flaws (crashes and bad performance), I still really miss the Dashboard feature from those old Mac OS versions!
Just recently, Apple have started reintroducing desktop Widgets to macOS. But I wish you could make them work like the old Dashboard, ie instantly go to them with a swipe gesture or a Fn-key press.
The old Dashboard was feature just so fast and easy!
Ok, but having to go to the edge of the screen or use a modifier key makes it more painful than it should be. Before when Dashboard was just like an extra desktop to the left of your other desktops, you could just three-finger swipe from anywhere on the screen, any time. Same gesture as switching between desktops. It works that way on iOS too. So simple!
I understand why they dropped the original Dashboard, its widget platform was a technological dead-end. But now that widgets are back it would be awesome if they made the new widgets work like the old Dashboard again.
As the widgets now basically _are_ your desktop, you can display them quite easily.
If you have any part of the desktop visible (e.g. to the left or right of the dock) you can click there so it hides all windows. I'm not sure if you need to enable this somewhere.
Also, there is a trackpad gesture to show the desktop: Keep your thumb stationary and use three fingers to swipe away, as if zooming out.
I don't really want widgets cluttering my desktop, I want them in their own space (ie: their own desktop).
The use case for me for widgets is to display information I want to look at very briefly and then have go away again.
It ought to be pretty simple for Apple to add a "special" desktop for widgets to the left of the first desktop. This would match both the old Dashboard behaviour that I miss, and the way that widgets work on iOS.
(And the gesture you describe isn't "show desktop", it's "show all windows", though I'm sure it can be configured in macOS settings!)
My headcanon is that this was secretly a test run for what an iOS IDE would have looked like under the original (pre-iPhoneOS-2.0) model where there was to be no native SDK since Dashcode 2.0 does actually include the ability to target iPhone Safari.
Jobs' "sweet solution" of web apps wasn't completely terrible - they added native-look widgets to Safari as well as touch capability and multimedia features. I wonder what might have happened if we had gone further down that alternate path...
Even today Amazon somehow managed to make the Luna web client work on Safari, which shows that with an appropriate server back end you can stream some fairly demanding games (and by extension, almost anything) into a web app.
I’m a bit surprised there isn’t mention of big endian issues. Even if libraries nominally support it, I’d be willing to guess there’s a lot of bugs out there due to a lack of active use.
Not to worry, NetBSD has also done their part to make BE really easy to test - they have a big-endian ARM image that you can run on Raspberry Pi hardware, so you don't need an ancient/exotic/expensive box.
I really wonder whether at least some of the compiler related issues can be worked around by using cross-compiling. Sure Xcode has GCC 4.0, but can we have a modern machine run a more modern version of GCC that targets this platform? Linker might be hard so maybe just do the linking on the actual machine.
> Reduce CO2 emissions, keep writing C.
This really made me chuckle. Really!? To reduce CO2 emissions just use a modern machine that's going to be so much more efficient on a performance per watt basis. The author is missing the forest for the trees.
Also, Rust has great cross-compilation support no? Isn't it easier to get Rust code compiled on a modern machine for that old machine?
On any given machine, Rust compilation consumes comparatively more power.
Also, I doubt mere mortals can compile Rust software for PowerPC OS X. LLVM IR isn't backward compatible and Darwin/PPC hasn't been a supported target for a while. If you used a 2018 rustc and LLVM 7.x you might get lucky.
Lot of the issues seem to stem from old GCC. Can't you just build a newer version of GCC (and binutils etc) to make life easier?
> Rust: Even if it worked on this platform
I wonder how much effort getting rust there is actually needed. rustc already has (tier3 level) support for powerpc-unknown-freebsd so PPC OSX doesn't sound like completely out of the question?
I have a Macbook with the last Snow Leopard (10.6.8) which supports PPC through Rosetta and Xcode.
Generally speaking web browsing is the biggest problem if you care about that because there is virtually no supported modern browser (apart from Lynx but that's text based). And even if there would be one the web is totally different compared to ~2010 era. Adblocking is a _must_ and without that any site with ads kills the old Core 2 Duo CPUs
Just spent a fair amount of time figuring out how to make a Mac Mini G4 with Snow Leopard (10.5.8) usable as my home bastion for when I want to access my home systems remotely.
The biggest issues are that Safari and sshd are so old they're basically useless.
- I don't really need a browser on that machine, but for comfort I replaced Safari with the no longer updated but still usable TenFourFox browser. Log into your ppc system and type 'machine' at the prompt. Use the value it shows to choose which version to download from: https://sourceforge.net/projects/tenfourfox/files/fpr32.5/
- For sshd replacement I installed Dropbear as I couldn't get openssh to build. To get Dropbear to build I had to:
1. Comment out "LTC_CFLAGS += -Wno-nullability-completeness" in libtomcrypt/makefile_include.mk and libtommath/makefile_include.mk (as the C compiler didn't know that option).
2. In default_options_guard.h after the #ifndef related to DROPBEAR_SVR_PAM_AUTH, add "#define DROPBEAR_SVR_PASSWORD_AUTH 0" and "#define DROPBEAR_SVR_PAM_AUTH 1" (as OS X needs PAM to log in).
3. Build with:
./configure --enable-pam
make PROGRAMS="dropbear dbclient dropbearkey dropbearconvert scp"
sudo make install
4. Start the new Dropbear ssh server on port 2222 as follows:
mkdir /etc/dropbear
/usr/local/sbin/dropbear -F -E -R -p 2222
You can then ssh into the machine as before (ssh -p2222 user@host) and things like port forwarding work fine.
Nice feeling to have a G4 Mini still doing something useful!
I still use my dual core PPC tower for Max MSP sometimes. I don't really know what I'm doing, but I dig the old layout. Plus it runs pretty well on an SSD.. Currently running Sorbet Leopard which is pretty sweet.
I have an old g3 tower that has 10.4 on it. Haven't powered it on in years. I got it in the mid 2000s to port code I'd written for gnustep to cocoa. Later I wrote a bit of ppc asm. It was a cool instruction set.
I bought a special power macbook from a friend just to be able to support some import programs I maintained on power BE and double-double. Thanksfully those times are over for over a decade now.
I think one of the major challenges of using modern software on early versions of Mac OS X (and even on current macOS releases) is the fact that Linux has become the de-facto standard Unix-like operating system, and modern Linux with systemd, Wayland, dbus, and other technologies have deviated greatly from POSIX and other classical Unix technologies. Granted, the world has moved on since the last POSIX revision, and commercial Unix (e.g., Solaris, HP-UX, AIX, etc.) is not as commonplace compared to 20 years ago. Still, this has impacted the BSDs; their development communities are more conservative and some people have strong feelings about technologies like systemd and Wayland, but since Linux has a higher marketshare and an increasing amount of software is written for it without regard for the BSDs and other systems, then Linux has become the standard and the BSDs have to deal with a fragmented software base that once cared about portability among *nix systems.
I wonder, though, how difficult would it be to replace older versions of Darwin (the open-source BSD and Mach layers of macOS) with updated code while ensuring the proprietary layers running on top of Darwin still work? This might be a good approach for helping older macOS versions run newer software, as well as adding compatibility layers to deal with Linuxisms. I remember reading about experiments updating the kernels of NeXTstep and Rhapsody in a similar fashion.