Timm Thaler hat geschrieben:"Die Entwicklung dieser Richtlinie begann im August 1993..."
Beschreibt genau das Problem. 1993 wurden ganz andere Anforderungen an Computer gestellt als heute. Windows hat sich dem angepasst, zum Beispiel wurden Konfig-Dateien früher als *.ini in das Programmverzeichnis geschmissen, heute gibt es dafür \Users\User\AppData. 1993 gab es zwei Handvoll ausführbare Programme auf einem Rechner, heute sind es tausende.
Durch schnelleres Internet und Slim Clients ist genau das grade rückläufig. Die meisten Nutzer haben immer weniger Programme auf dem Rechner da es jetzt für alles WebApps gibt. Zu windows XP Zeiten war es noch so, da hat man sich kleine VBA Programme als .exe versendet, das war schlimm.
Und was für ein Windows verwendest du bitte das alle Dateien in AppData landen? Es gibt ProgramData, Nutzerverzeichnis, Dokumente, AppData und dann noch die Registry. Und ich habe noch keine Anwendung gefunden die nur eins davon verwendet (Registry oder Dokumente sind eigentlich immer mit dabei). Embarcadero RAD Studio z.B. Verwendet AppData, Dokumente, ProgramData und ich glaube sogar noch die Registry zusätzlich.
Das System von Unix ist da sehr einfach globale Konfigurationen kommen in /etc, user spezifische ins Home Verzeichnis (dafür ist es ja da). Konfigurationsdateien in Unix fangen für gewöhnlich mit . an, und werden standardmäßig von ls und den meisten Dateibrowsern ausgeblendet. Daher verstehe ich nicht was dich daran stört, ich meine die Dateien sind Unsichtbar. Im vergleich dazu schreibt VC++ Redist (oder DirectX, weiß es grade nicht mehr) immer eine EULA Datei in C:\, ich hatte Zeitweise 40 EULA Dateien im C Root stehen. Das ist nicht gut durchdacht.
Timm Thaler hat geschrieben:Wenn ich auf den Raspi in /usr/bin schaue, liegen da 1500 Binaries und Verknüpfungen, von Dienstprogrammen wie alsamixer bis zu umfangreichen Userprogrammen wie firefox. Welches andere Konzept soll dahinter stehen als: Kipp halt alles auf einen Haufen?
Du hast glaube ich nicht verstanden wozu das /usr/bin bzw. /bin oder /usr/local/bin Verzeichnis gedacht ist. Diese Verzeichnisse sind standardmäßig im Suchpfad, daher kannst du alle Programme die in diesem Verzeichnis sind von anderen Programmen aufrufen, z.B. aus Shell Skripten.
Du hast das Konzept von Unix wirklich nicht verstanden. Die Idee hinter Unix ist das Nutzer und Maschinen das Betriebsystem gleich ansteuern können. Das wird dadurch realisiert das so genannte Utility Programme verwendet werden. Das beste Beispiel sind dabei z.B. die CoreUtils, welche auf einem Unix System standardmäßig installiert sind. Dazu gehören Programme wie ls oder cat. Wenn du als Nutzer jetzt den Inhalt eines Verzeichnisses lesen willst kannst du einfach ls eintippen. Wenn du das ganze von einem Programm (z.B. Shell Script) machen möchtest musst du aus diesem auch nur ls aufrufen und den STDOut lesen. Dafür stellt das System auch die Funktionen Fork, Execev, Pipe und Dup2, was das aufrufen von anderen Anwendungen kinderleicht selbst in C macht.
Microsoft hat sich dabei für einen anderen Weg entschieden. Microsoft verwendet Programme für Nutzer und Bibliotheken für Programme. Das führt zu einer Sehr komplexen Windows API und manche Sachen die als User möglich sind sind nicht als Programm möglich (z.B. die Sound Konfigurationen lassen sich nicht von Programmen ändern, nur von Windows Nutzern).
Nicht Utility Programme sollten auch gar nicht nach /usr/bin installiert werden, sondern in ein eigenes Verzeichnis, und nur nach /usr/bin gesoftlinked werden
Außerdem, ich habe mir auf Windows Separat die Core Utils, Bin Utils, Dev Utils, etc. Installiert, und ich kann sagen, ich habe lieber einen Zentralen Ordner in dem alle Dateien drin sind, als wie bei Windows die PATH Variable ständig verändern zu müssen.
Timm Thaler hat geschrieben:Wenn ich in mein home schaue, gibt es zwar eine .config. Dennoch legen 20 Programme ihre eigene .config-Verzeichnisse an, anstelle das .config zu nutzen.
Normalerweise halten sich alle gängigen Linux Programme an eine sehr einfache Regel, Konfigurationsdateinamen fangen mit . and somit sind sie normalerweise versteckt. Wenn sie sich nicht daran halten ist es einfach software die sich nicht an Konventionen hält, dafür kann das System ja nichts
Timm Thaler hat geschrieben:Und das ist nur auf dem Raspi, wo ich die nötigsten Programme installiert habe. Ich will gar nicht wissen, wie das auf einem Arbeitsrechner aussieht.
Raspbian und nur die nötigsten Programme schließt sich aus. Raspbian ist so vollgepackt mit Schrott den niemand braucht (z.B. Python, Wolfram alpha, etc.). Nur um das mal festzuhalten auf meinem OpenSUSE server auf dem ne menge läuft habe ich grade mal 1900 Programme im /usr/bin Verzeichnis, also nicht mal ein volles drittel mehr.
Wenn du es schmal haben magst installier doch OpenSUSE JeOS