Altes Macbook 2009 - lohnt sich OS Update?

[Macbeatnik]

Nutzt du die Apps eventuell im Vollbild Modus?

 

[tkreutz]

Ich habe ein bestehendes, sehr altes DJ Programm, das Hardware verbunden ist. Nun will ich dort auch upgraden. Da ich nicht weiss, .....

Daher der Spruch: "never change a running system". Darüber kann man natürlich streiten, aber ein Experimentalsystem bleibt eben ein Prototyp und sollte als solches auch auf einer "Spielwiese" getestet werden. Und dazu nimmt man nicht das System, an dem man täglich arbeiten möchte und die Erwartungshaltung hat, dass alles funktionieren sollte, sondern am besten eine separate Festplatte.

Ich meine, ich würde ja auch nicht zum Spaß in einen alten VW Käfer ein Modding mit Umrüstung auf Elektromobil im Retro-Design machen, wenn ich nicht wüsste, wie es geht und exakt diesen Vorgang schon tausendmal gemacht hätte. Nur - so ein Hinweis. Aber - musst Du natürlich selbst wissen.

 

[Butterfinger]

auf welchem System was stabil oder besser läuft

Ich würde da eher auf El Capitan bauen, da Mojave teilweise buggy auf den nicht unterstützen Geräten läuft. Alleine die Updateprozedur ist teilweise nicht so geil.

 

[tkreutz]

Ich würde da eher auf El Capitan bauen, da Mojave teilweise buggy auf den nicht unterstützen Geräten läuft. Alleine die Updateprozedur ist teilweise nicht so geil.

Dazu gab es auch entsprechende Fachartikel z.B.
https://www.maclife.de/news/alte-zo...e-nicht-allen-high-sierra-macs-100103393.html

Mag sein, dass man es auf älteren Geräten installieren kann, aber dies kann schon zu Problemen bei der Grafik führen.

Und hier scheint sich etwas wesentliches geändert zu haben. Denn umgekehrt gibt es ähnliche Effekte. Auf einem neuerem Mac Book Pro gibt es bei virtualisierten älteren Systemen Probleme mit der Grafik - heißt konkret, eine "virtualisierte" Maschine, die auf altem Mac lief, funktioniert plötzlich nicht mehr auf neuerer Hardware. Ich teste so was regelmäßig, weil ich immer wissen möchte, wie weit ein aktuelles System noch nach vorne oder hinten unterstützt und ob ich ältere Hardware noch vorhalten muss oder nicht, um bestimmte Anwendungen laufen lassen zu können.

Leider ist es bis heute unabdingbar, bestimmte Hardware vorrätig zu halten. Sonst ist man irgendwann verloren - sogar im Zeitalter von Emulationen und Virtualisierung.

Wer dass probieren möchte, versucht einfach ein Spiel aus älteren Zeiten zu laufen, was hardwarenahe Unterstützung braucht. Hier sieht man dann auch sehr schnell, ob es möglicherweise Probleme gibt bei dem Wechsel auf neuere Hardware.

 

[errorlog]

Mag sein, dass man es auf älteren Geräten installieren kann, aber dies kann schon zu Problemen bei der Grafik führen.

Vielleicht wäre es in diesem Zusammenhang wichtig, den technischen Hintergrund zu verstehen: Apple hat 2014 offiziell OpenGL durch einen eigenen Standard namens Metal ersetzt.

Gleichzeitig sind aber die Entwickler verplichtet, die zu dem OS "passenden" Anwendungen auf der Basis von Metal zu realisieren.

Der Patch macht nichts anderes, als bei "unsupported Macs" das Metal "abzustellen" und trotzdem die Installation des MacOS zu ermöglichen (jetzt mal ganz platt und einfach erklärt).

Deshalb kann es nicht zu Grafikproblemen führen, wenn aktuelle Software eingesetzt wird, sondern es wird zu Grafikproblemen führen.

Darüber sollte sich jeder im klaren sein, der diese gepatchten OS-Versionen verwendet!

Bitte jetzt nicht über Sinn oder nicht Sinn von Metal diskutieren. Es ist so, weil Apple es will, und wir werden nichts daran ändern.

Diese Diskussionen sind alle zuhauf vor Jahren gelaufen.

 

[tkreutz]

Gleichzeitig sind aber die Entwickler verplichtet, die zu dem OS "passenden" Anwendungen auf der Basis von Metal zu realisieren.
Diese Diskussionen sind alle zuhauf vor Jahren gelaufen.

Ich stelle mir mal eine Szene von 2 Archäologen vor, die eine Ausgrabung machen und der eine zu dem anderem sagt: "Heureka, Jens - ich habe die Antwort gefunden, Du kannst diese Maschine nicht zum Laufen bringen, hier ist ein in Stein gemeistelter Artikel aus Knowledgbase xxx mit dem Hinweis.....".

