Dieser Ulrich ist echt ein Arsch...

Braucht kein Mensch.

Das abschließende Statement von icculus kann ich vollkommen nachvollziehen, die Engstirnigkeit im OpenSource-Bereich ist einfach unübertroffen und die Arbeit an einem Ein-Man-Projekt ist zwar oftmals anstrengend aber weit weniger Nervenaufreibend als sich mit irgendwelchen Irren auf Mailinglisten rumzuschlagen.

Die Aversion FatELF für Kernelmodule zu verwenden kann ich noch nachvollziehen, für den Desktopbereich ist die Einführung von Multiplatform-Binaries aber ein echter Segen und wenn sich der GLIBC-Maintainer dagegen ausspricht dann sieht man daran nur mal wieder, wie wenig sich die meisten OpenSource-Entwickler für die Verbreitung ihrer Software interessieren ("wieso, bei mir läuft es doch, ich benötige das Feature nicht").

Mit nur einer Architektur wäre das Problem auch gelöst.

Ich war wirklich sehr gespannt darauf. Zumal das FatELF Format keinen Nachteil mitsich bringt, sondern nur Vorteile.
Laut dem Entwickler ist es ein weiterer Container, der fast nix verbraucht außer Speicherplatz. Und wenn, dann lässt sich der Speicherplatzverbrauch minimieren, indem man die anderen Architekturen löscht.

Und schade, dass dieser engagierter Kerl so nieder gemacht wurde.
Mein Motto: Open-Source for open-minded people.

...an einem .app Format arbeiten. So wie bei Mac OS X. Natürlich gibts die Repos. Aber für manche Anwendungen wär's einfach besser, wenn man einfach ne datei runterladen müsste, in den App Folder kopieren und fertig.

Oder war FatELF sowas? Dann hätte ich aber was missverstanden.

Eine Sache, die mir an Linux gefällt ist, dass es immer noch viele Leute gibt, die versuchen das System möglichst effizient zu halten. FatELF würde mir Daten auf den Computer schaufeln, die ich nie benötige. Bin froh, dass die Idee nicht weiter verfolgt wird. Ich hoffe das bleibt so.

Ich bin selbst kein Entwickler, sondern war mal ein arrangierter User der sich auch einbringen wollte. Als ich auf Verschiedenen Linuxtagen/KDEtagen/Mailing Listen verschiedene Vorschläge vorgetragen habe gab es eigentlich nur Ablehnungen. Klar ich wäre eh nicht in der Lage gewesen diese umzusetzen, aber das Prinzip bleibt das gleiche.

Wenn es ein paar Köpfe nicht Verstehen oder haben wollen wird es eben nicht gemacht. Und ein Fork ist ist eben auch keine Option.

Nein Sager (eigentlich das äquivalent von Ja sagern ) sind etwas menschliches und die gab es in der Menschlichen Geschichte immer wieder.

grüße,
Heinz

muss es noch lange nicht so gut sein, dass man es unbedingt nachmachen muss. Unified Binaries sind, wie das Beispiel OS X gezeigt hat, im Wesentlichen ein guter Weg, um überflüssigen freien Festplattenspeicher zu belegen. Da es so etwas wie überflüssigen freien Festplattenspeicher nicht wirklich gibt, ist der Nutzen darauf begrenzt, die Fehler, die man bei der Distribution von Software machen kann, abzufangen.

Das bringt einen zu dem Schluß, dass man lieber die betreffenden Fehler vorher vermeiden und den Festplattenplatz sparen sollte. Abgesehen davon muss man sich nicht entmutigen lassen, nur weil andere von einer Idee nichts halten, sondern lieber die Gründe prüfen, ob sie für einen selbst gelten oder nicht.

Gruß, LX

Die Bessere Lösung wäre,
Binaries und Libs als Pseudo Assembler auszuliefern und
während der Installation ein "make" zu machen,
dass den Pseudo Assembler für die Zielplattform assembliert.

So wie ich das auch aus eigener Erfahrung sehe; Die sogenannte Linux Community gebärdet sich oft wie ein Debattierklub. Außerdem scheinen sich eher Innovationsfeindlichkeit und Betriebsblindheit durchzusetzen als moderne und frische Lösungen. So werden Jahr für Jahr die gleichen Altlasten durchgeschleppt und das hehre Ziel, der Desktop des Users, bleibt im Null Komma Bereich. Schade um die vergeudeten Möglichkeiten.

Etwas Ordnung und Übersicht zu schaffen in dem Linux Babylon wäre ein erster Schritt zu den Anwendern hin!

Ich fand die Idee gut und hatte echt Hoffnung. Schade, wenn es jetzt gestoppt wird.

Die Idee mehrere Binaries in einer Datei zu halten für verschiedene Archithekturen hört sich im ersten Moment gut an, aber löst die wirklichen Probleme nicht wirklich.

Zu einen muss der Ersteller der FatELFs an alle möglich Plattformen denken beim kompilieren. Wer schon man Cross kompiliert hat, weiß das ist nichts was man ohne Zeitaufwand macht. Übrigens, um Sache richtig kompilziert zu machen, es gibt Archithekturen die Big-Endian oder Little-Endian sein können, und um es richtig komplex zu machen mit FPU oder ohne sein.
Ein Prozessor... viermal Code.

Das ganze Konzept taugt eh nur für closed Source, bei open source kann jeder selber kompilieren. Bei CS kann nur einer kompilieren und der muss dann auch noch das obige Problem lösen. Bei mancher CS Software klappt das ja nicht mal mit einer Plattform.

Auch der Blick zu Apple, und die Schlußfolgerung das die mit Universalbinaries hätten ja auch sowas ist falsch: Apple hat ein Problem mit einen üblen Hack beseitigt. Derzeit beseitigen sie diesen Hack, im dem sie die PPC-Platform absterben lassen, siehe Snow Leopard.

Welcher Ansatz würde funktionieren?
ich werfe da mal ein Blick zum LLVM. Würde man statt Binaries, den LLVM Bytecode ausliefern und ein JIT-Compiler haben wäre das Problem elgant gelöst. Der Witz bei der Sache, mit She-Bang muss nicht mal groß das Rad neu erfunden werden. Es müsste heute schon out-of-the-box funktionieren.

Gruß Micha

ich denke der punkt wurde noch nicht angesprochen: wenn die binarys grösser werden weil verschidene architekturen zusaamengepackt wurden vergrößert sich der traffic auf den servern die diese software ausliefern.
traffic verursacht kosten und ich denke das manche uni-mirrors die ein oder andere dirstibution von ihren (kostenlos zugänglichen!) servern nehmen würden.

Ich hab Systeme mit PA-Risc-, Sparc-, Alpha-, Intel- und AMD64-Prozessoren und ich hätts wirklich angenehm gefunden, wenn ich für alle diese Systeme einunddieselben Binaries, vielleicht sogar einunddieselbe Distributions-CD hätte nehmen können. So muß ich halt weiter mit unzig unterschiedlichen Datenträgersätzen jonglieren.

Es gibt nicht nur 32bit-Intel-Prozessoren!!!