Thema: Sicherheitskonzept VFS/Aufbau Wurzelverzeichnis "/"

[FlashBurn]

Ich wollte mal eure Meinung zu einer Idee eines Sicherheitskonzeptes was das Dateisystem betrifft hören. Das ist allerdings noch nicht vollständig und vollkommen durchdacht bzw. hat noch Probleme.

Also es geht mir darum den Zugriff der Programme zu beschränken. Die erste Frage die aufkommt, darf ein Programm alle Dateien lesen? Oder ist es schlimm wenn es alle Dateien lesen kann?

Ich dachte mir es so, das ein Programm nur schreibzugriff auf einen Ordner /home/user/appdata/app/ hat. Somit hätte man Sachen wie eventuelle Konfigurationsdateien oder meinet wegen Savegames und sowas immer an einem genau bekannten Ort und das auch noch pro User.
Allerdings muss ich ja auch davon ausgehen, das es Programme gibt wo man diese Daten zentral und nicht pro User haben möchte oder sogar beides.
Dafür dachte ich an einen Ordner /home/shared/app/.
Will ein Programm in irgendeinen anderen Ordner schreiben, muss es die Rechte anfordern, was wie sudo oder UAC wäre (je nachdem ob GUI oder TUI).
Soweit so gut. Jetzt will man aber nicht für jeden Ordner diese Rechte anfordern müssen. Also dachte ich mir das ich noch einen Order habe /home/user/data/ was den "Eigene Dateien" Ordner unter Windows entsprechen würde und dort kann sich der User bzw. die Programme nach herzenslust austoben.
Ich will den User/die Programme nicht direkt in den /home/user/ Ordner schreiben lassen, weil ja dann der appdata Ordner nicht mehr geschützt wäre, bzw. für diesen Ordner (und eventuell andere Ordner) extra Regeln gelten müssten. So halte ich mir auch offen, noch andere Ordner wie appdata einzuführen.

Dadurch wäre erstmal sichergestellt das irgendwelche Programmdateien nicht ausversehen oder mit absicht (ohne Wissen des Users) geändert werden können.

Allerdings muss bei der Anforderung von Rechten auch unterschieden werden ob z.B. Dateien geschrieben (kopieren/ändern/löschen) werden oder ob ein Programm installiert wird. Denn bei letzterem wäre es eher unschön wenn man jede einzelne Datei als User genehmigen müsste.

Dazu dann auch gleich eine Frage. Wie macht man das am dümmsten mit den Libraries? Ich meine ich würde die schon irgendwie zentral haben wollen. Was ich so lösen würde, das man sich für jede Library registrieren müsste und das OS einen Zähler pro Library mitführt und wenn keine Anwendung die Library mehr benötigt (der Zähler also 0 ist) würde die Library gelöscht werden.
Allerdings kommt dann noch das Problem wie man das mit einer neueren Version der Library macht? Einfach überschreiben und davon ausgehen, wenn der User dem Installationsprogramm vertraut, dann wird das schon eine Library sein, die in Ordnung ist?
Speziell mit systemkritischen Libraries stelle ich mir das schwer vor. Wie will man da vor gehen?
Auch würde damit nur eine Möglichkeit geschaffen werden, Libraries zentral zu organisieren, aber die Apps könnten ihre Libraries ja trotzdem in ihrem Installationverzeichnis packen (womit man dann das Windowsproblem hätte). Das könnte man auch verhindern, indem man es explizit unterbindet und Libraries nur in dem zentralen Verzeichnis gesucht werden. Das wiederrum wäre auch nicht so toll, wenn ich da an Spiele denke, die bestimmte Sachen in Libraries auslagern. Was also machen?

Wie sicher auffällt, ist das ein Mix aus Unix- und Windowskonzepten. Ich mag das mit der zentralen Verwaltung der Anwendungsdaten unter Windows und finde den relativ starren (keine Ahnung ob das wirklich so ist, aber so würde ich es machen) Aufbau vom Wurzelverzeichnis ("/") unter Unix gut.
Mir ist klar dass das mit den Laufwerksbuchstaben nicht so das wahre ist und werde deshalb sowas wie unter Unix machen.

Vllt kennt ja jemand mal einen Link wo die Ordnerstruktur für Unix gut beschrieben wird, damit ich mir mal angucken kann wie die aussieht um mir ne Inspiration zu holen.

[Sannaj]

Naja, es gibt schon Situationen wo ein Leseverbot sinvoll ist. z.b. soll nur der root die Dateien lesen können, welche das Passwort enthalten. Wenn du ein echtes Netzwerk aufbaust, braucht auch nicht jeder alle Dateien lesen zu können.

[Svenska]

Hallo,

warum übernimmst du nicht einfach das Unix-Konzept, d.h. read-write-execute für user-group-others?