Wirklich traurig, dass wir durch die Abhängigkeit von Änderungen an Hardware immer tolle Features gewinnen aber dabei Möglichkeiten verlieren, dessen Verlust wir zu einem viel späteren Zeitpunkt erfahren.

 

[Dj-X]

Nutzt du die Apps eventuell im Vollbild Modus?

Ja, aber im Alltag beim Arbeiten oder Surfen nicht

 

[Dj-X]

Daher der Spruch: "never change a running system". Darüber kann man natürlich streiten, aber ein Experimentalsystem bleibt eben ein Prototyp und sollte als solches auch auf einer "Spielwiese" getestet werden. Und dazu nimmt man nicht das System, an dem man täglich arbeiten möchte und die Erwartungshaltung hat, dass alles funktionieren sollte, sondern am besten eine separate Festplatte.

Ich meine, ich würde ja auch nicht zum Spaß in einen alten VW Käfer ein Modding mit Umrüstung auf Elektromobil im Retro-Design machen, wenn ich nicht wüsste, wie es geht und exakt diesen Vorgang schon tausendmal gemacht hätte. Nur - so ein Hinweis. Aber - musst Du natürlich selbst wissen.

Never change... Ja, denke ich genauso. Aber nach so langer Zeit muss ich mir was Neues gönnen; das funktioniert dann nicht mehr auf dem alten System...einen Tod muss ich eben in dem Falle sterben.

 

[tkreutz]

Never change... Ja, denke ich genauso. Aber nach so langer Zeit muss ich mir was Neues gönnen; das funktioniert dann nicht mehr auf dem alten System...einen Tod muss ich eben in dem Falle sterben.

Würde natürlich absolut mehr Sinn mit neuer(rer) Hardware machen - da auch der Spaßfaktor nicht auf der Strecke bleiben sollte.

 

[Benutzer 236231]

Abenteuerliche Diskussion hier!

Habe für den täglichen Einsatz ein 15" early-2008 MBP4,1 c2d 2,4GHz, 6GB RAM und SSD. Das läuft mit ElCapitan zufriedenstellend gut. Alles, was danach kommt und ElCapitan-fähig ist (siehe Everymac.com), sollte mit einem vergleichbarem System eigentlich auch klarkommen.
Man kann/sollte bei alten Maschinen mit dem System-Tool Onyx diverse grafische Gimmicks abschalten, damit das System weniger belastet wird.
Für Datensicherung würde ich primär CarbonCopyCloner hernehmen, weil das wesentlich schneller ist, als TimeMachine und anstelle inkrementeller Sicherungen einen bootfähigen Festplatten-Klon erstellt. Und man kann zusätzlich eine passende RecoveryPartition auf der externen HDD erstellen
Bevor irgendein OS-Upgrade ansteht, würde ich deshalb erstmal mit CCC ein Festplatten Image auf eine externe USB-Platte erstellen.
Wenn man plant, eine neue SSD zu installieren, klont man mit CCC die interne Platte vor dem Umbau per USB/FireWire/etc auf die neue SSD. Wenn die SSD gross genug ist, kann man mehrere Partitionen für das Testen weiterer OSX-Versionen anlegen.
Damit hat man:
1. die Originale Installation (+ ggf. Recovery) auf der internen HDD
2. Einen bootfähigen Klon (+ ggf. Recovery) auf einer externen USB-Festplatte und
3. einen bootfähigen Klon der Original-Installation (+ggf. Recovery) auf der neuen SSD (plus evtl. zusätzlicher freier Partitionen)
Die SSD dann gegen die interne HDD tauschen (damit hat man 2 Sicherungen des Original-Systems).
Ich würde, um ein Schlamassel mit APFS zu vermeiden, komplett im HFS+ File-System bleiben. Bis Mojave kann macOS optional auf HFS+ installiert werden. Erst Catalina erfordert APFS.

Und erst dann kann's mit dem Upgraden losgehen...!

Startet man mit einem Original-Sytem (z.B. in SnowLeopard), gibt's dann die Möglichkeit:

1) SL über die "offiziellen" Schritte bis auf ElCapitan upgraden. D.h. das Original-System mit allen Nutzer-Daten bekommt schrittweise ein Upgrade auf das letzte OS (z.B. ElCapitan).
Bei jedem Upgrade-Schritt kann man zusehen, wie einzelne Apps "rausfliegen" ...

