Time Capsule in 2022

[agrajag]

Mag sein, daß ich in deiner Aussage etwas mehr reingelesen habe als du tatsächlich meintest. Aber wenn Backup und RAID im direkten Zusammenhang genannt werden, schrillen bei mir die Alarmglocken, da es fast immer auf "RAID ist ein Backup" hinausläuft.

Und wie ich eben schon geschrieben hab, halte ich ein RAID als Backup-Ziel für nur bedingt sinnvoll. Es gibt sicherlich Szenarien, wo das angebracht sein könnte, aber ich denke in den allermeisten Fällen handelt man sich eher ein zusätzliches Problem ein, da die Ausfallwahscheinlichkeit (ganz plump gerechnet) n mal höher ist (mit dem Hinweis darfauf, daß dem ersten Ausfall schnell mal der zweite folgt). Ich würde die Platten lieber rotieren lassen, was die Datensicherheit eher erhöht. Edit: Da hier eine Platte ausfallen kann, ohne die Daten der anderen in Gefahr sind (vrmtl. erst ab 3 Platten relevant), vor allem aber nur die Daten von 1/n der Platten in Gefahr sind im verbundenen Zustand von einer Malware korrumpiert zu werden.

 

[dg2rbf]

 

[Johanna K]

Ich habe nie behaupted, dass die einzelnen Festplatten in einem RAID sich untereinander "backup'en",
[...]
D.h. ich habe die Daten 1x auf dem Laptop und 1x auf dem Raid = Redudant = ein Backup.

Diesen Satz hier

Natürlich kann ein RAID ein Backup sein.

verstehe ich anders in dem Sinne, dass nur das Raid durch die redundante Platte schon ein Backup bedeuten würde, ohne weitere Kopie. Und da es immer wieder Leute gibt, die das tatsächlich so machen und sich dann wundern, dass ihre Daten weg sind, bin ich @agrajag dankbar, dass er dir reingegrätscht ist, auch wenn du es letztlich nicht so gemeint hast, wie es von uns verstanden wurde.

 

[picknicker1971]

dass er dir reingegrätscht ist, auch wenn du es letztlich nicht so gemeint hast, wie es von uns verstanden wurde.

Wenn man das hier nicht verstehen will/kann

RAID ist eine techn. Lösung für die Speicherung von Daten, welche durch mehreren Laufwerken ein techn. Ausfallrisiko minimiert.
Backup ist ein „Prozess“, bei dem durch redundante Speicherung von Daten auf einem anderen Datenträger (welcher in RAID sein kann) das Verlustrisiko minimiert wird.

muss man eben grätschen...

 

[einseinsnull]

Ich hab das Gefühl es nochmal erwähnen zu müssen: RAIDs sind KEINE Backups. RAIDs sollen nur im Falle eine Laufwerkdefektes sicherstellen, daß man weiterarbeiten kann. Nicht mehr und nicht weniger. Es stellt in keinem Falle sicher, daß die Daten im Sinne eines Backups gesichert sind.

das habe ich auch nicht behauptet, ich lehne einfach nur beides für mich persönlich ab, und das aus dem gleichen grund, nämlich weil es scheinsicherheiten sind und man sich schnell vormachen kann, dass jetzt ja nichts mehr schiefgeht.

Wenn die Backup-Lösung was taugt, dann sichert die exakt nur das weg, was du explizit genannt hast, auf eine Weise, wie du sie vorgibtst (Intervalle, Vollbackup oder Inkrementell uws.)

ja klar, das geht natürlich auch.

aber time machine nutzen ja viele leute vor allem um ihr system wiederherzustellen, und merken dann nicht, dass das dann auch viele user daten betrifft.

oder dass diese userdaten eignetlich wichtiger sind als das system, denn das lässt sich mit fleißarbeit auch manuell neu aufsetzen, wenn man so schlau war, immer alle installer aufgehoben zu haben. backups braucht man eignetlich nur ggf. von den prefs.

Ich würde TM eher als "Bevor die überhaupt keine Backups machen"-Lösung sehen wollen.