In /home/user sollte meiner Meinung nach der Nutzer "user" tun und lassen können, was er möchte (einschließlich /home/user/appdata). Wenn du Dateien für alle Nutzer gemeinsam an einer zentralen Stelle halten möchtest (statt /home/shared/* wäre vielleicht /etc/* geeignet, um das Unix-Konzept aufzugreifen), dann könntest du eine Benutzergruppe "von-UAC-authorisiert" definieren, die dorthin schreiben darf. Dein UAC würde die Aktion dann mit den Rechten dieser Gruppe stattfinden lassen, d.h. Schreibzugriff ist erlaubt.

Benötigte Libraries von jedem Programm registrieren zu lassen und automatisch zu löschen halte ich für eine äußerst schlechte Idee, denn ich kann ja auch Programme kompilieren und in meinem Homeverzeichnis umhertragen, die vielleicht doch auf Systembibliotheken basieren und nicht registriert sind (z.B. weil ich keine Rechte für die Registrierung habe). Überschreiben von Libraries ist im Übrigen auch großer Mist, da brauchst du dir nur die CTL3D.DLL von Windows 3.x anschauen - die gibt es in verschiedensten, inkompatiblen Fassungen und viele Installationsprogramme installieren die dann stupide nach \Windows\System. Das geht nur, wenn du Binärkompatiblität garantieren kannst; das kannst du nicht, wenn die Libs nicht von dir sind.

Du könntest natürlich den Weg des (zugegeben relativ schmutzigen Hacks) LD_LIBRARY_PATH gehen: Eine Anwendung sucht ihre Libs nur in den Pfaden, die in einer Umgebungsvariablen stehen (standardmäßig ausschließlich die systemweit installierten Libs). Ein Programm, welches Libs aus dem Programmverzeichnis benötigt, überschreibt dann die Umgebungsvariable (hängt z.B. vorne das Programmverzeichnis an). Du wirst nicht alle Anwendungen gleichermaßen glücklich bekommen.

Was du für Linux suchst, ist der FHS (Filesystem Hierarchy Standard, z.B. hier). Allerdings wird inzwischen überlegt, /usr abzuschaffen; unter üblichen Linuxdistributionen wird eh alles durch die Paketverwaltung administriert, eine Trennung zwischen /bin und /usr/bin ist dort nicht mehr besonders sinnvoll.

Gruß,
Svenska

[FlashBurn]

warum übernimmst du nicht einfach das Unix-Konzept, d.h. read-write-execute für user-group-others?

Vllt weil ich es nicht wirklich kenne, da ich mich damit noch nie beschäftigt habe

In /home/user sollte meiner Meinung nach der Nutzer "user" tun und lassen können, was er möchte (einschließlich /home/user/appdata).

Würde ich an sich auch sagen, nur leider heißt "user" in dem Fall Programme. Allerdings kann man das ja durch Umgebungsvariablen lösen. Der Gedanke dahinter war, das ein Programm z.B. seine variablen Daten unter "$APPDATA/foobar.conf" speichert. Da stellt sich dann die Frage wie und wer legt den Namen für $APPDATA fest?

Ich finde die Idee der Eigenen Dateien, Eigene Dokumente usw. gar nicht so verkehrt. Deswegen würde ich halt auch schon ein paar Ordner vordefinieren, aber eigentlich hast du schon recht, dass jeder "user" in seinem home Verzeichnis machen darf was er will. Das mit dem /home/user/appdata/app/ Verzeichnis kann ich da ja trotzdem unterbringen.

Überschreiben von Libraries ist im Übrigen auch großer Mist

Ich weiß, aber wie will man das Problem lösen? Ich meine ich gehe erstmal davon aus das ich kein Repository habe, wo alle Libraries gemanagt werden könnten. Das man System-Libraries (also alle Libraries die das System mitbringt) könnte man ja an einem anderen Ort speichern, als die Libraries der Programme.

Als Bsp. nenne ich jetzt einfach mal die SDL. Da gibt es ja ab und zu auch mal neuere Versionen und wie willst du das da handeln? Soll jede App ihre eigene SDL-Version mitbringen und nutzen? Das finde ich nämlich wiederum unschön (wird aber unter Windows auch verdammt oft gemacht, auch mit ganz anderen Libraries), das wiederspricht auch dem Konzept der shared libraries.
Ich würde da irgendwie die Versionsinformationen für nutzen wollen. Sprich ich würde zwar die SDL in den Versionen 1.2 und 1.3 zulassen, aber die 1.2.14 würde die Version 1.2.13 erstetzen und alle Programme würden dann diese Version nutzen. Allerdings hat auch dieses Vorgehen Probleme, nämlich das nicht alle Libraries einem einheitlichem Standard folgen was die Versionierung betrifft.
Ich könnte mir jetzt vorstellen das man das so lösen könnte das die Version irgendwie in der Datei gespeichert sein muss (PE hat da ja was für, aber gibt es da auch was bei ELF? ansonsten würde ich dafür ne extra Sektion reinpacken) und auch im Dateinamen, dort aber nur die wichtigsten, sprich um bei SDL zu bleiben, ich hätte 2 Dateien, libsdl.so.1.2 und libsdl.so.1.3, aber alles was dahinter kommt, z.B. Version 1.2.13 oder 1.2.14, kann dann genutzt werden um ein eventuelles Update zu machen.

Könnte das funktionieren? (In meinem Kopf tut es das, aber die Realität will nicht immer so wie mein Kopf )

Also die komplette Ordnerstruktur von Unix werde ich so nicht nutzen, aber die ein oder andere Sache schon. Man sieht halt deutlich (nur meine bescheidene Meinung) das Unix eher Kommandozeilenorientiert ist und Windows eher grafik orientiert ist. Denn sowas wie nen Programm-Verzeichnis möchte ich auch haben. Macht z.B. die Installation/Deinstallation von Programmen deutlich einfacher und gerade viele grafische Programme bestehen halt nicht nur aus der ausführbaren Datei und die will ich nicht alle in einem Verzeichnis haben. Natürlich könnte man über symlinks die Hauptdateien in ein Verzeichnis packen, aber dann könnte man wieder nicht 2 verschiedene Versionen eines Programms gleichzeitig haben (da müsste man dann wieder die Version irgendwie an den symlink mit ranhängen).
Ich würde da also zw. Kommandozeile und grafik unterscheiden wollen.

[erik.vikinger]

Hallo,


Du hast noch /tmp vergessen. Auch sowas ist sehr wichtig. Eventuell wäre es geschickt wenn man für jeden Prozess dort ein individuelles Unterverzeichnis einrichtet auf das nur der Prozess selber freien Zugriff hat, aber es muss auch möglich sein das die temporären Dateien direkt in /tmp liegen damit darauf mehrere Prozesse zugreifen können.

Was mir persönlich sehr wichtig wäre ist das auf die (globalen) Verzeichnisse mit den Programmen nur ganz bestimmte Programme Schreibzugriff haben, es sollte also einen Zwang geben das nur die Paketverwaltung Programme installieren/updaten/deinstallieren kann. Das Programme die Möglichkeit haben ihr eigenes Executable zu ändern ist IMHO eine ziemlich große Sicherheitslücke und individuelle Setup-Programme sind einfach ein Schrottkonzept aus dem letzten Jahrtausend.
Selbstkompilierte Programme kommen ins entsprechende User-Verzeichnis und sind dort erst mal für das restliche System ungefährlich.

Das Unix-Konzept mit user-group-others finde ich eigentlich recht gut aber read-write-execute finde ich persönlich ziemlichen Scheiß. Zum einen werden da die Flags je nach dem ob Datei oder Verzeichnis umgedeutet was einige Probleme mit sich bringen kann und zum anderen fehlen Dinge wie Append (bei einer Logdatei wäre es nicht schlecht wenn nur bestimmte User diese löschen oder überschreiben dürften aber jeder was Anhängen kann). Was mir im Unix-Konzept auch fehlt ist das Vererben von Rechten über Verzeichnisse hinweg, das ist etwas was in Windows schon recht brauchbar implementiert ist. Ich hoffe das hierfür btrfs endlich mal bessere Features bringen wird.


Grüße
Erik

[Svenska]

warum übernimmst du nicht einfach das Unix-Konzept, d.h. read-write-execute für user-group-others?

Vllt weil ich es nicht wirklich kenne, da ich mich damit noch nie beschäftigt habe

Mach mal, das Konzept ist ziemlich durchdacht und einfach. Wenn du es kennst, kannst du es immernoch ablehnen.

In /home/user sollte meiner Meinung nach der Nutzer "user" tun und lassen können, was er möchte (einschließlich /home/user/appdata).

Würde ich an sich auch sagen, nur leider heißt "user" in dem Fall Programme.

Systemweit installierte Programme haben in Homeverzeichnis nichts zu suchen, dafür gibt es unter Unix Ordner wie /usr/bin (Binaries), /usr/share (Hilfsdateien, z.B. Dokumentation), /etc (systemweite Einstellungen) und so. Selbstkompilate fallen aus der Betrachtung komplett aus.

Allerdings kann man das ja durch Umgebungsvariablen lösen. Der Gedanke dahinter war, das ein Programm z.B. seine variablen Daten unter "$APPDATA/foobar.conf" speichert. Da stellt sich dann die Frage wie und wer legt den Namen für $APPDATA fest?

Du denkst zu sehr Windows. Unter Unix nennt man das nicht $APPDATA, sondern $HOME und Anwendungen speichern alles dorthin. Wo genau hängt vom Programm und vom verwendeten Toolkit ab.

Ich finde die Idee der Eigenen Dateien, Eigene Dokumente usw. gar nicht so verkehrt. Deswegen würde ich halt auch schon ein paar Ordner vordefinieren, aber eigentlich hast du schon recht, dass jeder "user" in seinem home Verzeichnis machen darf was er will. Das mit dem /home/user/appdata/app/ Verzeichnis kann ich da ja trotzdem unterbringen.

Also /home/user/ ist unter Unix mit "Eigene Dateien" gleichzusetzen, ob du darunter noch ein paar andere Verzeichnisse wie "Downloads", "Music" usw definierst, bleibt dir überlassen. (Das sollte aber auch jeder Nutzer für sich entscheiden können, ob er das auch so will oder nicht.)

Überschreiben von Libraries ist im Übrigen auch großer Mist

Das man System-Libraries (also alle Libraries die das System mitbringt) könnte man ja an einem anderen Ort speichern, als die Libraries der Programme.

Naja, installiere doch alle gemeinsam genutzten Bibliotheken systemweit in einen Pfad und wenn ein Programm eine spezielle Version benutzt, kann es ja immernoch $LD_LIBRARY_PATH überschreiben und die eigene nehmen. Ansonsten sollte jedes Programm immer die vom System bereitgestellte Lib benutzen, da dort z.B. Sicherheitsfixes integriert wurden oder so.

Als Bsp. nenne ich jetzt einfach mal die SDL. Da gibt es ja ab und zu auch mal neuere Versionen und wie willst du das da handeln?

Auch da hat Unix wieder ein nettes Konzept, es nennt sich symbolische Links. Die Datei selbst heißt /usr/lib/libSDL-1.2.so.0.11.3 (bzw. /lib/libc-2.11.2.so), hat also im Dateinamen ihre Version; diese Lib kann ein Programm benutzen, wenn es exakt diese Version braucht. Außerdem gibt es noch verschiedene Symlinks darauf (/usr/lib/libSDL.so und /usr/lib/libSDL-1.2.so.0 bzw. /lib/libc.so.6).

Ich würde da irgendwie die Versionsinformationen für nutzen wollen. Sprich ich würde zwar die SDL in den Versionen 1.2 und 1.3 zulassen, aber die 1.2.14 würde die Version 1.2.13 erstetzen und alle Programme würden dann diese Version nutzen. Allerdings hat auch dieses Vorgehen Probleme, nämlich das nicht alle Libraries einem einheitlichem Standard folgen was die Versionierung betrifft.

Für die Programme wichtig ist die Binärkompatiblität. Um mit Updates klarzukommen, verweisen Programme also nicht auf die /usr/lib/libSDL-1.2.so.0.11.3 (/lib/libc-2.11.2.so), sondern auf die /usr/lib/libSDL-1.2.so.0 (/lib/libc.so.6). Die Ziffer hinter der Dateiendung gibt die Major-Version an, d.h. wenn sich die ändert, ist die neue Lib nicht mehr zur alten Lib kompatibel.

So kannst du systemweit mehrere verschiedene inkompatible Versionen einer Lib bereithalten (z.B. /lib/libc.so.5 für eine alte Variante und die aktuelle /lib/libc.so.6), du kannst transparent Updates einspielen (den Symlink umhängen auf die neue Version) und Anwendungen haben die Freiheit, eine bestimmte Version anzufordern.

Denn sowas wie nen Programm-Verzeichnis möchte ich auch haben. Macht z.B. die Installation/Deinstallation von Programmen deutlich einfacher und gerade viele grafische Programme bestehen halt nicht nur aus der ausführbaren Datei und die will ich nicht alle in einem Verzeichnis haben.

Dann schau dir mal das MacOS-Prinzip an: Anwendungen sind dort einfach Ordner mit einer vorgegebenen Struktur, wo das Binary und alle benötigten Hilfsdateien drin sind plus ein paar Metainformationen. Insbesondere erscheinen solche Ordner in der Oberfläche als ausführbare Dateien und sind in sich abgeschlossen (es gibt neben diesem Ordner keine weiteren Bestandteile im System). Die Installation ist also eine Kopie an den Zielort, die Deinstallation das Löschen; es wird nichts registriert; das Programm selbst speichert seine Anwendungsdaten aber trotzdem in $HOME. Finde ich ein sehr gutes Konzept.

Natürlich könnte man über symlinks die Hauptdateien in ein Verzeichnis packen, aber dann könnte man wieder nicht 2 verschiedene Versionen eines Programms gleichzeitig haben (da müsste man dann wieder die Version irgendwie an den symlink mit ranhängen).

Alle ausführbaren Dateien an einen Ort zu packen hat einen Vorteil, nämlich dass man mit $PATH arbeiten kann, du also bei Verknüpfungen und so keine vollen Pfadangaben machen brauchst. Die musst du nämlich anpassen, wann immer du das Programm dann verschiebst (oder die Festplatte woandershin mountest). Ob du das brauchst oder möchtest, musst du selbst entscheiden, beides hat Vor- und Nachteile.

Die Idee mit den Symlinks auf die jeweiligen Programme hat einen gewaltigen Vorteil: Du kannst eine neue Programmversion installieren und in aller Ruhe testen, bevor du die systemweite Verknüpfung änderst (bei kritischen Programmen wie "ls" oder "explorer.exe" kann das durchaus wichtig sein).

Ich würde da also zw. Kommandozeile und grafik unterscheiden wollen.

Das halte ich nicht unbedingt für sinnvoll. Anwendung ist Anwendung, entweder man geht den klassischen Unix-Weg und verteilt die Bestandteile der Anwendung im System (/usr/bin, /usr/lib, /usr/share, /etc, ...) oder den MacOS-Weg und betrachtet Anwendungen als Bundle, wo alles drin ist.

Den Windows-Weg, wo du Bibliotheken ins Windows-Systemverzeichnis installierst (ok, inzwischen nicht mehr - außer bei Microsoft-Programmen), die Anwendung in einen eigenen Ordner, die Anwendungsdaten quer über die Platte verteilt und alles in der Registry brav notiert, damit das System auch alles findet - den Weg halte ich für komplett falsch. Wenn du einen Sinn für Setup-Programme siehst, ist dein Konzept kaputt.

Meine 2ct.

Gruß,
Svenska

[FlashBurn]

Du denkst zu sehr Windows. smiley Unter Unix nennt man das nicht $APPDATA, sondern $HOME und Anwendungen speichern alles dorthin. Wo genau hängt vom Programm und vom verwendeten Toolkit ab.

Jap, ich finde diese Konzept des appdata Ordners gut. Ich möchte nicht dass das Programm entscheidet wo es seine Daten hinspeichert, sondern dass das Teil des Konzeptes ist. Damit dürfte auch das Umziehen auf eine neue Platte und sowas viel einfacher werden. Was ich halt bräuchte wäre, dass mir jemand eindeutige Nachteile nennen kann, für die mir keine Lösung einfällt oder für die es zu Umständlich damit wird.

ob du darunter noch ein paar andere Verzeichnisse wie "Downloads", "Music" usw definierst, bleibt dir überlassen. (Das sollte aber auch jeder Nutzer für sich entscheiden können, ob er das auch so will oder nicht.)

Naja, ich würde bestimmte Standard-Ordner schon definieren wollen. Damit will ich erreichen das Programme (z.B. nen Office-Programm) einen Einsprungpunkt in das Dateisystem haben, wo wahrscheinlich die meisten ihre Sachen speichern werden. Natürlich könnte man das auch einfach so machen, das man nen Symlink definiert (sowas macht Windows ja auch) und der Nutzer kann festlegen wo der Symlink hinführen soll.

Ansonsten sollte jedes Programm immer die vom System bereitgestellte Lib benutzen, da dort z.B. Sicherheitsfixes integriert wurden oder so.

Davon kannst du ausgehen wenn du ein Repository hast, aber nicht bei nem Hobby OS oder z.B. Windows. Also muss ich das irgendwie anders lösen.

Die Datei selbst heißt /usr/lib/libSDL-1.2.so.0.11.3 (bzw. /lib/libc-2.11.2.so), hat also im Dateinamen ihre Version; diese Lib kann ein Programm benutzen, wenn es exakt diese Version braucht. Außerdem gibt es noch verschiedene Symlinks darauf (/usr/lib/libSDL.so und /usr/lib/libSDL-1.2.so.0 bzw. /lib/libc.so.6).

Das ist ja auch erstmal alles gut und schön, aber das führt doch dazu das man irgendwann so ziemlich alle Versionen auf dem System hat die es von jeder Library gibt. Das ist halt unschön und das muss man irgendwie managen. Unter Linux macht das nen Paketmanager, sowas habe ich noch nicht geplant.
Auch würde ich einfach vorschreiben, das wenn sich das Interface (ABI) nicht geändert hat, immer die neuste Version genommen wird. Des Weiteren würde ich weder libSDL.so haben wollen, noch das ein Programm die genaue Version anfordern kann, also z.B. libSDL-1.2.so.0.11.3.
Damit kann ich erstens vermeiden, das es Probleme gibt mit dem Interface und zweitens das ich zuviele Versionen ein und derselben Library habe.

Auf das Problem des managen der Libraries komme ich später noch zurück.

Dann schau dir mal das MacOS-Prinzip an: Anwendungen sind dort einfach Ordner mit einer vorgegebenen Struktur, wo das Binary und alle benötigten Hilfsdateien drin sind plus ein paar Metainformationen. Insbesondere erscheinen solche Ordner in der Oberfläche als ausführbare Dateien und sind in sich abgeschlossen (es gibt neben diesem Ordner keine weiteren Bestandteile im System). Die Installation ist also eine Kopie an den Zielort, die Deinstallation das Löschen; es wird nichts registriert; das Programm selbst speichert seine Anwendungsdaten aber trotzdem in $HOME. Finde ich ein sehr gutes Konzept.

Wieder was gelernt und genau sowas schwebt mir auch vor.

Jetzt komm ich dann auch zum Managen der Libraries. Ich würde den Programmordner von einer Art Library-Manager beobachten lassen und jedes Mal wenn ein Programm installiert wird, wird in eine Art Datenbank (oder sowas) die mitgebrachten/benötigten Libraries eingetragen und wenn ein Programm gelöscht/Deinstalliert wird, wird in der Datenbank nachgeguckt, ob es noch andere Programme gibt, die irgendeine Library die das zu deinstallierende Programm braucht, auch brauchen. Ansonsten können diese gelöscht werden.

Das würde auch soweit funktionieren, nur nicht mit Programmen die ich nicht installiert/in das entsprechende Verzeichnis kopiert habe.
Dafür würde ich sagen entweder müssen die Libraries dann im selben Ordner sein wie das Programm oder aber im Unterordner /lib des Programms.
Ich würde dann wahrscheinlich sogar soweit gehen, das man den Pfad wo nach den Libraries gesucht wird, nicht ändern kann, sondern der ist fest vorgegeben.
Was ein Programm aber nicht daran hindert, eine Library einfach zur Laufzeit nachzuladen. Das sollte wiederrum von überall möglich sein (wo das Programm drauf zugriff hat).

Alle ausführbaren Dateien an einen Ort zu packen hat einen Vorteil, nämlich dass man mit $PATH arbeiten kann, du also bei Verknüpfungen und so keine vollen Pfadangaben machen brauchst. Die musst du nämlich anpassen, wann immer du das Programm dann verschiebst (oder die Festplatte woandershin mountest). Ob du das brauchst oder möchtest, musst du selbst entscheiden, beides hat Vor- und Nachteile.

Deswegen will ich ja so einen "Programme" Ordner, damit alle Programme an einem Ort sind, aber nicht so dass auch alle Dateien in einem Ordnern sind. Das kann man mit Kommandozeilentools machen aber nicht mit Grafikprogrammen.

Ich glaube da würde ich dann wieder den Unix-Weg aufgreifen und zw. vom System mitgebrachte Tools und vom User nachinstallierte Tools unterscheiden.
Da könnte man sogar soweit gehen, das es im /home/user Verzeichnis einen Unterordner /bin gibt, wo die Tools des jeweiligen Users drin sind. Bzw. den Ordner /home/shared/bin für Tools die nicht vom System stammen, aber auf die alle User zugreifen können sollen.

Und ja ich möchte diesen shared Ordner haben, das soll alles unter dem /home Verzeichnis sein, weil es für mich einfach nur ein User ist, nur halt einer auf den alle Zugriff haben.

Wenn du einen Sinn für Setup-Programme siehst, ist dein Konzept kaputt.

Dann müsste der Unix-Weg ja auch kaputt sein und der MacOS-Weg ist dann viel zu uneffektiv. Denn ich denke da an die Libraries, unter Unix hast du das Problem der Dependencies (und dafür hast du nen Paketmanager, für mich nichts anderes als nen Setup-Programm) und unter MacOS (wenn ich es richtig verstanden habe) bringt jedes Programm seine eigene Libraries mit und man hätte so keine Vorteile wenn man eine Library mal updatet, sondern das müsste man für alle Libraries in jedem Programm Ordner machen und dann kann man nicht mal davon ausgehen, das die alle gleich benannt sind. Das würde ich kaputt nennen!

Du hast noch /tmp vergessen. Auch sowas ist sehr wichtig. Eventuell wäre es geschickt wenn man für jeden Prozess dort ein individuelles Unterverzeichnis einrichtet auf das nur der Prozess selber freien Zugriff hat, aber es muss auch möglich sein das die temporären Dateien direkt in /tmp liegen damit darauf mehrere Prozesse zugreifen können.

Das würde ich wieder genauso wie mit dem /home Verzeichnis machen wollen, sprich /tmp/app und /tmp/shared. Damit hätte ich dann das gleiche Konzept nochmal verwendet und es wäre schön getrennt.

Was mir persönlich sehr wichtig wäre ist das auf die (globalen) Verzeichnisse mit den Programmen nur ganz bestimmte Programme Schreibzugriff haben, es sollte also einen Zwang geben das nur die Paketverwaltung Programme installieren/updaten/deinstallieren kann. Das Programme die Möglichkeit haben ihr eigenes Executable zu ändern ist IMHO eine ziemlich große Sicherheitslücke und individuelle Setup-Programme sind einfach ein Schrottkonzept aus dem letzten Jahrtausend.

Sprich man würde nen Art Paketmanager haben, der halt auch nen Überblick über die Libraries hat (ich weiß, ich nerve mit den Libraries, aber die sind nunmal nicht so einfach zu handeln). Man würde also das Konzept von MacOS (jedes Programm in einem Ordner mit bestimmten Vorgaben) mit den oben genannten Dingen verbinden. Da könnte ich dann sogar einfach .tar.foo (wobei foo irgendein Komprimierverfahren wäre) als Paketformat nehmen und da ist ne vorgegebene Ordnerstruktur drin. Damit muss man nichts neues erfinden.

[Svenska]

Hallo,

Du denkst zu sehr Windows. Unter Unix nennt man das nicht $APPDATA, sondern $HOME und Anwendungen speichern alles dorthin. Wo genau hängt vom Programm und vom verwendeten Toolkit ab.

Jap, ich finde diese Konzept des appdata Ordners gut. Ich möchte nicht dass das Programm entscheidet wo es seine Daten hinspeichert, sondern dass das Teil des Konzeptes ist.

Naja, Programme dürfen an sich erstmal nur nach $HOME speichern, das heißt, dass dein Appdata dort auch liegt. Wenn du ein vernünftiges Konzept anbietest, werden Programme das auch nutzen - du kannst sie aber nicht dazu zwingen, ihre Daten dort abzulegen. Du könntest einfach $HOME/AppData/anwendungsname/ als "best practice" festlegen, oder - was unter Unix praktiziert wird - $HOME/.anwendungsname. Inzwischen gibt es da viel zu viel Wildwuchs (~/.local, ~/.config, ~/.dbus, ~/.gconf, ~/.gconfd, ...), von daher ist eine feste Schnittstelle zu begrüßen.

Damit dürfte auch das Umziehen auf eine neue Platte und sowas viel einfacher werden. Was ich halt bräuchte wäre, dass mir jemand eindeutige Nachteile nennen kann, für die mir keine Lösung einfällt oder für die es zu Umständlich damit wird.

Bitte keine Registrierung. Jedes Programm soll nach Möglichkeit in dem Format abspeichern dürfen, was ihm am besten gefällt und nicht auf "key=value" oder XML-Datensätze beschränkt sein. Ansonsten ziehst du ein Linux-System um, indem du $HOME auf die neue Festplatte kopierst.

Naja, ich würde bestimmte Standard-Ordner schon definieren wollen. Damit will ich erreichen das Programme (z.B. nen Office-Programm) einen Einsprungpunkt in das Dateisystem haben, wo wahrscheinlich die meisten ihre Sachen speichern werden.

Ja, ist sinnvoll. Aber wenn ich die Ordner lösche, dann möchte ich auch, dass die weg sind und nicht bei jedem Login neu erzeugt werden.

Ansonsten sollte jedes Programm immer die vom System bereitgestellte Lib benutzen, da dort z.B. Sicherheitsfixes integriert wurden oder so.

Davon kannst du ausgehen wenn du ein Repository hast, aber nicht bei nem Hobby OS oder z.B. Windows. Also muss ich das irgendwie anders lösen.

Wieso? Wenn du ein Programm auf dein OS portierst, dann musst du ohnehin die benutzten Libs portieren. Die kannst du dann aber auch gleich systemweit installieren und von anderen Programmen mitbenutzen lassen. Jedem Programm seine eigene libSDL zu geben ist jedenfalls Mist.

Die Datei selbst heißt /usr/lib/libSDL-1.2.so.0.11.3 (bzw. /lib/libc-2.11.2.so), hat also im Dateinamen ihre Version; diese Lib kann ein Programm benutzen, wenn es exakt diese Version braucht. Außerdem gibt es noch verschiedene Symlinks darauf (/usr/lib/libSDL.so und /usr/lib/libSDL-1.2.so.0 bzw. /lib/libc.so.6).

Das ist ja auch erstmal alles gut und schön, aber das führt doch dazu das man irgendwann so ziemlich alle Versionen auf dem System hat die es von jeder Library gibt.

Nö. Es gibt ja für die meisten Programme keine Notwendigkeit, zwingend eine bestimmte Bibliotheksversion zu benutzen - die Nachfolgeversionen sind fast immer kompatibel.

Das ist halt unschön und das muss man irgendwie managen. Unter Linux macht das nen Paketmanager, sowas habe ich noch nicht geplant.

Also möchtest du doch das Windows-Konzept der Setup-Programme (pro Anwendung) weiterführen. Das finde ich kaputt; stabil lässt sich das nämlich nur machen, wenn alle Programme ihre Bibliotheken ins Anwendungsverzeichnis (Bundle) stopfen und damit von Updates ausgeschlossen sind - siehe MacOS. Alles andere wird über kurz oder lang dein Systemverzeichnis zerschießen, weil Setupprogramme historisch gesehen immer der letzte Dreck sind.

Der Windows-Installer hat eher was mit Paketverwaltung von Linux zu tun als mit dem InstallShield, der bei Anwendungen früher dabei war. So schlecht kann das Konzept also nicht sein.

Auch würde ich einfach vorschreiben, das wenn sich das Interface (ABI) nicht geändert hat, immer die neuste Version genommen wird. Des Weiteren würde ich weder libSDL.so haben wollen, noch das ein Programm die genaue Version anfordern kann, also z.B. libSDL-1.2.so.0.11.3.

Darum verweist die /lib/libc.so.6 immer auf die aktuelle Version der C-Bibliothek mit der ABI-Version 6. Wenn der Loader erstmal ein "ls" auf den Lib-Ordner machen muss, um die aktuelle Version rauszufinden, dann ist das umständlich und kaputt.

Damit kann ich erstens vermeiden, das es Probleme gibt mit dem Interface und zweitens das ich zuviele Versionen ein und derselben Library habe.

Wenn die neue Version der Lib funktioniert und du den Symlink /lib/libc.so.6 -> /lib/libc-2.11.2.so korrekt gesetzt hast, kannst du die alte Version einfach löschen. Fertig.

Jetzt komm ich dann auch zum Managen der Libraries. Ich würde den Programmordner von einer Art Library-Manager beobachten lassen und jedes Mal wenn ein Programm installiert wird, wird in eine Art Datenbank (oder sowas) die mitgebrachten/benötigten Libraries eingetragen und wenn ein Programm gelöscht/Deinstalliert wird, wird in der Datenbank nachgeguckt, ob es noch andere Programme gibt, die irgendeine Library die das zu deinstallierende Programm braucht, auch brauchen. Ansonsten können diese gelöscht werden.

Das ist kaputt. Stell dir mal vor, ein Programm baut jetzt ganz viele Dateien, die alle aussehen wie Libraries, aber keine sind (sondern z.B. Texturen). Dann fängt dein Library-Manager an, in die Datenbank tausende von Texturen einzutragen, die da garnicht hingehören. Außerdem zerfällt dein Gesamtsystem zu staub, wenn die Datenbank mal kaputt geht.

Das ist das Konzept der Windows-Registrierdatenbank. Ich mag es nicht. Wenn du es willst - deine Sache.

Ich würde dann wahrscheinlich sogar soweit gehen, das man den Pfad wo nach den Libraries gesucht wird, nicht ändern kann, sondern der ist fest vorgegeben.

Würde ich nicht tun. Verschenkt unglaubliche Flexibilität.

Alle ausführbaren Dateien an einen Ort zu packen hat einen Vorteil, nämlich dass man mit $PATH arbeiten kann, du also bei Verknüpfungen und so keine vollen Pfadangaben machen brauchst.[...]

Deswegen will ich ja so einen "Programme" Ordner, damit alle Programme an einem Ort sind, aber nicht so dass auch alle Dateien in einem Ordnern sind. Das kann man mit Kommandozeilentools machen aber nicht mit Grafikprogrammen.

Du kannst $PATH aber schlecht sagen "und alle Unterordner auch bitte". Das wird beim Suchen zu langsam. Entweder du tust alle Binaries in einen gemeinsamen Ordner oder du tust jedes Binary in den Anwendungsordner. Im letzten Fall musst du an jeder Stelle den vollen Pfad angeben (oder jedes einzelne Programm zu $PATH explizit hinzufügen, was wieder andere Probleme nach sich zieht).

Und ja ich möchte diesen shared Ordner haben, das soll alles unter dem /home Verzeichnis sein, weil es für mich einfach nur ein User ist, nur halt einer auf den alle Zugriff haben.

Du trennst also zwischen "können alle nutzen, gehört zum System", "können alle nutzen, gehört nicht zum System" und "kann nur einer nutzen, gehört ihm". Naja, musst du wissen. Ich finde das nicht besonders gut.

Insbesondere gehören ausschließlich Nutzerdaten nach /home, sonst nichts. "shared" ist kein Nutzer, sondern eine Nutzergruppe.

Wenn du einen Sinn für Setup-Programme siehst, ist dein Konzept kaputt.

Dann müsste der Unix-Weg ja auch kaputt sein und der MacOS-Weg ist dann viel zu uneffektiv. Denn ich denke da an die Libraries, unter Unix hast du das Problem der Dependencies (und dafür hast du nen Paketmanager, für mich nichts anderes als nen Setup-Programm) und unter MacOS (wenn ich es richtig verstanden habe) bringt jedes Programm seine eigene Libraries mit und man hätte so keine Vorteile wenn man eine Library mal updatet, sondern das müsste man für alle Libraries in jedem Programm Ordner machen und dann kann man nicht mal davon ausgehen, das die alle gleich benannt sind. Das würde ich kaputt nennen!

Paketverwaltung != Setup-Programm. Erstere ist nämlich auch für das Auflösen von Abhängigkeiten, Updates und so zuständig und außerdem in der Lage, die Integrität des Systems sicherzustellen. Ein Setup-Programm kopiert nur die benötigten Daten an einen Ort und kümmert sich nicht weiter um das System. Anders ausgedrückt: Die Paketverwaltung ist Teil des Betriebssystems, das Setup-Programm ist Teil der Anwendung.

Der MacOS-Weg ist wirklich so, dass jedes Programm alle Libs mitbringt, die das Basisbetriebssystem nicht hat. Nur so kannst du vollständig unabhängige Programmbundles haben, die immer und überall funktionieren (endnutzerfreundlich).

Sprich man würde nen Art Paketmanager haben, der halt auch nen Überblick über die Libraries hat (ich weiß, ich nerve mit den Libraries, aber die sind nunmal nicht so einfach zu handeln). Man würde also das Konzept von MacOS (jedes Programm in einem Ordner mit bestimmten Vorgaben) mit den oben genannten Dingen verbinden.

Das kann man nicht verbinden: Entweder, du hast alles, was zu einem Programm gehört in einem Ordner (dem Bundle), oder du installierst die Bestandteile des Programms (Libs, Binaries, Doku, ...) in verschiedene Ordner im System. Eine Mischung davon gibt es nicht. Das ist dann auch kein Bundle mehr, sondern ein Paket, welches installiert werden muss.

Eine zentrale Datenbank, die in die innere Struktur der Anwendungen reinpfuscht ist jedenfalls nicht besonders hilfreich. Was machst du denn bei Library-Updates? Einfach in jedem Programm die Lib ersetzen?

Da könnte ich dann sogar einfach .tar.foo (wobei foo irgendein Komprimierverfahren wäre) als Paketformat nehmen und da ist ne vorgegebene Ordnerstruktur drin. Damit muss man nichts neues erfinden.

Du könntest in dem Moment auch gleich DEB oder RPM benutzen... und hättest schlagartig ein Paketmanagementsystem als Lösung für dein Problem gefunden.

Gruß,
Svenska

[FlashBurn]

Wenn du ein vernünftiges Konzept anbietest, werden Programme das auch nutzen - du kannst sie aber nicht dazu zwingen, ihre Daten dort abzulegen.

Wieso kann ich sie nicht zwingen

Ich will einfach vermeiden, das es Programme gibt, die ein an sich vernünftiges Konzept zerstören, weil der Programmierer der Meinung war, ach brauch ich nicht.
Das gleiche gilt für die Libraries, wenn du die Programme zu bestimmten Dingen zwingst kannst du bestimmte Sachen vermeiden.

Bitte keine Registrierung. Jedes Programm soll nach Möglichkeit in dem Format abspeichern dürfen, was ihm am besten gefällt und nicht auf "key=value" oder XML-Datensätze beschränkt sein. Ansonsten ziehst du ein Linux-System um, indem du $HOME auf die neue Festplatte kopierst.

Ich hatte mir das genauso vorgestellt, das man einfach nur das home-Verzeichnis kopieren müsste. Allerdings fällt mir dabei auf, dass dann am besten auch alle Libs (die nicht vom System kommen) dort mit drin sein sollten.

Ja, ist sinnvoll. Aber wenn ich die Ordner lösche, dann möchte ich auch, dass die weg sind und nicht bei jedem Login neu erzeugt werden.

Hmm, das kann ich so nicht einfach stehen lassen. Denn dann kommt es zu Problemen, wenn du bestimmte Standarddialoge hast und die Ordner sind mit einmal nicht mehr da. Also wäre es halt am besten wenn man diese Ordner erstmal erstellt, aber dem Nutzer die Möglichkeit gibt, sie auf andere Ordner verweisen zu lassen. Nur dann kann der Ordner auch gelöscht werden.

Wieso? Wenn du ein Programm auf dein OS portierst, dann musst du ohnehin die benutzten Libs portieren. Die kannst du dann aber auch gleich systemweit installieren und von anderen Programmen mitbenutzen lassen. Jedem Programm seine eigene libSDL zu geben ist jedenfalls Mist.

Gut, jetzt portiere aber nicht nur ich Programme, sondern andere schreiben auch Programme und das habe ich dann nicht mehr unter Kontrolle. Ich will ja auch nicht das jeder seine eigene libSDL nutzt, sondern wenn schon eine vorhanden ist wird die genutzt, bzw. wenn die die das Programm bzw. Paket mitbringt neuer ist, wird diese "installiert".

Nö. Es gibt ja für die meisten Programme keine Notwendigkeit, zwingend eine bestimmte Bibliotheksversion zu benutzen - die Nachfolgeversionen sind fast immer kompatibel.

Ich meinte das ich nicht zulassen möchte das ein Programm ganz genau eine Version anfordern kann (z.B. libSDL 1.2.13 soll nicht gehen, nur libSDL 1.2). Hoffe du verstehst jetzt was ich meinte.

Also möchtest du doch das Windows-Konzept der Setup-Programme (pro Anwendung) weiterführen. Das finde ich kaputt; stabil lässt sich das nämlich nur machen, wenn alle Programme ihre Bibliotheken ins Anwendungsverzeichnis (Bundle) stopfen und damit von Updates ausgeschlossen sind - siehe MacOS. Alles andere wird über kurz oder lang dein Systemverzeichnis zerschießen, weil Setupprogramme historisch gesehen immer der letzte Dreck sind.

Von Setup-Programm war doch nie die Rede. Ich würde sowas wie nen Paketmanager haben wollen. Deswegen ja auch die .tar.foo Dateien=Pakete. Aber in dem Paket sollen ruhig alle benötigten Libraries mit drin sein, aber "installiert" werden diese nur sofern nicht vorhanden bzw. die vorhandenen werden geupdatet.

Darum verweist die /lib/libc.so.6 immer auf die aktuelle Version der C-Bibliothek mit der ABI-Version 6. Wenn der Loader erstmal ein "ls" auf den Lib-Ordner machen muss, um die aktuelle Version rauszufinden, dann ist das umständlich und kaputt.

Aber warum muss /lib/libc.so.6 auf die neueste Version verweisen, wieso kann sie es nicht einfach sein? Ich sehe das nur als doppelt gemoppelt. Wenn ich eh immer nur einer /lib/libc.so.6 haben kann, brauche ich doch keinen Verweis. Das ist was ich ausdrücken wollte.

Stell dir mal vor, ein Programm baut jetzt ganz viele Dateien, die alle aussehen wie Libraries, aber keine sind (sondern z.B. Texturen). Dann fängt dein Library-Manager an, in die Datenbank tausende von Texturen einzutragen, die da garnicht hingehören. Außerdem zerfällt dein Gesamtsystem zu staub, wenn die Datenbank mal kaputt geht.

Deswegen ja die Pakete mit vorgegebener Ordnerstruktur und natürlich kann man ne Library von einer Textur unterscheiden. Ich würde da schon prüfen ob das wirklich ne ELF-Library ist, ansonsten wird das einfach ignoriert bzw. würde ich da auch so weit gehen, das Paket als fehlerhaft (weil außer Libraries keine anderen Dateien in diesem speziellen Ordner zu sein haben) zu melden und gar nicht erst "installieren" lassen.

Würde ich nicht tun. Verschenkt unglaubliche Flexibilität.

Wieso? Das sehe ich irgendwie nicht.

Du kannst $PATH aber schlecht sagen "und alle Unterordner auch bitte". Das wird beim Suchen zu langsam. Entweder du tust alle Binaries in einen gemeinsamen Ordner oder du tust jedes Binary in den Anwendungsordner. Im letzten Fall musst du an jeder Stelle den vollen Pfad angeben (oder jedes einzelne Programm zu $PATH explizit hinzufügen, was wieder andere Probleme nach sich zieht).

Genau deswegen will ich Kommandozeilen Programme von grafischen trennen! Ich lege ganz einfach fest, ein grafisches Programm wird nicht über die Kommandozeile gestartet, sondern grafisch über nen Link und wer es doch über die Kommandozeile machen will, muss halt den entsprechenden Ordner suchen, fertig!

Du trennst also zwischen "können alle nutzen, gehört zum System", "können alle nutzen, gehört nicht zum System" und "kann nur einer nutzen, gehört ihm". Naja, musst du wissen. Ich finde das nicht besonders gut.

Wieso nicht? Obwohl mir spontan eine Sache einfällt die man so nicht regeln kann, nämlich das unterschiedliche Nutzer Zugriff auf unterschiedliche Programme haben. Bei meiner momentanen Idee würde es passieren das man Programme doppelt installieren muss, weil 2 Benutzer zugriff haben sollen, aber ein anderer nicht.
Und mir fällt auf, das ich das nur für die Kommandozeilentools erdacht habe und nicht auch zusätzlich für die grafischen. Das müsste man also doch über ne vernünftige Rechteverwaltung machen. Das wiederrum erfordert das ich nen anderes Dateisystem als FAT einsetzen muss.

Das kann man nicht verbinden: Entweder, du hast alles, was zu einem Programm gehört in einem Ordner (dem Bundle), oder du installierst die Bestandteile des Programms (Libs, Binaries, Doku, ...) in verschiedene Ordner im System. Eine Mischung davon gibt es nicht. Das ist dann auch kein Bundle mehr, sondern ein Paket, welches installiert werden muss.

Wie gesagt ich würde Paket und Setup mischen. Du hast ein Paket, welches auf den ersten Blich aussieht wie so ein Bundle für MacOS, aber der Paketmanager, würde das Paket so installieren, das die Libs in das System integriert werden. Also sind in dem Programmordner der später auf der HDD landet keine Libs mehr drin, sondern die sind im entsprechenden Ordner.

Wie gesagt ich kann und will mir nicht den Luxus eines Repositories leisten (und das aus mehreren Gründen nicht).

Du könntest in dem Moment auch gleich DEB oder RPM benutzen... und hättest schlagartig ein Paketmanagementsystem als Lösung für dein Problem gefunden

Da stellt sich mir dann wieder die Frage, wenn die so toll sind, wieso gibt es dann so viele unterschiedliche und warum durften dir ihr eigenes Bier brauen und ich nicht
Zumal, ich schreibe mein eigenes OS, da fällt dann ein eigenes Paketmanagementsystem auch nicht mehr auf

[Svenska]

Ich will einfach vermeiden, das es Programme gibt, die ein an sich vernünftiges Konzept zerstören, weil der Programmierer der Meinung war, ach brauch ich nicht.

Gut, dann mach es wie Apple und erzeuge eine Whitelist erlaubter Applikationen für dein Betriebssystem.

Ich hatte mir das genauso vorgestellt, das man einfach nur das home-Verzeichnis kopieren müsste. Allerdings fällt mir dabei auf, dass dann am besten auch alle Libs (die nicht vom System kommen) dort mit drin sein sollten.

*facepalm*

Ja, ist sinnvoll. Aber wenn ich die Ordner lösche, dann möchte ich auch, dass die weg sind und nicht bei jedem Login neu erzeugt werden.

Hmm, das kann ich so nicht einfach stehen lassen. Denn dann kommt es zu Problemen, wenn du bestimmte Standarddialoge hast und die Ordner sind mit einmal nicht mehr da.

Wo ist das Problem? Ich sehe da keins. Es sei denn natürlich, dass der Standarddialog abstürzt, aber das ist Pfusch am Bau.

Ich will meine eigene Organisation und mir von niemandem reinreden lassen.

Gut, jetzt portiere aber nicht nur ich Programme, sondern andere schreiben auch Programme und das habe ich dann nicht mehr unter Kontrolle. Ich will ja auch nicht das jeder seine eigene libSDL nutzt, sondern wenn schon eine vorhanden ist wird die genutzt, bzw. wenn die die das Programm bzw. Paket mitbringt neuer ist, wird diese "installiert".

Wenn jedes Programm seine eigenen Libs mitbringen "muss" (du willst ja die nicht systemweit installieren), dann sind diese Programme auch nur gegen diese bestimmten Libs getestet. Diese nachträglich einfach so zu ersetzen ist definitiv nicht im Sinne des Erfinders.

Außerdem installierst du dann ein Programm, welches eine abgespeckte dummy-libSDL benutzt (z.B. nur für Sound) und - weils den Entwickler nicht interessiert hat - mit Version 9.99 der libSDL geliefert wird... dein Library-Manager integriert die dann ins System (weil sie ja neuer ist) und schwupps, sind alle auf SDL basierenden Programme kaputt. Wunderbar. Und jetzt finde im System mal die spezielle libSDL, die kaputt ist.

Nö. Es gibt ja für die meisten Programme keine Notwendigkeit, zwingend eine bestimmte Bibliotheksversion zu benutzen - die Nachfolgeversionen sind fast immer kompatibel.

Ich meinte das ich nicht zulassen möchte das ein Programm ganz genau eine Version anfordern kann (z.B. libSDL 1.2.13 soll nicht gehen, nur libSDL 1.2). Hoffe du verstehst jetzt was ich meinte.

Es mag Gründe für exakte Versionsstände geben. Als Beispiel führe ich mal Zertifizierungen oder digitale Signaturen an. Das im Voraus zu verbieten ist falsch.

Aber in dem Paket sollen ruhig alle benötigten Libraries mit drin sein, aber "installiert" werden diese nur sofern nicht vorhanden bzw. die vorhandenen werden geupdatet.

Also willst du auf jegliche Form von Abhängigkeitsmanagement verzichten und dafür jedem Paket erlauben, potentiell dein System zu zerschießen. Tolle Wurst.

Darum verweist die /lib/libc.so.6 immer auf die aktuelle Version der C-Bibliothek mit der ABI-Version 6. Wenn der Loader erstmal ein "ls" auf den Lib-Ordner machen muss, um die aktuelle Version rauszufinden, dann ist das umständlich und kaputt.

Aber warum muss /lib/libc.so.6 auf die neueste Version verweisen, wieso kann sie es nicht einfach sein? Ich sehe das nur als doppelt gemoppelt. Wenn ich eh immer nur einer /lib/libc.so.6 haben kann, brauche ich doch keinen Verweis. Das ist was ich ausdrücken wollte.

Sicher kannst du deine C-Bibliothek auch "libc.so.6" nennen, allerdings kannst du dann nicht mehr mehrere Versionen parallel installiert haben und wärst zu rolling updates gezwungen (keine Versionsstände mehr). Schließlich könnte <zertifiziertes Programm hier> ja explizit die libc-2.11.6.so anfordern dürfen.

Genau deswegen will ich Kommandozeilen Programme von grafischen trennen! Ich lege ganz einfach fest, ein grafisches Programm wird nicht über die Kommandozeile gestartet, sondern grafisch über nen Link und wer es doch über die Kommandozeile machen will, muss halt den entsprechenden Ordner suchen, fertig!

Also ich finde den Gedanken, dass grafische Programme auch stdin/stdout benutzen dürfen, schon garnicht so schlecht... alle grafischen Unixprogramme sind auch Kommandozeilenprogramme - und sei es für Debugausgaben. Da ne willkürliche Grenze zu ziehen ist doof; außerdem kann ein Programm ja auch beides sein. Beispielsweise REGEDIT von Win95 (läuft unter DOS, aber auch grafisch), oder dein Netzwerkverwaltungstool (ist die grafische Oberfläche aktiv -> grafisch, fehlt die grafische Oberfläche -> textbasiert, wurden Parameter übergeben -> nichtinteraktiv). Der Übergang ist fließend und ihn im Betriebssystem einzumauern falsch.

Wie gesagt ich kann und will mir nicht den Luxus eines Repositories leisten (und das aus mehreren Gründen nicht).

Einverstanden. Das macht dann jemand anders. Solange du selbst dran rumwerkelst und der fast einzige Nutzer bist, sind alle diese Konzepte eh hinfällig.

Komische Vorstellungen hast du.

Gruß,
Svenska

[erik.vikinger]

Hallo,


FlashBurn, Du solltest Dich eventuell von dem Gedanken trennen das eine Library ein Teil des Programms ist sondern das als eigenständiges Paket betrachten von dem das Programm abhängig ist. Zu der Abhängigkeit darf dann natürlich noch die gewünschte Version der Library gehören. Wenn man das mit einer guten Paketverwaltung verknüpft kommt ein brauchbares System bei raus und Du wirst immer zuverlässig vor der Library/DLL-Hölle bewahrt.

Ein anderes Problem sind fest eingelickte Libraries, im Endeffekt kannst Du nicht zuverlässig verhindern das die Programme eigene Libraries mitbringen.

Das Du überhaupt Executables in /home haben willst betrachte ich persönlich als Fehler.
Wenn ein Programm nur von einer bestimmte Teil-Menge an Usern benutzt werden soll dann bekommt es als Owner root und als Gruppe eine in der auch alle User drin sind die das Programm benutzen dürfen. Du solltest Dich wirklich mal mit user-group-others beschäftigen.

Da stellt sich mir dann wieder die Frage, wenn die so toll sind, wieso gibt es dann so viele unterschiedliche

Das ist in der Tat eine berechtigte Frage. Die Antwort würde mich auch sehr interessieren.

und warum durften dir ihr eigenes Bier brauen und ich nicht

Vielleicht haben die eine passende Lizenz oder passende Erfahrung.

Zumal, ich schreibe mein eigenes OS, da fällt dann ein eigenes Paketmanagementsystem auch nicht mehr auf

Also der Unterschied zwischen einem OS und einer Paketverwaltung ist doch ziemlich erheblich.


Grüße
Erik

[FlashBurn]

Wo ist das Problem? Ich sehe da keins. Es sei denn natürlich, dass der Standarddialog abstürzt, aber das ist Pfusch am Bau.

Der soll nicht abstürzen, aber wenn ich einen Standarddialog designe und verwende, dann möchte ich da auch immer z.B. "Eigene Dokumente" auswählen können, wo auch immer dieses Verzeichnis liegt. Hauptsache es ist eins vorhanden das dafür bekannt ist, dass dort die Dokumente gespeichert werden sollen.

Ich will meine eigene Organisation und mir von niemandem reinreden lassen.

Dann ist aber Unix nicht das richtige für dich Denn da gibt es (wie auf jedem OS, gehe ich einfach mal von aus) immer bestimmte Sachen die an einen bestimmten Ort müssen.

Wenn jedes Programm seine eigenen Libs mitbringen "muss" (du willst ja die nicht systemweit installieren), dann sind diese Programme auch nur gegen diese bestimmten Libs getestet. Diese nachträglich einfach so zu ersetzen ist definitiv nicht im Sinne des Erfinders.

Also ersten sollte es kein Problem sein, wenn sich das Interface einer Lib nicht ändert, das eine neuere Version verwendet wird (Bugfixing und sowas) und du hast noch immer nicht verstanden was ich vorhabe.

Also ein Programm besteht erstmal aus einem Paket (welches man sich z.B. runterladen könnte), welches wieder ein einfaches .tar.foo Archive ist. In diesem Archive ist das Programm, so wie es nachher auf die HDD soll und ein extra Ordner mit allen Libs die das Programm benötigt. Es wird nur der Ordner mit dem Programm samt der Daten auf die HDD kopiert, nicht die Libs! Die Libs werden nur kopiert so fern noch nicht vorhanden oder neuer als im System vorhanden.
So hat halt nicht jedes Programm seine eigenen Libs, sondern die sind systemweit verfügbar. Der Grund ist einfach, das ich kein Repository habe, wo ich die Libs drin haben könnte (und zwecks Offline Installation, wie wird das eigentlich unter Linux gemacht?).

Hat man ein Repository ist es auch kein Problem die Libs von den Programmen gesondert zu liefern und zu behandeln.

Es mag Gründe für exakte Versionsstände geben. Als Beispiel führe ich mal Zertifizierungen oder digitale Signaturen an.

Also läuft es ja doch darauf hinaus das ich alle Versionen einer Lib habe. Denn so wie du es jetzt beschreibst, kann es durchaus sein, das ich 13 Programme habe und jedes benötigt eine andere Version der libSDL.so.1.2. Genau das will ich aber vermeiden.
Gibt es dafür ein praktisches Bsp, wo sowas schonmal verwendet wurde/wird?

Also willst du auf jegliche Form von Abhängigkeitsmanagement verzichten und dafür jedem Paket erlauben, potentiell dein System zu zerschießen.

Also erstmal was hintert mich daran mir das System unter Linux zu zerschiessen, in dem ich eine solche Library per Hand installiere?
Was verstehst du genau unter Abhängigkeitsmanagement?

Sicher kannst du deine C-Bibliothek auch "libc.so.6" nennen, allerdings kannst du dann nicht mehr mehrere Versionen parallel installiert haben

Ich kann dann nicht mehr mehrere Versionen mit dem gleichen Interface installiert haben und warum ist das so schlimm? Bzw. versuche ich ja genau das zu vermeiden. Dann kann man doch gleich jedem Programm seine eigenen Libs mitgeben, wenn die eh alle genau eine Version wollen.

Also ich finde den Gedanken, dass grafische Programme auch stdin/stdout benutzen dürfen, schon garnicht so schlecht... alle grafischen Unixprogramme sind auch Kommandozeilenprogramme - und sei es für Debugausgaben. Da ne willkürliche Grenze zu ziehen ist doof; außerdem kann ein Programm ja auch beides sein. Beispielsweise REGEDIT von Win95 (läuft unter DOS, aber auch grafisch), oder dein Netzwerkverwaltungstool (ist die grafische Oberfläche aktiv -> grafisch, fehlt die grafische Oberfläche -> textbasiert, wurden Parameter übergeben -> nichtinteraktiv). Der Übergang ist fließend und ihn im Betriebssystem einzumauern falsch.

Das ist ein typisches Unix Konzept, noch dazu eins mit dem ich mich noch nie anfreunden konnte. Es gibt immer das eigentliche Programm, welches ein Kommandozeilentool ist und die grafische Oberfläche ist dann nochmal ein Programm, welches nur mit dem Kommandozeilentool kommuniziert.
Zumal das ja trotzdem mit meinem Konzept funktionieren würde. Wäre halt nur ein wenig Sinnlos.

Komische Vorstellungen hast du.

Das kann man über alle Genies sagen  

FlashBurn, Du solltest Dich eventuell von dem Gedanken trennen das eine Library ein Teil des Programms ist sondern das als eigenständiges Paket betrachten von dem das Programm abhängig ist. Zu der Abhängigkeit darf dann natürlich noch die gewünschte Version der Library gehören. Wenn man das mit einer guten Paketverwaltung verknüpft kommt ein brauchbares System bei raus und Du wirst immer zuverlässig vor der Library/DLL-Hölle bewahrt.

Also erstmal mag ich die Bezeichnung DLL-Hölle nicht und hier sollten das eigentlich alle besser wissen, dass das nix mit den DLLs ansich zu tun hat, sondern ein Problem von Windows ist.
DLLs sind doch im Endeffekt nichts anderes als ELF-shared objects. Zumal DLLs vor Vista und vor mehr als 2GB RAM durchaus ihre Vorteile gegenüber ELF-shared objects unter x86 hatten.

Ich würde das ganz gerne so betrachten, aber wo kommen die Libs dann her, wenn nicht mit aus dem Paket von dem Programm? Und wie löst man Offline-Installationen?

Im Endeffekt ist es doch so, dass man unter Linux ein Programm, samt Libs, das nicht in einem Repository ist, per Hand installieren muss bzw. mit nem Skript und das ist dann auch nichts anderes als ein Setup.

Und nochmal, ein Repository ist aus mehreren Gründen nicht möglich.

Edit::

Solange du selbst dran rumwerkelst und der fast einzige Nutzer bist, sind alle diese Konzepte eh hinfällig.

Wenn es danach geht, brauche ich gar kein Management und auch keine Sicherheitsfeatures!

[Svenska]

aber wenn ich einen Standarddialog designe und verwende, dann möchte ich da auch immer z.B. "Eigene Dokumente" auswählen können, wo auch immer dieses Verzeichnis liegt. Hauptsache es ist eins vorhanden das dafür bekannt ist, dass dort die Dokumente gespeichert werden sollen.

Wow, du legst die Designkriterien aber sehr hoch an. Das kannst du (a) sowieso nicht umsetzen und (b) nutzt deine Standarddialoge am Ende eh keiner, sondern die von GTK und Qt...

Löse dich von der Vorstellung, dem Programmierer seine Verhaltensweisen vorschreiben zu wollen. Es geht nicht: Entweder du hast am Ende ein geschlossenes System (Apple) oder jemand baut einfach Alternativen (Firefox für Windows).

Ich will meine eigene Organisation und mir von niemandem reinreden lassen.

Dann ist aber Unix nicht das richtige für dich Denn da gibt es (wie auf jedem OS, gehe ich einfach mal von aus) immer bestimmte Sachen die an einen bestimmten Ort müssen.

Mein Homelaufwerk ist mir, der Rest ist dem System seins. Ich kann logischerweise nur meine eigenen Dinge organisieren.

Also ein Programm besteht erstmal aus einem Paket (welches man sich z.B. runterladen könnte), welches wieder ein einfaches .tar.foo Archive ist. In diesem Archive ist das Programm, so wie es nachher auf die HDD soll und ein extra Ordner mit allen Libs die das Programm benötigt. Es wird nur der Ordner mit dem Programm samt der Daten auf die HDD kopiert, nicht die Libs! Die Libs werden nur kopiert so fern noch nicht vorhanden oder neuer als im System vorhanden.

Das ist meiner Meinung nach schon ein großer Fehler: Zu jedem Programm gehört also eine Menge Datenmüll, der im Zweifelsfall noch nichtmal installiert wird. Damit blähst du die Pakete unglaublich auf, denn jedes Utility für eine KTaskleiste muss eine komplette Qt- und KDE-Laufzeitumgebung mitbringen, die du dann nicht installierst, weil schon vorhanden. Oder du installierst ein unglaublich neues Utility und das aktualisiert dir sämtliche Bestandteile deines Systems, was du u.U. nicht wünschst.

So hat halt nicht jedes Programm seine eigenen Libs, sondern die sind systemweit verfügbar. Der Grund ist einfach, das ich kein Repository habe, wo ich die Libs drin haben könnte (und zwecks Offline Installation, wie wird das eigentlich unter Linux gemacht?).

Ja klar und die Installation eines klitzekleinen Programms mit vielen Abhängigkeiten führt zu extrem großen Paketen und kann große Veränderungen im System bedeuten. Die Vorteile kannst du auch anders haben, ohne die Nachteile. Die Abneigung gegen ein Repository verstehe ich zwar nicht, aber das ist deine Entscheidung.

Unter Debian kannst du deb-Pakete auch per Hand installieren ("dpkg -i"), allerdings hast du dann keine automatische Abhängigkeitsauflösung. Es hindert dich allerdings auch niemand dran, alle benötigten Debs auf eine CD zu brennen (oder eine Diskette zu kopieren) und von dort dann die Abhängigkeiten automatisch zu installieren... du bist nicht ans Internet gebunden.

Es mag Gründe für exakte Versionsstände geben. Als Beispiel führe ich mal Zertifizierungen oder digitale Signaturen an.

Also läuft es ja doch darauf hinaus das ich alle Versionen einer Lib habe. Denn so wie du es jetzt beschreibst, kann es durchaus sein, das ich 13 Programme habe und jedes benötigt eine andere Version der libSDL.so.1.2. Genau das will ich aber vermeiden.

Die Möglichkeit ist gegeben. Es gibt nahezu keine Programme, die davon Gebrauch machen oder daran auch nur denken sollten. Du willst es im Übrigen nicht vermeiden, du willst es verbieten.

Gibt es dafür ein praktisches Bsp, wo sowas schonmal verwendet wurde/wird?

Updates auf Produktivsystemen mit Uptimegarantie einerseits (bzw. ich weiß von mehreren Fällen, dass jedes Programm seinen eigenen Satz OpenSSH-Bibliotheken bekommen hat), zum anderen hast du dann neben dem "allgemeinen" Versionsstand vielleicht noch einen zweiten Satz "zertifizierter" Bibliotheken für zertifizierte Anwendungen.

Also willst du auf jegliche Form von Abhängigkeitsmanagement verzichten und dafür jedem Paket erlauben, potentiell dein System zu zerschießen.

Also erstmal was hintert mich daran mir das System unter Linux zu zerschiessen, in dem ich eine solche Library per Hand installiere?

Es gibt einen Unterschied zwischen "die Installation von xyz hat mir das System zerstört" und "ich habe jetzt mit Gewalt gegen den Willen meiner Paketverwaltung diese Bibliothek installiert und jetzt geht mein System nicht mehr".

Was verstehst du genau unter Abhängigkeitsmanagement?

Welche Bibliotheken werden in welchen Versionen (exakt-major, mindest-minorversion) von einem bestimmten Programm benötigt. Also das, was eine gute Paketverwaltung tut.

Das ist ein typisches Unix Konzept, noch dazu eins mit dem ich mich noch nie anfreunden konnte. Es gibt immer das eigentliche Programm, welches ein Kommandozeilentool ist und die grafische Oberfläche ist dann nochmal ein Programm, welches nur mit dem Kommandozeilentool kommuniziert.

Das meinte ich gerade nicht, sondern das Beispiel REGEDIT (Windows) war absichtlich gewählt, um den fließenden Übergang darzustellen. Mit Frontends und Backends hat das nichts zu tun (im Gegensatz zu SCANDISK.EXE, welches unter DOS verwendet wurde und unter Windows SCANDSKW.EXE gestartet hat, war REGEDIT.EXE ein Windows-Programm, welches im DOS-Stub ein vollwertiges DOS-Programm war).

Komische Vorstellungen hast du.

Das kann man über alle Genies sagen  

Kaputtheit als Genie zu bezeichnen ist aber doch ein bisschen anmaßend.

Also erstmal mag ich die Bezeichnung DLL-Hölle nicht und hier sollten das eigentlich alle besser wissen, dass das nix mit den DLLs ansich zu tun hat, sondern ein Problem von Windows ist.

Du weißt aber schon, dass DLLs ausschließlich unter Windows verwendet werden? Von daher passt der Begriff DLL-Hölle schon (eine Shared Object Hölle wäre mir jedenfalls neu).

Ich würde das ganz gerne so betrachten, aber wo kommen die Libs dann her, wenn nicht mit aus dem Paket von dem Programm? Und wie löst man Offline-Installationen?

Wo kommt die WING.DLL denn her, wenn nicht von den Windows-Lemmingen? Na aus dem WinG-Paket natürlich. Wo kommt denn die MSVBVM60.DLL her, wenn nicht aus meiner Anwendung? Na aus dem VB6 Runtime Paket natürlich... auch Windows-Anwendungen haben Voraussetzungen und die musst du erfüllt haben. Inzwischen bringt Windows mehrere weitere komplette Runtimes mit (.net in verschiedenen, inkompatiblen Versionen) und ansonsten gibt es noch "Windows Update".

Die meisten Programme linken alle systemfremden Bibliotheken statisch ein und wenn das mal doch nicht so der Fall ist (mir fällt da WinUAE ein), dann werden die ganzen Bibliotheken (z.B. GLIB.DLL, GTK.DLL, ZLIB.DLL, ...) ins Anwendungsverzeichnis dazugelegt. Das willst du nicht.

Im Endeffekt ist es doch so, dass man unter Linux ein Programm, samt Libs, das nicht in einem Repository ist, per Hand installieren muss bzw. mit nem Skript und das ist dann auch nichts anderes als ein Setup.

Das ist Quatsch. Mal abgesehen davon ist die eigentliche Software-Verteilung von Unix nicht das Binärformat, sondern Quelltext (gucke dir mal die FreeBSD Ports oder pkgsrc an, oder wenn es Linux sein muss, die Gentoo-Rezepte). Verteilung von Binärpaketen ist eine nette Geste der Distributionen.

Die paar Male, wo ich ein Binärpaket nicht aus dem Distributionsrepository installiert habe, war das entweder ein extern gepflegtes Repository (wie Debian-Multimedia) oder es war eine DEB, die ausschließlich von Paketen abhängt, die es im Repository gibt (wie OpenTTD).

Und nochmal, ein Repository ist aus mehreren Gründen nicht möglich.

Sag doch mal.

Solange du selbst dran rumwerkelst und der fast einzige Nutzer bist, sind alle diese Konzepte eh hinfällig.

Wenn es danach geht, brauche ich gar kein Management und auch keine Sicherheitsfeatures!

Richtig.

Gruß,
Svenska

[FlashBurn]

Also ein Repository heißt für mich, ich müsste irgendwo im Internet eins haben und ich müsste es pflegen und das geht beides nicht.
Ich kann mich nicht um alle Libs kümmern und genauso wenig kann ich nen Server im Internet unterhalten.

Du (svenska) hast mir jetzt auch nur ein Bsp (OpenTTD) genannt, was nicht im Repository war, aber die nötigen Libs schon. Ich will aber mal wissen was ist, wenn du davon ausgehst, das beides Programm und Libs nicht im Repository sind. Was ist dann?

Dann sagst du das die meisten Anwendungen eh in Sourceform verteilt werden bzw. dass das mit den binären Paketen ein nettes Angebot der Distributionen ist. Ich will das aber nicht vorraussetzen. Open-Source mag ja gut und schön sein, aber warum sollte ich mich Closed-Source verschließen bzw. es schwieriger machen sowas auf meinem System auszuführen?

Selbst wenn man dann alle Libs in einzelne Pakete packt, müsste der User sie zur Not alle runterladen. Dazu muss er wissen welche benötigt werden und ganz ehrlich, das ist für mich ein großer Rückschritt. Da finde ich dann die Windowsvariante mit den MSI´s besser.

Ich sehe da erstmal kein Problem, wenn grundsätzlich davon ausgegangen wird, dass die ganzen Libs nicht vorhanden sind.

Was dein Bsp. mit QT oder KDE betrifft, da handelt es sich dann um eine ganze Laufzeitumgebung, nicht um einzelne verschiedene Libs. Das ein Programm z.B. QT vorraussetzt und diese Laufzeitumgebung dann vorhanden sein muss ist für mich was anderes. Genauso wie Java und .net. Sowas kann wirklich extra zum Programm heruntergeladen werden bzw. muss es dann für bestimmte Sachen auch.

Wie gesagt Open-Source schön und gut, aber ich will mich auch nicht dem Verschließen, das es andere Quellen gibt, die nicht in ein Repository aufgenommen werden dürfen/können.

Und das wir uns nicht falsch verstehen, ich mag Repositories, sind verdammt bequem, aber funktionieren meiner Meinung nach nur unter Linux/Open-Source unter Windows wirst du sowas aus vielen Gründen nicht hinbekommen.

Die Möglichkeit ist gegeben. Es gibt nahezu keine Programme, die davon Gebrauch machen oder daran auch nur denken sollten. Du willst es im Übrigen nicht vermeiden, du willst es verbieten.

So, es nutzt also keiner und ich soll es trotzdem zur Verfügung stellen? Wieso? Schonmal was von Altlasten gehört, die sollte man auch irgendwann über Bord werfen und genau das möchte ich an der Stelle tun

[kevin]

Also ein Programm besteht erstmal aus einem Paket (welches man sich z.B. runterladen könnte), welches wieder ein einfaches .tar.foo Archive ist. In diesem Archive ist das Programm, so wie es nachher auf die HDD soll und ein extra Ordner mit allen Libs die das Programm benötigt. Es wird nur der Ordner mit dem Programm samt der Daten auf die HDD kopiert, nicht die Libs! Die Libs werden nur kopiert so fern noch nicht vorhanden oder neuer als im System vorhanden.

Was ist, wenn ein Programm Abhängigkeiten auf Sachen hat, die der Hersteller des Programms zum Beispiel lizenzrechtlich gar nicht mitliefern darf?

So hat halt nicht jedes Programm seine eigenen Libs, sondern die sind systemweit verfügbar. Der Grund ist einfach, das ich kein Repository habe, wo ich die Libs drin haben könnte (und zwecks Offline Installation, wie wird das eigentlich unter Linux gemacht?).

Du musst dich mal von der Vorstellung trennen, dass ein Repository irgendwas mit Internet zu tun hat. Das kann genauso gut auf der lokalen Platte oder auf einer CD liegen. Ich hab hier noch einen Satz mit 7 CDs für Debian Woody rumstehen - von damals, als es noch kein Internet gab.

Schwieriger wird es natürlich, wenn die Abhängigkeit auf etwas ist, was beim System nicht dabei ist und man deswegen nicht unbedingt erwarten kann, dass es jeder installiert hat. Einfach alles mitliefern geht vielleicht, wenn das Programm auf CD ausgeliefert wird und sowieso viel Platz frei ist. Dann kannst du wieder die CD als Repository einbinden. Für einen Download würde es mich ziemlich ankotzen, für ein kleines Tool mit 50 kB Python-Code jedesmal die komplette Python-Runtime mitrunterladen zu müssen, obwohl sie nicht installiert wird.

Man kann natürlich auch die Microsoft-Variante wählen: Der Benutzer hat die Abhängigkeiten bitteschön von Hand aufzulösen. Ich hatte im Studium mal sehr viel Spaß damit, auf einer relativ frischen Windows-Installation BizTalk zu installieren. Der Installer sagt dir immer genau eine Abhängigkeit, die du als nächstes installieren musst (sprich: in meinem Fall zur CD-Ausleihstelle rennen, weil das ja alles nicht frei runterzuladen ist) und erst wenn du die erfüllt hast, bekommst du die nächste präsentiert. Ein paar Abhängigkeiten gibt es natürlich auch im Internet runterzuladen, aber auch das geht nicht automatisch, sondern du musst die Abhängigkeit manuell erfüllen. Der Graus, aber sowas kommt halt raus, wenn man keine Paketverwaltung hat...

[erik.vikinger]

Hallo,


Warum sollte man in ein Repository keine Closed-Source-Programme packen können? Wenn Hersteller XY ein eigenes Programm verticken will kann er das doch mit einem eigenen Repository anbieten und falls diese Programme Geld kosten kann man die Verbindung immer noch mit passender Kryptographie absichern damit nur Leute ran kommen die auch ordnungsgemäß bezahlt haben. Das hätte für den Kunden den Vorteil das er automagisch auch mit Bugfixes versorgt werden würde. Und bei zertifizierten Programmen kann der Hersteller eben auch die zertifizierten Versionen bestimmter Libraries mit ins Repository packen oder er verlässt sich darauf das die über das zum OS gehörende Main-Repository (oder über das Repository vom Library-Hersteller falls das was spezielles ist) verfügbar sind. All das, bis auf die automatischen Bugfixes, funktioniert auch genauso gut wenn das Repository nicht im Internet sondern auf CD/DVD/USB-Stick/sonstwas geliefert wird. Der entscheidende Punkt ist das auf dem System des Endanwenders eine vernünftige Paketverwaltung alle Fäden in der Hand hält und dafür sorgt das alle Abhängigkeiten korrekt bedient werden und es keine vagabundierenden Executables/Libraries auf dem System gibt (von selbstkompilierten Dingen mal abgesehen). Ein weiterer Vorteil ist das nur diese Paketverwaltung Executables/Librarys (außerhalb des User-Directory) installieren/ändern/entfernen kann und damit alle Programme gegen Viren usw. vorerst immun sind (klar es gibt dann noch Makro-Viren u.ä. aber die Executables/Libraries bleiben sauber und Viren können nur im User-Verzeichnis existieren).


Grüße
Erik

[Svenska]

Also ein Repository heißt für mich, ich müsste irgendwo im Internet eins haben und ich müsste es pflegen und das geht beides nicht.

Repository hat nichts mit Internet zu tun, das darf genauso auch ein lokaler Ordner mit deinen tar.foo-Paketen sein.

Du (svenska) hast mir jetzt auch nur ein Bsp (OpenTTD) genannt, was nicht im Repository war, aber die nötigen Libs schon. Ich will aber mal wissen was ist, wenn du davon ausgehst, das beides Programm und Libs nicht im Repository sind. Was ist dann?

Dann handelt es sich in der Regel um äußerst spezielle Libs, die dann ebenfalls zum Programm gehören und entweder nur von diesem Programm verwendet werden (dann wären die im gleichen Paket wie das Programm) oder vielleicht "noch" nicht offiziell im Repo drin sind, dann wäre das ein zweites Paket, zu erhalten an gleicher Stelle. Da mache ich mir keine Sorgen.

Dann sagst du das die meisten Anwendungen eh in Sourceform verteilt werden bzw. dass das mit den binären Paketen ein nettes Angebot der Distributionen ist. Ich will das aber nicht vorraussetzen. Open-Source mag ja gut und schön sein, aber warum sollte ich mich Closed-Source verschließen bzw. es schwieriger machen sowas auf meinem System auszuführen?

Sollst du doch garnicht. Closed-Source-Software stellt aber in den seltensten Fällen Libs bereit, die man systemweit für andere Programme nutzbar installieren möchte... da stellt sich das Problem nicht (Closed-Source-Software linkt sowas in der Regel statisch ein).

Ich sehe da erstmal kein Problem, wenn grundsätzlich davon ausgegangen wird, dass die ganzen Libs nicht vorhanden sind.

Nach einer Neuinstallation nicht, normalerweise wird aber die Mehrheit der Libs schon vorhanden sein. Zumindest ist das meine Erfahrung, wenn ich bei mir mal Software nachinstalliere...

Was dein Bsp. mit QT oder KDE betrifft, da handelt es sich dann um eine ganze Laufzeitumgebung, nicht um einzelne verschiedene Libs.

Was ist der Unterschied zwischen einer Laufzeitumgebung und einer (recht langen) Liste von (bestimmten) Bibliotheken? Da gibt es keinen. Willkürlich einen zu setzen bringts aber auch nicht.

Außerdem heißt "Qt" ja nicht, dass alle Libs davon vorhanden sind, viele Programme sind auch mit einer Teilmenge zufrieden. Wie das mit .net funktioniert, weiß ich nicht - bei Java gehören noch ein paar Hilfsprogramme ins Paket.

Wie gesagt Open-Source schön und gut, aber ich will mich auch nicht dem Verschließen, das es andere Quellen gibt, die nicht in ein Repository aufgenommen werden dürfen/können.

Was hindert einen Hersteller von Closed-Source-Software, sein eigenes - vom OS-Hersteller getrenntes - Repository aufzumachen? (Repository im Sinne von "hier die tar.foo zum Download".)

Und das wir uns nicht falsch verstehen, ich mag Repositories, sind verdammt bequem, aber funktionieren meiner Meinung nach nur unter Linux/Open-Source unter Windows wirst du sowas aus vielen Gründen nicht hinbekommen.

Wenn du Windows nachprogrammieren möchtest, ... Ich habe mich jetzt schon länger mit Linux befasst und finde die Konzepte dahinter oft wesentlich angenehmer als die von Windows. Sicher, es gibt Ausnahmen, aber viele Dinge sind einfach bequemer und schlüssiger. Wenn du jetzt die Windows-Konzepte übernehmen möchtest (weil du nichts anderes kennst), dann betrachte ich das als Rückschritt - daher meine Ablehnung.

Die Möglichkeit ist gegeben. Es gibt nahezu keine Programme, die davon Gebrauch machen oder daran auch nur denken sollten. Du willst es im Übrigen nicht vermeiden, du willst es verbieten.

So, es nutzt also keiner und ich soll es trotzdem zur Verfügung stellen? Wieso? Schonmal was von Altlasten gehört, die sollte man auch irgendwann über Bord werfen und genau das möchte ich an der Stelle tun

Flexibilität als Altlast zu bezeichnen finde ich vermessen.

Gruß,
Svenska

[Sannaj]

Ich prsönich finde, das auch das aktuelle Linuxsystem (dpkg/apt-basierende Ditros) gut, allerdings bemängle ich:
1. Es gibt keine Möglichkeit Programme außerhalb von Respos vernünftig dem apt-system zuzufügen.
2. dpkg verteilt die Packete munter über die Programmordner
3. Programme speichern ihre Benutzerdaten direkt in das ~ - Verzeichniss, was dazu führt, das dieser in Speicherdialogen (die versteckte Daten anzeigen) überquillt.

Also ich präfferiere folgendes System:

Das Grunddatensysstem entspricht dem von FHS, mit folgenden Erweiterungen. Inerhalb jedes Benutzerordners gibt es das Unterverzeichnis, ~/appdata welches die Programmdaten enthält. Auch gibt es einen Ordner /dae, welcher alle Server und Daemonen enthält, die notwendig sind, ein mikrokernelbasierendes System in Stand zu halten. Statt es /usr - Verzeichniss gibt es das neue /ear (Extended Application Reecurces) Verzeichniss ersetzt. Diese enthält die Ordner:
/ear/run/bin - Enthält kleine ein-Datei-Programme die nicht in /bin oder /sbin passen
/ear/run - Executionsdescriptor (Datei, die ihren Aufruf an das eigentliche Programm weiterleitet.)
/ear/proc - Enthält die Programmdaten (Fungiert so ähnlich wie eigene Dateien unter Win)
/ear/games - Optional, selbe wie /ear/proc, aber für Spiele.
/ear/lib - Programmunabhängige Bibliotheken, die nicht in /lib oder /ear/proc passen
/ear/inc - Programmheader zu den Bibliotheken. (in Unterordnern nach Programmiersprache.)
/ear/local - Programme die ohne Hilfe der Packetverwaltung installiert worden sind.
/ear/local/old
/ear/etc - Sonstiges

/ear/proc und /ear/lib bestehen hierbei aus Unterordnern. Diese folgen dem Schema <name>-<version>. Innerhalb dieser Ordner ist eine Struktur vorgegeben (alle Ordern optional):
./bin - Selbst ausführbare Dateien. (Also nicht bei Bibliotheken)
./share - Lizenztexte und co. (Geläufige Lizenzen können auch als Symlink auf /ear/etc/licences/<name> eingebunden sein.)
./src - Quellcode
Es dürfen auch noch weitere Dateien und Unterordner vorhanden sein.

Wie genau die Executionsdescriptoren in /ear/run umgesetzt werden, ist noch nicht genau festgelegt. Möglich wären Symlinks, Shellscripts (im schlimmsten Fall) oder auch Logdateien, wobei man hierfür Systemunterstürzung bräuchte.

[Svenska]

1. Es gibt keine Möglichkeit Programme außerhalb von Respos vernünftig dem apt-system zuzufügen.

Doch, und zwar der gesamte Baum unterhalb von /usr/local (der unterliegt nicht der Paketverwaltung). Beispielsweise liegt /usr/local/bin in $PATH und /usr/local/lib wird ebenfalls beachtet.

2. dpkg verteilt die Packete munter über die Programmordner

Lässt sich leicht sagen, wenn es keinen Programmordner gibt. Der FHS verteilt Programme inhaltlich (Konfigurationen nach /etc, Binaries nach /usr/bin, Manpages nach /usr/share/man, ...) und nicht nach Programmen sortiert.

3. Programme speichern ihre Benutzerdaten direkt in das ~ - Verzeichniss, was dazu führt, das dieser in Speicherdialogen (die versteckte Daten anzeigen) überquillt.

Richtig, allerdings wird mit ~/.local und ~/.config versucht, da wieder ein bisschen Übersicht reinzubringen.

Ansonsten habe ich an deinem System zu bemängeln, dass die Suche nach z.B. einer Lib dazu führt, dass sämtliche Verzeichnisse unterhalb von /ear/lib/* vom Loader durchsucht werden müssen und dass es prinzipiell mehrere gleichnahmige Dateien geben kann.

Wenn du /ear/proc/ als "eigene Dateien" betrachtest, verkennst du, dass dieser Ordner irgendwo unter /home liegen sollte - weil er nutzerspezifisch ist.

Eine Mischung ist meiner Meinung nach nicht sinnvoll. Dann kann man lieber /app/programmname/* haben und jedes Programm darf seinen Programmeordner frei gestalten (und sonst nur nach /home/$USER/AppData/programmname schreiben).

Mehr denke ich darüber jetzt aber auch nicht nach.

Gruß,
Svenska

[Sannaj]

1. Es gibt keine Möglichkeit Programme außerhalb von Respos vernünftig dem apt-system zuzufügen.

Doch, und zwar der gesamte Baum unterhalb von /usr/local (der unterliegt nicht der Paketverwaltung). Beispielsweise liegt /usr/local/bin in $PATH und /usr/local/lib wird ebenfalls beachtet.

Ich hab nicht behauptet, das man nicht auch Programme selber installieren kann. Dazu ist /usr/local und /opt ja da. Was ich kritisiert habe, das man das an apt vorbeimachen muss. (Ich stell mir ne Methode vor, bei der man eine Metadatei an apt übergibt, das dann unter zuhilfenahme der in der Respo und der in der Metadatei enthaltenen Pakete das Programm samt allen Abhängigkeiten installiert.)

3. Programme speichern ihre Benutzerdaten direkt in das ~ - Verzeichniss, was dazu führt, das dieser in Speicherdialogen (die versteckte Daten anzeigen) überquillt.

Richtig, allerdings wird mit ~/.local und ~/.config versucht, da wieder ein bisschen Übersicht reinzubringen.

Schön wär's. Leider liegt bei mir  immer noch von scheinbar jedem Programm ein Unterordner direkt im Homeverzeichniss.

Ansonsten habe ich an deinem System zu bemängeln, dass die Suche nach z.B. einer Lib dazu führt, dass sämtliche Verzeichnisse unterhalb von /ear/lib/* vom Loader durchsucht werden müssen und dass es prinzipiell mehrere gleichnahmige Dateien geben kann.

Wieso ich hab doch deshalb extra diese <name>-<version> Form eingeführt. Der Libname sollte halt in den Include-Header Dateinen gescheit vermerkt werden.

Wenn du /ear/proc/ als "eigene Dateien" betrachtest, verkennst du, dass dieser Ordner irgendwo unter /home liegen sollte - weil er nutzerspezifisch ist.

Da hab ich mich vertippt. Ich meinte C:/Programme nicht ./Eigene Dateien.

Alles in Allem Danke ich dir aber für deine konstruktive Kritik. Ich versuche halt nur, das Ein-Programm = Ein-Ordner-System (welches ich persönlich bevorzuge) mit den Ansprüchen, die bei Linux vorherrschen (Gemeinsame Bibliotheken, Einfache Nutzung über's Shell, etc.) zu verbinden.

Deine letzte Bemerkung halte ich für nützlich. Vielleicht ist es besser /usr doch nicht abzuschaffen und dafür die zusätzlichen Ordner /app mit den Unterverzeichnissen. /app/proc für proc für Programme und /app/run für die Executivdeskriptoren einzuführen.