2) eine komplette Neuinstallation auf eine noch freie Partition der neuen SSD mit anschliessender Übernahme der Daten aus dem Original-System mit dem Migrations-Assistent (Dienstprogramme-MigrationsAssistent)
a) das neue System kann über die Schritte SL-Lion- ... - ElCapitan aufbauend installiert werden.
b) man hat einen USB-Stick mit einem OSX (oder macht sich einen ... dosdude1-Mac OS X USB Drive Creator)
c) man bootet von einer bestehenden (ElCapitan-)Recovery (intern oder USB) und installiert das zur Recovery passende OSX per Download auf die interne SSD.
d) man installiert Sierra/HighSierra/Mojave mit dem Patch von dosdude1 (das zum Patch passende erforderliche macOS zum Erstellen eines bootfähigen Installationsmediums kann dabei mit dem "Patcher-Programm" von dosdude1 vor der ganzen Prozedur heruntergeladen werden.)
Es kann auch mit einem der Patches ein Upgrade des Original-Systems von ElCapitan weiter auf Sierra/HighSierra/Mojave durchgeführt werden.

Ich würde bei den Patches auf jeden Fall "Testläufe" auf eine freien Partitionen der neuen internen SSD empfehlen und updates eines Original-Systems nur machen, wenn ich 2 bootfähige Festplatten-Klone als Sicherung habe.

Habe die Patches (HS/Mojave/Catalina) mittlerweile alle auf einem separaten MBP4,1 (wie oben beschrieben, allerdings mit nur 4GB RAM) installiert und ausprobiert.
Mein Original-System und alle anderen Macs haben mittlerweile alle ein Patch-Upgrade (oder Downgrade) auf HighSierra bekommen.
HighSierra und Mojave laufen auf dem early-2008 MBP4,1 mit C2Duo und 4GB gut, aber am Limit. Web und VideoStreaming(SD) sind ok. Werde nach Aufbau eines parallelen Systems mit Mojave, wenn alles läuft, mein HighSierra entweder per Migrations-Assistenz rüberziehen oder die HighSierra-Installation per Patch upgraden.
Catalina ist auch einigermassen gut gelaufen, kommt aber für mich aktuell nicht in Frage, weil eine Menge für mich wichtige 32-bit-Programme und mein ScanSnap1500 nicht mehr unterstützt werden.

Wenn man alle Testläufe auf den separaten Partitionen durch hat, kann man im Festplatten-Dienstprogramm die nicht mehr gewünschten Partitionen (nebst der darauf befindlichen macOS-Experimente) löschen und den frei gewordenen Platz dann dem "überlebendem" System einverleiben. (Auch deshalb alles primär in HFS+ halten, um Schlamassel mit APFS zu vermeiden!)

Für den beschriebenen Fall, dass man noch alte Software hat, die z.B. Rosetta/SnowLeopard oder eine andere ältere Version von OSX erfordert (z.B. Tiger ), kann man ja noch das alte Original-System parallel auf der neuen SSD bestehen lassen ...

Es gibt dann noch einige Feineinstellungen nach Installation der Patches um das System zu entlasten:
- Systemeinstellungen/Bedienungshilfen/Anzeige/Transparenz reduzieren: korrigiert dunkelgraue Menü- und Seitenleiste im LightMode von Mojave
- Onyx: Einstellungen zum Reduzieren von grafischen Effekten, Abschalten von Dashboard etc
- Systemeinstellungen/Spotlight/Privatsphäre: Spotlight Indizierung auf Hauptpartition beschränken
- Grey: Programm, um den totalen DarkMode aufzuknacken, und einzelne Apps im LightMode darzustellen (oder umgekehrt)
- Tastatur-Shortcut, um zwischen DarkMode und LightMode zu wechseln
- Gesichtserkennung der Foto-App abschalten

Mit iStatMenus lässt sich gut die Performance, die für das MBP4,1 essentielle GPU/CPU-Temperatur und weitere Systemdaten überwachen ...

Der ganze Installations-Aufwand hält sich mit CarbonCopyCloner, interner SSD, externer 120GB SSD (für die Erstellung der macOS-Patches), USB2-Verbindung zeitlich gut in Grenzen.

Zu berücksichtigen ist, dass bei manchen Mac die Broadcom Wifi Karte nicht erkannt und deshalb ausgetauscht, werden muss (Alternative: nur Ethernet, kleine WLAN-Ethernet-Bridge, Edimax-USB-mini WLAN-Stick)

 

[tkreutz]

Abenteuerliche Diskussion hier!

Für Datensicherung würde ich primär CarbonCopyCloner hernehmen, weil das wesentlich schneller ist, als TimeMachine und

Ja, schneller und fehlerhafter - so jedenfalls meine Erfahrung. Bei Sicherungen über Netzwerk gab es auch Probleme mit Größeninformation des APFS Dateisystems.