jap, besser als nix ist es zweifelsfrei.

 

[einseinsnull]

Das und nichts anderes habe ich postuliert.

das mit dem "verlustrisiko" kann man leicht missverstehen, wenn man sich dem thema noch nicht forensisch angenähert hat.

denn du hättest zwar unrecht wenn man anwenderfehler betrachtet (wenn du etwas versehtlich löschst ist es auf beiden platten weg), aber das größere problem ist ja ein technischer totalausfall eines der beiden laufwerke. in der situation schützt spiegeln deine daten zu 99.9%

 

[agrajag]

oder dass diese userdaten eignetlich wichtiger sind als das system, denn das lässt sich mit fleißarbeit auch manuell neu aufsetzen, wenn man so schlau war, immer alle installer aufgehoben zu haben. backups braucht man eignetlich nur ggf. von den prefs.

Das ist ein Problem, was man nicht einfach wegautomatisieren kannst. Entweder du sicherst alles, abzüglich einer Blacklist (die initial ja auch schon von Apple Einträge enthält), oder der Anwender der Backup-Lösung muß sich Gedanken machen. Für den "DAU" ist die Haudrauf-Methode nicht die blödeste, da hier idR. auch nur moderat viele Daten anfallen. Aber die Komplexität steigt sehr steil an. Auf Linux-Systemen würdest du diverse Pfade einfach als eigene Dateisysteme an die entsprechenden Stellen mounten. Das vereinfacht die Backup-Strategie dann erheblich. Bei NixOS z.B. liegt das System auf einem read-only Pfad (/nix) und ist schlicht das Ergebnis der Konfigurationdatei(en) in /etc/nixos. Und die Nutzerdaten liegen in /home. Die letzten beiden packst du ins Backup. /nix wird einfach automatisch bei der nächsten Installation aus /etc/nixos/configuration.nix neu gebaut.

Und je nachdem, was du da betreibst, kann du ja ganz gezielt die Datasets nach völlig unterschiedlichen Regeln an unterschiedliche Ziele wegsichern.

Ich hatte früher gerne die Home-Ordner auf einer Users-Partition und den Shared-Ordner auf einer Shared-Partition. In Shared lag alles, was nicht unbedingt nur meinem User gehören muß, wie z.B. alle Musik- und Video-Dateien. Bei Bildern kann man eher argumentieren, daß sie einem spezifischen Nutzer gehören sollten, ich hab sie aber ebenfalls in Shared abgelegt.

Zu der Zeit hatte ich noch einige Daten auf DVD-RAM rotierend gesichert. Mein User-ordner war so klein, daß der noch auf eine DVD-RAM passte und hab diese dann bei Freunden abgelegt. Heute wäre es ein riesiger USB-Stick oder eine USB-Platte. Auf Shared haben sich die Daten weitaus seltener geändert, so daß hier die Backup-Intervalle deutlich größer sein konnten.

Die User hab ich mittlerweile nicht mehr auf einer Extra-Partition, aber das mit der Shared-Partition mit all den Medien-Dateien mach ich immer noch so. Einer der Gründe, warum ich damals die Userordner auf eine seperate Partition gepackt habe, lag u.A. in der Backup-SW. Bei CCC war es damals etwas umständlich nur Unterverzeichnisse zu sichern. Die Details weiß ich aber nicht mehr.

tl;dr: man kann sich das Backup-Leben durchaus durch anlegen einzelner Datasets (ZFS) bzw. Partitionen und entsprechendes symlinken vereinfachen.

jap, besser als nix ist es zweifelsfrei.

Nichts ist besser als Nix.

 

[picollo]

Ihr seid am Thema vorbei, die Fragen wurden beantwortet: es geht und Client-Modus durch Reset der TC.

 

[agrajag]

Hassjarecht…

 

[einseinsnull]

Aber die Komplexität steigt sehr steil an. Auf Linux-Systemen würdest du diverse Pfade einfach als eigene Dateisysteme an die entsprechenden Stellen mounten. Das vereinfacht die Backup-Strategie dann erheblich.

