6 ms·
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
by linguae 3y ago
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.
- znpy 3y ago> 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…
- user982 3y agoWhat's the best, most seamless option for this kind of LAN-hosted browser? X11 forwarding, Apache Guacamole, something else?
- znpy 3y agoX11 (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…
- rescbr 3y agoI’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.
- SpecialistK 3y ago> 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. We know that the XNU kernel from Snow Leopard still lists PPC (https://github.com/apple-oss-distributions/xnu/tree/xnu-1504.15.3 https://github.com/apple-oss-distributions/xnu/tree/xnu-1504...) but it probably won't be easy to build and replace a 10.5 kernel with. 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.
- deleted 3y ago[deleted]
- saagarjha 3y agoA lot of code written these days basically assumes little endian so this might be more difficult than just a recompile and patch up unfortunately :(
- samatman 3y ago> 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.
- jwells89 3y agoIn 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.
- logicprog 3y ago> iOS-type (GNOME, Pantheon). 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."
- ynx 3y ago> 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.