https://www.golem.de/news/carbon-co...tenverlustgefahr-beschraenkt-1802-132831.html

Denkbar, dass diese Probleme mittlerweile behoben sind und nur in bestimmten Szenarien auftreten. Aber pauschal kann man so eine Software nicht empfehlen, es kommt immer auf den jeweiligen Einsatzzweck an. Freilich kann man diesen Fehler dann nicht den CarbonCopyHerstellern anlasten.

Catalina hat übrigens immer noch das Problem falscher Größenangaben bei verschlüsselten Laufwerken. Da wäre ich dann an dieser Stelle vorsichtig.

 

[Benutzer 236231]

Ja, schneller und fehlerhafter - so jedenfalls meine Erfahrung. Bei Sicherungen über Netzwerk gab es auch Probleme mit Größeninformation des APFS Dateisystems.

https://www.golem.de/news/carbon-co...tenverlustgefahr-beschraenkt-1802-132831.html

Denkbar, dass diese Probleme mittlerweile behoben sind und nur in bestimmten Szenarien auftreten. Aber pauschal kann man so eine Software nicht empfehlen, es kommt immer auf den jeweiligen Einsatzzweck an.

Catalina hat übrigens immer noch das Problem falscher Größenangaben bei verschlüsselten Laufwerken. Da wäre ich dann an dieser Stelle vorsichtig.

Ah, gut zu wissen. Aber, wie geschrieben, würde ich aktuell sowieso APFS und Catalina vermeiden und habe mich bisher auf Backups auf lokale USB/Firewire-Festplatten beschränkt. Da hatte ich bisher noch keine Probleme.
Naja und TimeMachine - da hat man in der Regel doch nur eine Sicherungskopie und bei inkrementeller Sicherung. Das nutze ich parallel zu CCC wegen der Option, ggf. eine bestimmte Datei vor Änderung zu rekonstruieren. Habe ich allerdings noch nie benötigt.

 

[tkreutz]

Ah, gut zu wissen. Aber, wie geschrieben, würde ich aktuell sowieso APFS und Catalina vermeiden und habe mich bisher auf Backups auf lokale USB/Firewire-Festplatten beschränkt. Da hatte ich bisher noch keine Probleme.
Naja und TimeMachine - da hat man in der Regel doch nur eine Sicherungskopie und bei inkrementeller Sicherung. Das nutze ich parallel zu CCC wegen der Option, ggf. eine bestimmte Datei vor Änderung zu rekonstruieren. Habe ich allerdings noch nie benötigt.

Ja, die Probleme treten nur in bestimmten Szenarien auf. Bei lokaler Sicherung und ohne APFS sollte es keine Probleme geben.

 

[Benutzer 236231]

Laut Artikel nutzt CCC ja eigentlich nur macOS-Systemprozesse für den Vorgang des Klonens und das Problem liegt bei diesen macOS-Systemprozessen und erstreckt sich auch auf andere Methoden/App, die diesen Weg nutzten. In Mojave sei das behoben, in HighSierra nicht. Und beschränkt auf APFS und SparseDiskImages. Habe Mojave auf meinem Test-MacBook auch auf HFS+ gelassen.
Da kann ich aber erstmal ruhiger schlafen ... aber ein Grund mehr, doch noch alles auf Mojave anzuheben. Danke!

 

[tkreutz]

Laut Artikel nutzt CCC ja eigentlich nur macOS-Systemprozesse für den Vorgang des Klonens und das Problem liegt bei diesen macOS-Systemprozessen und erstreckt sich auch auf andere Methoden/App, die diesen Weg nutzten. In Mojave sei das behoben, in HighSierra nicht. Und beschränkt auf APFS und SparseDiskImages. Habe Mojave auf meinem Test-MacBook auch auf HFS+ gelassen.
Da kann ich aber erstmal ruhiger schlafen ... aber ein Grund mehr, doch noch alles auf Mojave anzuheben. Danke!

Ja, muss man probieren. Als APFS eingeführt worden ist, hatte ich auch Probleme mit den Images. Der Apple Eigene Support hatte mir darauf hin geraten, die Backup-Platten nicht mit APFS anzulegen. Dabei bin ich für die Platten, auf denen die Images liegen dann zunächst geblieben.

Klar, die beste Software kann nur auf den Informationen aufsetzen, die vom System geliefert werden, wenn darin schon ein Bug ist - muss man zunächst dieses Problem lösen.

Man muss auch davon ausgehen, dass eben in älteren Systemen bestimmte Bugs auch nicht mehr behoben werden. Mein Weg ist daher immer, möglichst alle Probleme auf dem möglichst neuerem System zu beheben, damit eine Weile Ruhe ist mit Problemen.