macOS ist da schon sehr monolithisch aufgestellt - oder zumindest wirkt das so auf normalnutzer, die jetzt nicht unbedingt unix cracks sind und wissen, wie man irgendwas auch umgehen oder erweitern kann.

wenn ich z.b. ordner namens "programme" oder "dokumente" sehe, dann bringt mich schon meine innere querulanz automatisch dazu, die erst mal zu ignorieren und mir irgendwo anders neue anzulegen, von der struktur, wie ich sie gerade brauche.

unter OSX ging das früher (mit ausnahme von updatern von apple, die dann einfach die geänderten dateien in das safari package schreibt, was ja gar nicht da ist) prima, ob es jetzt auch noch so ist, weiß ich nicht.

unter windows bin ich mit dieser einstellung schon mal bös gegen die wand gelaufen, denn auch dort gibt es sachen, die nur im programme ordner funktionieren, z.b. die zuweisbarkeit von dateien ohne dateiendungen zu ihren applikationen.

Zu der Zeit hatte ich noch einige Daten auf DVD-RAM rotierend gesichert.

ist ein geiles medium, ich steh total drauf.

normale DVD-R sind ja von der datensicherheit um ein vielfaches schlechter als CD und Bluray, DVD-RAM hingegen ist sogar besser. notfalls schließt du ordner dann dort eifnach noch ab gegen das überschreiben.

ist nur heute schon fast wieder zu klein, aber es gibt ja auch kleine daten, die "wichtig" sind.


letztlich ist vieles davon einfach auch geschmackssache. jemand, der viel geld hat wird die dinge anders lösen wie jemand der viel zeit hat, und menschen, die sich noch nie aus blödheit ein wichtiges projekt überschrieben haben (muss ich leider mit ja ankreuzen) oder denen noch nie eine HDD kaputtgegangen ist (schon 2 in 25 jahren), werden mein stundenweises kopieren von objektiv eher unwichtigen dingen vermutlich als paranoid und zeitverschwendung einordnen.

 

[agrajag]

macOS ist da schon sehr monolithisch aufgestellt - oder zumindest wirkt das so auf normalnutzer, die jetzt nicht unbedingt unix cracks sind und wissen, wie man irgendwas auch umgehen oder erweitern kann.

Was meinst du damit? Sind $LINUXDERIVAT+KDE|GNOME das nicht auch?

wenn ich z.b. ordner namens "programme" oder "dokumente" sehe, dann bringt mich schon meine innere querulanz automatisch dazu, die erst mal zu ignorieren und mir irgendwo anders neue anzulegen, von der struktur, wie ich sie gerade brauche.

Was ist das Problem damit nahezu JEDES Betriebssystem hat eine innere logische Verzeichnisstruktur. Das ist auch gut so. Ohne weitere Hilfsmittel hättest du sonst Probleme, komplexere SW auch wirklich Lauffähig zu installieren.

Die einzige Ausnahme, die ich kenne ist da RISC OS. Da gibt es nur wenige wirklich festgelegte Ordner (wenn ich nicht irre, ist es im wesentlichen !Boot, was grob vergleichbar mit /System in macOS ist). Ansonsten kannst du da jederzeit beliebige Ordnerstrukturen anlegen und die Anwendungen (die hatten schon immer, seit ca. 1987, App-Bundles) beliebig in Ordner sortieren. Bei RISC OS wurden die Anwendungs-Datei-Verknüpfung bei jedem Neustart neu ausgehandelt und erkannt wo welche Anwendung liegt. Das war ein Feature, was ich heute auch noch gerne.

unter OSX ging das früher (mit ausnahme von updatern von apple, die dann einfach die geänderten dateien in das safari package schreibt, was ja gar nicht da ist) prima, ob es jetzt auch noch so ist, weiß ich nicht.

