GnuZukunft hier beschreiben... 
Ansätze, die in Zukunft die Arbeit mit Freier Software stark positiv beeinflussen und erfrischen können.
Ein plattform- und distributions-übergreifendes Paketformat (wie z.B. http://www.autopackage.org), das am besten gleichzeitig AppDir-kompatibel ist, um Programmpakete einfach überall ausführbar zu machen (sofern /home nicht als noexec gemounted ist).
Darüber kann man sich ewig streiten, ohne auf ein sinnvolles Ergebnis zu kommen. Zum Standard wird das IHMO nie. -- RonnyBuchmann 2003-10-13 13:02:20
- Da hast Du recht, war auch anfänglich nicht so eindeutig ausgedrückt, natürlich jeder wie er möchte. Ich meine die konstruktivste Lösung ist einfach beides nebeneinander zu ermöglichen (Prinzip Freiheit).
Regeln ähnlich dem Choices-System, um Programmeinstellungen system- und benutzerspezifisch abgestuft zu verwalten (KDE macht das schon so ähnlich, beschränkt sich aber auf native KDE apps).
- Das ist bei fast allen Programmen so, aber etwas Vereinheitlichung wäre nicht von Schaden.
NEU: Auf freedesktop.org existiert nun eine Basedir Spezifikation.
Ich kann nichts wirklich revolutionäres an Choices entdecken -- allenfalls schlechte Standard-Verzeichnisse: ein offenes Verzeichnis im Home und die systemweite Konfiguration unter /usr/share -- aua! Ansonsten gleicht es weitgehend der alten Systematik /etc/foo systemweit und zusätzlich $HOME/.foo benutzerspezifisch zu halten. Sinnvoller wäre da schon das Verschieben der Benutzer-Konfigurationen nach $HOME/.etc, wie es MirBSD macht. -- BennySiegert 2003-10-13 13:39:02
- Naja, ein Verzeichniss z.B. unter /usr/share wäre für Netzwerkweite Voreinstellungen gedacht. Bisher gibt es doch nur Benutzer- und lokale Einstellungen. Hat jemand evtl. einen besseren Pfad-Vorschlag?
Sehr interessant! Bessere Pfade wie $HOME/.etc wären sicher was für LSB. Die Idee das konkrete Verhalten und die genauen Speicherorte allgemein per Environment Variable steuerbar zu machen sowie eine "kein speichern von defaults" und allgemeine Merging Policy zu haben find ich aber gut.
Ein System wie ZeroInstall, um auf Systemebene die zusätzliche "Installation"/Bereitstellung von Software zu verwalten bzw. dies überflüssig zu machen.
Dazu müssten ebenfalls erstmal die bekannten Probleme der Binärdistribution beseitigt werden. Was IMHO nicht möglich ist. -- RonnyBuchmann 2003-10-13 13:02:20
- Lösungen zur Binärkompatibilität sind gut in der FAQ von autopackage.org erläutert.
Config4Gnu (auch kurz CFG genannt), um die verschiedensten Konfigurationsarbeiten flexibel zu integrieren.
Daraus könnte u.U. wirklich was werden, aber eigentlich gibt es das schon -> Webmin. -- RonnyBuchmann 2003-10-13 13:02:20
Ich halte das Config4Gnu Projekt für eine geniale Sache, genau nach sowas habe ich schon seit einiger Zeit Ausschau gehalten. Es ist nicht mit Webmin vergleichbar. Es schafft einen Zwischenlayer, sozusagen einen Übersetzer, der alle Konfigurationsdialekte erzeugen kann und eine einheitliche Konfigsprache versteht. Egal, was auch immer ich konfigurieren will, ich kann es mit einer einheitlichen Konfigsprache tun, egal ob mit Webinterface, auf der Kommandozeile, durch ein Skript oder wie auch immer. Jetzt brauche ich nur noch im Fokus zu haben, was ich konfigurieren will und nicht mehr, wie ich überhaupt konfigurieren kann. Ich brauche nicht immer wieder neue Konfigsprachen zu lernen. Bei den meisten bisherigen grafischen Tools ist es auch so, dass nicht transparent alle Konfigparameter dargestellt werden. Es handelt sich oft um Wizzards, die irgendwas einstellen, wo mir gar nicht klar ist, was die genau im Hintergrund tun, welchen Parameter die nun genau mit welchem Wert einstellen. Deshalb mag ich solche Werkzeuge auch nicht besonders. Bei solchen Werkzeugen ist es bisher auch so, dass man für jedes Konfigurationsfile ein neues Frontend schreiben muß. Bei Config4Gnu ist das nicht der Fall, weil es generischen Regeln folgt. -- WinfriedMueller
Wer hier einen neuen Ansatz sucht sollte sich auch debconf anschauen. Ist zwar debian spezifisch aber das war apt auch.
Speziell die Trennung Frontend / debconf / Backend lässt eine gute Scalierung zu. Außerdem braucht ein solches tool meiner Meinung eine Distribution in der es reifen kann. -- AndreasSchockenhoff 2003-12-03 18:28:43 debconf wurde von den CFG (aka Config4Gnu) Entwicklern tatsächlich intensiv angeschaut, und Debian gehört wohl wie so oft auch hier zu den Besten. CFG vereinte dann viele Vorteile, auch so das debconf selbst stark davon profitieren kann, es kann an CFG andocken, CFG wird aber selbst per Design keine Zustände außerhalb der Konfigurationsdateien speichern. Genau das tut debconf nämlich leider und führt daher zu den allseits bekannten "debconf is not a registry" vs. "managed by debconf" Konflikten.
- Was das reifen anbelangt ist CFG extra so gestaltet das es dezentral applikationsorientiert reifen kann, aber auch ganze Projekte wie Debian-Edu / Skolelinux sind daran interessiert.
OffeneFrage: Was bräuchte man mehr für "The Brave GNU World"?
Frage: Hier scheint ja jemand sehr stark in Rox verliebt zu sein?
- Nicht wirklich. Ich bin neu darauf gestoßen, aber das Projekt spricht genau die Fragen an, die ich mir auch schon länger gestellt habe. Andere Ansätze wären auch interessant. Autopackage.org hat zum Beispiel relevante Links.
Für echtes weiterkommen von freier Software sind eigentlich nur distributionsunabhängige Projekte geeignet. Leider scheinen die ganzen Eigenentwicklungen der großen Distributionen die Entwicklung in diese Richtung zur Zeit aber stark zu behindern.