Ich bin nicht sicher was du meinst. Redest du von SW, die ihre SW nur nach /Applications updaten können?. Da das nervt mich auch. Ich hatte früher™️
meine Anwendungen innerhalb von /Applications nach Kategorien in Unterordner abgelegt. Anwendungen, die z.B. Sparkle als Update-Framework benutzen, haben das Update In-Place gemacht. Egal wo das App-Bundle liegt. Leider gab es dann immer mehr Apps, die unbedingt in /Applications liegen wollten. Entweder weil sie sonst ihren Start verweigert hatten (vermutlich, weil sie schlicht unfähig waren den Bundle-Path flexibel zu handhaben, wie es 1000 andere Apps auch immer konnten), oder weil der spätestens der Updater das Update nach /Applications geschrieben hatte und man dann ZWEI App-Versionen installiert hatte. BusyCal und BusyContacts sind solche Kandidaten.

Ich hatte dann irgendwann aufgegeben und hab dann alle Apps in /Applications belassen.

Da gebe ich dir recht, DAS nervt mich auch. Und da ist Apple IMHO mit ihrem AppStore nicht ganz unschuldig dran. Mein /Applications hat mehr als 400 Einträge und es nervt unfassbar darin nach sehr selten genutzter SW zu suchen, wenn man sich nicht mehr an den Namen erinnert (was bei mir der Standard ist).

unter windows bin ich mit dieser einstellung schon mal bös gegen die wand gelaufen, denn auch dort gibt es sachen, die nur im programme ordner funktionieren, z.b. die zuweisbarkeit von dateien ohne dateiendungen zu ihren applikationen.

Bei Windows ist es IMHO Kraut und Rüben. Wenn ich schon sehe, daß der Sophos VPN-Client die VPN-Profile in seinem Anwendungsordner ablegt, könnte ich die Kriese bekommen. Völliger Murks. Wenn man sich dann vorstellt, daß sie innerhalb der SW auch so arbeiten, dann will man sich direkt nach einer Alternative umsehen. Aber leider müssen meine Windows-Kollegen den benutzen.

ist ein geiles medium, ich steh total drauf.

Das hatte sich ja leider nie durchsetzen können. Und irgendwann waren die Datenmengen auch zu groß, um noch sinvoll (für meine Zwecke) darauf zu sichern.

letztlich ist vieles davon einfach auch geschmackssache. jemand, der viel geld hat wird die dinge anders lösen wie jemand der viel zeit hat, und menschen, die sich noch nie aus blödheit ein wichtiges projekt überschrieben haben (muss ich leider mit ja ankreuzen) oder denen noch nie eine HDD kaputtgegangen ist (schon 2 in 25 jahren), werden mein stundenweises kopieren von objektiv eher unwichtigen dingen vermutlich als paranoid und zeitverschwendung einordnen.

Das Problem ist halt, daß Backups wirklich keine Triviale Sache sind. Daher war Apples TimeMachine ja so ein Ding. Das war aus meiner Sicht das erste wirklich DAU-Taugliche Backup-System. Auch wenn es sehr viele Probleme, gerade in den ersten Jahren hatte. Wer erinnert sich nicht an Meldungen wie "Ach, ich denke ich schmeiss mal dein Backup wech und fang nochmal neu an". Und ewig lange Wiederherstellungszeiten. Als "Wissender" hab ich natürlich eine andere Lösung benutzt. Ich bin z.B. von Anfang an auf CCC unterwegs gewesen. U.a weil zu der Zeit Backup-Systeme gerne proprietäre Datenformate benutzt hatte und man ohne diese konkrete SW nicht mehr an die Backups kam. Und auch sonst war CCC einfach gut. Aber es gab auch viele andere gute Lösungen, die vielleicht andere positive Eigenschaften hatten. Aber da muß man sich schon mit dem Thema Backup und Backupstrategien beschäftigt haben, um für sich die passende SW zu finden.

Das mag man bemängeln, aber es ist so. Entweder du machst die Haudraufmethode wie TimeMachine, oder du must dich als User kümmern. Die SW kann nicht wissen, was für dich wichtige Daten sind und wie und wo du sie gesichert haben möchtest.

 

[einseinsnull]

Was meinst du damit? Sind $LINUXDERIVAT+KDE|GNOME das nicht auch?

linux kann ich nicht beurteilen, aber bei netBSD u.ä. ist das sicherlich genauso. wobei bei apple sich da ja nicht nur auf die verzeichnisstruktur beschränkt sondern der ganze andere kram mit appdownload-monopol, gatekeeper und verifizierungsgedöns noch on top kommt.

Was ist das Problem damit nahezu JEDES Betriebssystem hat eine innere logische Verzeichnisstruktur. Das ist auch gut so.

also amigaOS oder MacOS9 haben das nicht und es war dort nie ein problem.

und man könnte das problem ja auch umgehen, indem man die apps monolitisch baut und nicht auf tausende von dependencies setzt.

Ohne weitere Hilfsmittel hättest du sonst Probleme, komplexere SW auch wirklich Lauffähig zu installieren.

man kann doch einen installer so bauen, dass die eigentliche anwendung den nutzer wählen lässt wo sie hin soll?
das gleiche geht mit dokumenten, voreinstellungsdateien und vor allem mit plug-ins: gib den programmen die option, dass ich den pfad selbst festlegen kann und schon läuft das alles ganz prima, und solche dinge wie "backup" oder "wiederherstellung" sind ein klacks, denn strukturen, die man sich selbst anlegen musste, weiß man viel besser auswendig wie die eines vorgegebenen systems.

dass man so zeugs heutzutage immer öfter zwingend an bestimmten stellen installieren muss hat manchmal sicher gute gründe, manchmal nervt es aber auch.

bei macOS und windows frage ich mich teiweise eher, wozu es überhaupt feste pfade gibt, wenn man sie doch mit ein bischen ausprobieren sowieso umgehen kann, und das dann ja auch zu 95% problemlos funktioniert.

Ich bin nicht sicher was du meinst. Redest du von SW, die ihre SW nur nach /Applications updaten können?

ja, genau.
ich kann dir kein validiertes beispiel nennen, weil das zu lange her ist, aber ich glaube es war unter 10.2 und 10.3 damals so, dass wenn du safari verschoben hast, und dann safari updaten wolltest, dass dir die apple installer neue und zu ersetzende dateien dahin geschrieben haben, wo sie hingehört hätten, obwohl safari garnicht da war. der installer hat dann einen ordner namens "safari.app" in /applications angelegt und die häfte der safari ressourcen reingelegt.^^
direkt im anschluss daran es noch mal korrekt zu probieren scheiterte zumindest via update kontrollfeld dann daran, dass es angeblich bereits installiert war.

Da das nervt mich auch.

meine verfahrensweise ist seitdem (letzter absatz) so, dass ich die mitgelieferten programme dort lasse, wo sie "hingehören", und nur alles andere woanders installiere.

das mit den kategorien mache ich ähnlich wie du. anders könnte ich gar nicht arbeiten.

Da gebe ich dir recht, DAS nervt mich auch. Und da ist Apple IMHO mit ihrem AppStore nicht ganz unschuldig dran.

wenn man user wirklich dazu zwingen will einen bestimmten ordner zu benutzen sollte man vor allem erstens keine rechner im jahr 2020 verkaufen, die 256 gb große SSDs verbaut haben, und zweitens seinem unix-basierten OS mal einen verdammten paketmanager spendieren.

(obwohl ich jetzt installer.app gar nicht mal so schlecht finde und das ja auch von anfang an von sehr vielen leuten dankbar angenommen wurde)

Bei Windows ist es IMHO Kraut und Rüben.

was ich unter windows ja sehr liebe sind VST plug-ins.

da hat man dann im betriebssystem für x32 und x64 bzw. für VST2 und VST3 insgesamt 4 verschiedene pflicht-pfade wo das zeug hin muss, wobei viele produkte gar nicht da reininstallieren, wo das zeug rein soll. viele der anwendungen, die solche plug-ins öffnen können, erlauben aber auch zusätzlich dazu noch eigene pfade oder brignen pflicht-pfade für dieses programm mit.

da ich selbst erstens entwickler solcher host programme und plug.-ins bin und zweitens als anwender - meinem MacOS9 blickwinkel geschuldet - plug-ins am liebsten per drag und drop lade... ich denke, ich muss den satz nicht beenden, you get the idea.

da fliegt dann auch schon mal was gegen die wand.


gut, so netzwerk-, datenbank- und scriptsprachenzeugs ist unter unix natürlich logischer wie unter windows, das ist keine überraschung.

das ist partition cloning oder den gesamter rechnen redundant zu betreiben auch die angemesse verfahrensweise.

das manuelle kopieren ist eher etwas für solche spielkinder wie mich, die ihren kontrollzwang dabei ausleben wollen.

 

[agrajag]

also amigaOS oder MacOS9 haben das nicht und es war dort nie ein problem.

und man könnte das problem ja auch umgehen, indem man die apps monolitisch baut und nicht auf tausende von dependencies setzt.

Ja, aber diese Systeme waren noch weitaus simpler. Vor allem waren das SINGLE-USER-Systeme. So wie RISC OS auch. Das alleine sorgt schon für den Zwang diene strenger zu formalisieren. Wenn du mal hinschaust, wirst du sehen, daß /Applications keinem User gehört.

Was ich an macOS wirklich immer sehr schön fand, ist das Domänenprinzip: Benutzer, Lokal, Network, System (und mit Augenzwinkern noch die App-Bundles. Wenn ich nicht komplett irre, ist das die Reihenfolge, nach der nach angeforderten Ressourcen gesucht wird.

Wenn also eine Anwendung nach Dateien in Library sucht, dann schaut das System zuerst, ob es ein entsprechendes Objekt in ~/Library/ gibt, wenn nicht, dann schaut es in /Library/, dann in der Network-Domäne (keine Ahnung, wie der Pfad da ausschaut). Dann bin ich mir nicht sicher, ob die Ressource noch in /System/Library/ gesucht wird und am Schluss wird im App-Bundle geschaut. Wenn es dann immer noch nichts gefunden hat, gibt es eine Fehlermeldung.

Der Vorteil ist hierbei, daß du so hierarchisch Dateien "überschreiben" kannst. Im Beispiel von MailMate, kannst du z.B. die Keybindings-Datei (ich weiß, man kann auch eigene anlegen, aber das nur als Beispiel) nach ~/Library/Application Support/MailMate/Ressources/Keybindings kopieren und dann nach deinem Wunsch anpassen. Wenn MailMate startet, findet es also dann als erstes die Keybindings von diesem einen Nutzer. Und wenn du die Keybindings für alle lokalen Nutzer modifizieren möchtest, dann kopierst du sie halt nach /Library/Application Support/MailMate/Ressources/Keybindings.

Und nach diesem Prinzip kannst du recht elegant Konfigurationen, Templates, Plugins, Extensions, Farbpaletten und vieles mehr einzelnen, allen lokalen Nutzern oder allen Netzwerkdomänennutzern unterschiedlich zur Verfügung stellen.

Leider ist diese sehr klare Struktur von Apple selbst schon von Anfang an zerfickt worden. IMHO hätten die Daten von Mail, dem Adressbuch, Kalender und vieles mehr nie direkt in ~/Library gehört, sondern nach ~/Library/Application Support. Darüber hinaus haben sich leider viele Devs nicht an die Konventioen gehalten und Dinge nicht korrekt benannt (man schaue sich nur mal ~/Library/Preferences an.

Und die Sache mit dem Sandboxing hat die Sache nicht wirklich übersichtlicher gemacht, mit den Containers und GroupContainers.

man kann doch einen installer so bauen, dass die eigentliche anwendung den nutzer wählen lässt wo sie hin soll?

Ursprünglich war das mal so, daß jeder Nutzer sich eigene SW nach ~/Applications installieren kann. Leider hatte kaum ein SW-Hersteller diese Option im Installer aktiviert dieses Ziel zu wählen.

das gleiche geht mit dokumenten, voreinstellungsdateien und vor allem mit plug-ins: gib den programmen die option, dass ich den pfad selbst festlegen kann und schon läuft das alles ganz prima, und solche dinge wie "backup" oder "wiederherstellung" sind ein klacks, denn strukturen, die man sich selbst anlegen musste, weiß man viel besser auswendig wie die eines vorgegebenen systems.

dass man so zeugs heutzutage immer öfter zwingend an bestimmten stellen installieren muss hat manchmal sicher gute gründe, manchmal nervt es aber auch.

Ich muss sagen, anfangs hat mich das mit den "Zwangsordnern" Music, Pictures, Videos auch extrem genervt, weil ich derartige Daten komplett in /Volumes/Shared liegen hatte (und bis heute habe). Aber irgendwann war es OK und ich hatte es einfach ignoriert.

wenn man user wirklich dazu zwingen will einen bestimmten ordner zu benutzen sollte man vor allem erstens keine rechner im jahr 2020 verkaufen, die 256 gb große SSDs verbaut haben, und zweitens seinem unix-basierten OS mal einen verdammten paketmanager spendieren.

(obwohl ich jetzt installer.app gar nicht mal so schlecht finde und das ja auch von anfang an von sehr vielen leuten dankbar angenommen wurde)

Naja, macOS hatte ja von Anfang an das Konzept mit den App-Bundles. Das + das Konzept mit den Libraries (wo die SW dann die Frameworks findet) hatte es schlicht nicht nötig gemacht.

Paketmanager in der Unix-Welt sind ja eher aus der Not geboren, weil Anwendungen nicht in eigenen Ordnern landen, sondern die Dateien nach Typus (sozusagen) gruppiert sind. Also die bin-Dateien zusammen, Man-pages etc.

Es hat beides Vor- und Nachteile. Letzteres hält das Sytsm kompakter. Aber du handelst dir dann auch viel schneller fiese Versionskonflikte ein.

Ich benutze für macOS Nix als Paketmanager. Der hat den Vorteil, daß es per Funktionsweise KEINE Versionskonflikte gibt. Dazu benutze ich nix-darwin (erweitert Nix um Module für eine deklarative Systemkonfiguration und Launchd-Management) und home-manager (erweitert Nix um Module für eine deklarative Nutzerkonfiguration. Ich beschreibe meine ZSH-Konfig z.B. deklarativ). Darüber manage ich alle benötigten Pakete und Konfigurationen.

Im Prinzip könnte ich auch GUI-Anwendungen darüber installieren, aber das klappt derzeit auf macOS nicht so gut. Hierfür bietet nix-darwin ein Homebrew-Modul. Somit kann ich auch GUI-SW via deklarativer Beschreibung installieren.

 

[einseinsnull]

Ich muss sagen, anfangs hat mich das mit den "Zwangsordnern" Music, Pictures, Videos auch extrem genervt, weil ich derartige Daten komplett in /Volumes/Shared liegen hatte (und bis heute habe). Aber irgendwann war es OK und ich hatte es einfach ignoriert.

habe diese pfade nie benutzt, weil ich shcon die entsprechenden programme nicht benutze.

leider lassen sich die ordner aber nicht löschen oder werden von irgenwelchen utility apps wieder neu angelegt.

Paketmanager in der Unix-Welt sind ja eher aus der Not geboren, weil Anwendungen nicht in eigenen Ordnern landen

ich verstehe das grundsätzlich, finde aber, dass ein richtiger paketmanager wenigstens eine lösung wäre, die dazu führen würde, dass alles immer gleiche funktioniert und alles immer linear ist.

dabei habe ich wie gesagt keine wirkliche erfahrung im umgang mit den macOS der letzten 5 jahre.

besonders schlimm war es ganz am anfang von OSX, wo vor allem auch viele dritthersteller echte probleme mit dem deployment von binaries hatten, wie oft hast du am anfang irgendwo ordner statt bundles gehabt, oder eine anwendersoftware wollte sinnloserweise unbedingt admin rechte, progamme, die unter user installiert wurden haben ihre /application support sachen unter system installiert usw., man war nur am suchen und grübeln, zumal man ja auch selbst nicth nicht alles wusste und in diesem chaos auch nicht lernen konnte.