> Wird dies nicht erreicht, müssen Anwendungsentwickler unter > Umständen mehrere Varianten ihrer Software pflegen, sofern > diese nicht quelloffen ist.
Stimmt doch gar nicht. Kann es sein, dass dieser Satz ein wenig tendenziös ist?
Richtig wäre meiner Meinung nach:
"Wird dies nicht erreicht, müssen Anwendungsentwickler unter Umständen mehrere Varianten ihrer Software pflegen, und zwar unabhängig davon, ob diese quelloffen ist oder nicht."
Wenn eine Bibliothek keine stabile API hat, dann erschwert dies _jedem_ Softwarehersteller, der diese Bibliothek benutzen will, die Arbeit und seine Produktivität. Es gilt eben gerade nicht der Satz: "Ist doch OSS, kannst Du doch jederzeit selbst kompilieren und selbst für Dein System zurechtpatchen."
Oder vielleicht gilt der Satz doch, es ist aber definitiv _nicht_ die Absicht, gezielt den Herstellern nicht quelloffener Software entgegenzukommen, sondern es soll eine standardisierte Umgebung für _jedermann_ geschaffen werden. Dass dies auch Software, die nicht quelloffen, einschließt, liegt in der Natur der Sache, ist aber nicht das zentrale Ziel, sondern ein Nebeneffekt.
Es wundert mich ehrlich gesagt, dass auch hier wieder diese Kategorien und Schubladen zum Vorschein kommen, um die es bei der LSB eigentlich überhaupt nicht geht. Auch der Autor einer x-beliebigen quelloffenen Software hat auf der Basis der LSB die Möglichkeit, seine Software für Linux zusätzlich zum Quellcode auch als Binärpaket anzubieten.
Auf der meistgenutzten Desktop-Plattform ist dies auch für quelloffene Software längst üblich und nützlich, unter Linux geht das zur Zeit schwierig und in einigen Fällen überhaupt nicht, genau daran arbeitet jetzt die LSB - nutzen kann die Ergebnisse _jeder_.
> Es wird die GUI-Toolkits standardisieren und sehr > wahrscheinlich sowohl GTK+ als auch Qt umfassen.
Quellenangabe? Nach meinem Kenntnisstand ist diese Information falsch.
Weiß ich. Bezug? Von Nachteil für jedermann sind Inkontinuität bei beidem und um beides kümmert sich die LSB - im Allgemeinen schon seit langem und jetzt auch ganz speziell für Desktop-Systeme und Desktop-Anwendungen.
Oder verstehe ich die Andeutung leider richtig und Du meinst doch, dass jeder alles passend zu seinem Problem selbst kompilieren soll? Das ist zumindest der erste Gedanke, den ich bei überflüssigen Belehrungen über den Unterschied zwischen API und ABI habe. Genau das will die LSB doch überflüssig machen.
Quellenangabe? Nach meinem Kenntnisstand ist diese Information falsch.
Lies dir mal den Artikel durch: Es weiß die Unterstützung von zahlreichen Firmen hinter sich, darunter Adobe, IBM, Intel, HP, Linspire, Mandriva, Novell, RealNetworks, Red Hat, Trolltech und Xandros.
Was hat Xandros mit Gtk+ zu tun? Du hast dich sicher verlesen und gedacht, dort würde Ximian stehen. Ximian gehört schon seit langem zu Novell, welche zu den Unterstützerfirmen gehört, genauso wie Red Hat, die voll auf GNOME setzen.
> es ist aber definitiv _nicht_ die Absicht, gezielt den Herstellern nicht quelloffener Software entgegenzukommen, sondern es soll eine standardisierte Umgebung für _jedermann_ geschaffen werden. Dass dies auch Software, die nicht quelloffen, einschließt, liegt in der Natur der Sache, ist aber nicht das zentrale Ziel, sondern ein Nebeneffekt.
Ja,ja, niemand hat die Absicht... (Interessenlage und Hintergedanken werden stets bestritten.)
Verdrehungsrethorik ist doch nich zu übersehen. Freie Software mit Versions- und Distributionswerkzeugen ist nicht von Binärkompatibilität abhängig.
Es muß auch nicht jeder für sich kompilieren. Das ist nicht nötig, der Dezentralisierungsgrad kann nach Bedarf optimal gewählt werden.
Sourcecode kann zentralisiert upgedated werden und dabei nicht unfrei gemacht werden. Binärcode kann, wenn er zentralisiert upgedated wird, auch unfrei gemacht werden.
Von Binärkompatibilität profitieren in erster Linie proprietäre Softwarekopiermodelle. Die Arbeit haben externe Entwickler die die Binärkompatibilität gewährleisten sollen, anstatt sich mit Werkzeugen, die den Sourcecodefluß von upstream auf unterschiedliche Platformen und Distributionen verbessern, das Leben zu erleichtern.
Nebenwirkungen verändern nichts am Hauptzusammenhang.
> Sourcecode kann zentralisiert upgedated werden und dabei nicht unfrei > gemacht werden. Binärcode kann, wenn er zentralisiert upgedated wird, > auch unfrei gemacht werden.
Wie gemein, da gibt es doch tatsächlich Leute, die für ihre Arbeit Geld haben wollen. Wie böse ist doch die Welt.
> Von Binärkompatibilität profitieren in erster Linie proprietäre Softwarekopiermodelle.
Nein, davon profitieren alle, denn es macht allen das Leben leichter.
> Die Arbeit haben externe Entwickler die die Binärkompatibilität gewährleisten sollen, > anstatt sich mit Werkzeugen, die den Sourcecodefluß von upstream auf unterschiedliche > Platformen und Distributionen verbessern, das Leben zu erleichtern.
Ach ja, man muss sich nur lange genug einreden, dass etwas so ist, wie es zu sein hat. Es wird mit Sicherheit ein Vielfaches an Arbeit in zig Paket- und Installationssysteme, Binärpakete für > 300 Linuxdistris und noch ein Dutzend Unixe gesteckt als es nötig wäre, durch ein vernünftiges Konzept Binärkompatibilität sicherzustellen. Und das Wichtigste: für den Normalanwender würde Linux auf einmal benutzbar werden. Zumindest in diesem Punkt.
Geld soll für den sofortigen oder späteren Empfang von Leistung umlaufen müssen, und nicht für künstliche Knappheiten abgegeben werden müssen.
Wo mehr Geld eingenommen wird als Leistungen bezogen werden sollte es auch nicht so leicht zum Aufbau künstlicher Knappheiten verwendet werden können, weil es an anderer Stelle, zur Aufrechterhaltung der Wirtschaftskreisläufe (der Konkurenz) fehlt. (Zentralisation)
In einer gesättigten Volkswirtschaft werden absolute Gewinne theoretisch immer schwerer.
Die Knappheit macht den Preis. Was wird bei entwickelten Volkswirtschaften mit hoher Produktivität (hier und heute) teurer?
Mit privatisierten natürlichen Monopolen und Monopolrechten künstlich knappgehaltenes?
Arbeitskraft, die nicht mehr die jährliche prozentuale Kapitalrendite erwirtschaften kann?
Produktionsmittel die nicht mehr wegrationalisiert werden (Überkapazitäten)?
Geld und kurzfristige Geldforderungen die liquide gehalten werden können und bei niedrigem Renditenivau und Inflation keinem Angebotsdruck unterliegen?
----
Selbst wenn wirklich durch synchrone ABIs alle profitieren sollten, profitierten proprietäre Softwarekopierer mit der für die Verbreitung Freier Software gar nicht notwendigen Binärkompatibilität mehr.
Und zwar auf Kosten derer, die die Arbeit der Programmierer Freier Software bezahlen.
Nebenwirkungen heben noch immer keinen Hauptzusammenhang auf.
Man merkt, dass Du nur zum Hausgebrauch kopierst. Selbstverständlich macht kopieren Arbeit. Auch das Vorhalten von Kopien, der benötigten Infrastruktur etc. verursacht keineswegs geringe Kosten.
> In einer gesättigten Volkswirtschaft werden absolute Gewinne theoretisch immer schwerer.
PDS-Listenkandidat?
> profitierten proprietäre Softwarekopierer mit der für die Verbreitung Freier Software > gar nicht notwendigen Binärkompatibilität mehr.
Und das ist ganz schlimm. Auweia, die bösen Closed-Source-Anbieter profitieren mehr davon. Lieber soll es allen schlecht gehen. Doch nicht PDS, die versprachen immerhin Luxus für alle.
> Und zwar auf Kosten derer, die die Arbeit der Programmierer Freier Software bezahlen.
Ja, wer bezahlt denn die Arbeit der OSS-Programmierer? Entweder die Programmierer selbst, indem sie ihre freizeit opfern oder der Steuerzahler, wenn Angestellte des öffentlichen Dienstes während ihrer Arbeitszeit an OSS arbeiten.
> Nebenwirkungen heben noch immer keinen Hauptzusammenhang auf.
Ideologien scheitern immer an den Gesetzen der Ökonomie.
Das mit Hausgebrauch, dass kann man so vielleicht nicht sagen, wir stimmen darüber überein das kopieren allgemein Arbeit und Kosten macht. Abhängig von der Art und Weise der Methoden und der Medien, aber ebenso unabhängig von dem Erstellungsaufwand "in" der "Software", wie unabhängig vom Marktpreis für die Kopie.
Es liegt einfach nicht im Interesse Freier Software, aber auch nicht der Allgemeinheit Unfreiheit zu fördern oder zu sichern. Und man kann das einfach lassen sobalt man es erkannt hat, da braucht man kein Feindbild und keine Unterwerfung.
Viele Programmierer Freier Software Opfern ihre Zeit damit sie die Softare haben können wie sie sie möchten.
Als Lohnarbeiter werden sie dafür bezahlt, dass sie die Software so anpassen wie es, von dem der dafür bezahlt, gewünscht ist, oder dafür, dass sie Sicherstellen das der Betrieb möglichst störungsfrei aufrechterhalten werden kann. Es macht Sinn sie ggf. auch als Administratoren/Maintainer weiter zu bezahlen wenn gerade alles zur Zufriedenheit funktioniert.
So stellt man sicher das sie bei Bedarf sofort mit hoher Priorität vor Ort zur Verfügung stehen, und sie sich über die Vernetzung mit anderen Programmierern, Administratoren und Nutzern mit geringerer und höherer Erfahrung als sie jeweils selbst kontinuierlich Weiterbilden können.
Dies ist unabhängig davon für wen Freie Software Programmierer arbeiten, es gibt sie in privaten wie im öffentlichen Dienst.
Darüber das es im Bereich des öffentlichen Dienstes heute zu Ineffizienzen kommt, die es erlauben das dort während der Arbeitszeit teils zweckfremde oder gar ganz überflüssige Sachen gemacht werden, brauchen wir uns nicht zu streiten.
Das hat mit dem Staatsmonopol zu tun aber nichts mit Freier Software.
> Nebenwirkungen heben noch immer keinen Hauptzusammenhang auf.
Ideologien scheitern immer an den Gesetzen der Ökonomie.
Dem stimme ich vom ganzen Herzen zu.
Die Ideologie der Wachstumsökonomiker scheitert wiederholt an den Gesetzen der naturwissenschaftlichen Ökonomie.
Man schaue sich mal genauer die *Volkswirtschaflichen* Märchen an. Z.B.: Sparen baut Staatsschulden ab. Nur private, kapitalgebundene Vorsorge hilft im Alter. Arbeit ist zu teuer.
Dabei ist klar das jeder (Kapital-) Gewinn mit einem (Kapital-) Verlust an anderer Stelle einhergehen muß, die Entropie immer zunimmt, folglich Erhaltungsarbeit nötig ist.
Von Flux W. Wild am Do, 20. Oktober 2005 um 08:08 #
Versuch z.B. mal ein Programm dass QT benötigt auf einem Rechner zu compilieren, auf dem keine QT Entwicklerpakete vorhanden sind. Da helfen dir auch beste Programmierkenntnisse und der Quellcode nichts.
>>Richtig wäre meiner Meinung nach: "Wird dies nicht erreicht, müssen Anwendungsentwickler unter Umständen mehrere Varianten ihrer Software pflegen, und zwar unabhängig davon, ob diese quelloffen ist oder nicht."<<
Richtig, aber auch trivial: so lange Softwareentwickler selber auf einer bestimmten Plattform mit Binärpaketen präsent sein wollen, müssen sie Binärpakete pflegen. Das gilt offensichtlich für Entwickler freier und unfreier Software. Aber im Unterschied zu freier Software, deren großer Vorteil bekanntermaßen ist, daß jeder den Quellcode einsehen, modifizieren und kompilieren kann und darf, müssen Entwickler unfreier Software Anpassungen zwecks Plattformkompatibilität selber vornehmen und bleiben auch auf der Erstellung von Binärpaketen hängen. Entwickler unfreier Software können entwicklungsmodellbedingt diesen Aufwand nicht ohne vorherige juristische Absprachen an Dritte abgeben. Freie Software hingegen wird mit dem Release in die Öffentlichkeit von diesen Lasten befreit und daher findet sich meistens ein Dritter, der diese Aufgaben übernimmt und, wenn nötig, Änderungen zwecks Plattformkompatibilität vornimmt. Aus dieser Perspektive stimmt der Originalsatz zweifelsohne, denn nur Entwickler unfreier Software müssen die Binärpakete unbedingt selber erstellen.
Davon mal abgesehen ist der Satz, den Sie mockieren Teil der Berichterstattung und nicht des LSB-Statements. Ich glaube, daß die Autoren von Pro-Linux meiner Ansicht -- wie oben beschrieben -- folgen und nicht das offensichtliche wiederholen wollten. Hier gilt (oder sollte gelten) das Prinzip der Benevolenz.
>>Quellenangabe? Nach meinem Kenntnisstand ist diese Information falsch.<<
Das verlinkte Wiki zeigt die LibQT im Ratifizierungsprozeß. Dieser scheint so weit fortgeschritten, daß die Wikiautoren sicher sind, daß die LibQT Teil der ersten Runde sein wird.
Es ist ja schön das man Standards schafen will und sogar mit einander redet um da gemeinsam was zu erreichen, aber als Programmierer (bisher nur Privat und im Studium) sehe ich da ein paar ganz andere Probleme. Ich programmiere schon seit ein paar Jahren mit Delphi und habe seit gut 2 Jahren, dass Problem das mich meine eingenen Anwendungen weiter an Windows binden. Mit Lazarus konnte ich schon einiges relativ einfach unter Linux ans laufen bekommen, allerdings würde ich lieber auf C++ umsteigen. Im Text Modus ist es auch absulut kein Problem, im Gegenteil, der Code ist schön kurz und man muss weniger tippen. So bald allerdings Graphische Oberfläschen ins Spiel kommen fängt der Spaß an. Die erste Frage die sich stellt was nehme ich denn zum programieren: QT, GTK, wxWidgets oder doch was anderes? Die Probleme mit dem Aussehen von GTK Programmen unter KDE und QT unter Gnome sind ja bekannt. Vorallem ist das Problem, dass man sich erst mal eine Weile rein arbeiten muss und wenn man dann aufs falsche Pferd gesetzt hat, darf man wieder bei Null beginnen. Vom Kompfort der Entwicklungs Umgebungen mal ganz zu schweigen. Etwas das wirklich an Sachen wie Visual Studio, Borland C++ Builder und ähnliche Sachen ran kommt und sowohl unter Linux als auch unter Windows verfügbar ist hab ich bisher noch nicht gefunden. Eclipse ist zwar schon ganz gut, aber 100% kann es noch nicht mithalten bei den Graphischen Sachen.
Was wirklich sinnvoll wäre um diese Probleme, die sicher auch genug professionelle Programierer haben zu lösen wären vereinheitlichungen bei dem Graphik Frame Works wie QT, GTK usw.
Bei der Objekt Orientierten Programmierung gibt es doch alles was man braucht: Vererbung, Geheiniss Prinzip usw.
Was spricht dagegen sich bei den wesentlichen Elementen wie Formular, Label, Edit , Button usw. auf standardisierte Bezeichnungen zu einigen.
Also praktisch werden von den vorhandenen Klassen von QT noch mal Klassen abgeleitet, die Standard bezeichnungen haben Also statt auf einen qtButton oder GTKButton nehme ich einen Standard-Button und gebe dann beim kompilieren an wo gegen ich linken will. Schon kann ich mit einem Code, der sich an den Standard beschränkt jeder Zeit eine QT oder GTK Anwendung machen und habe eine Version die unter Gnome und eine zweite die unter KDE gut aussieht. Vorallem kann als Programmierer beim wechsel der Bibliothek vieles machen wie bisher und muss nur bei den Zusatzsachen etwas umlernen. Also man kann so zusagen neben dem Code auch einen großen Teil der Erfahrung weiter nutzen und muss nicht alles neu lernen.
Sowas kombiniert mit guten Plattform unabhängigen Tools für die Entwicklung und schon klappt es mit den Anwendungen für Linux.
Von Kevin Krammer am Di, 18. Oktober 2005 um 23:48 #
Ich denke für Entwickler, die mit einem Wrapper Toolkit arbeiten wollen, gibt es mit wxWidgets bereits eine sehr gute Lösung.
Aber darum geht es bei LSB ansich nicht, sondern um die Sicherheit für Softwarehersteller (alle, nicht nur Firmen) daß Bibliothek mit bestimmen API und ABI Versionen vorhanden sind.
Es erleichtert also weniger die Entwicklung, sondern die Verteilung/Installation.
Von theBohemian am Mi, 19. Oktober 2005 um 00:14 #
Die Sache ist nur, dass die Angelegenheit von denen geregelt wird, die sich beteiligen. Du hast hier sehr viel Text geschrieben, der aber gar nicht die richtigen Leute treffen wird.
Wenn du deine Wünsche einbringen willst, solltest du es bei der FSG versuchen. Feedback und Peer Review wird es dort genug geben.
Dieser Sachverhalt, den Du da beschreibst, ist wichtig, aber nicht Linux-spezifisch und hat auch nicht besonders viel mit der Arbeit der LSB zu tun. Die LSB sieht ihre Aufgabe nicht darin, Lücken im Softwareangebot zu schließen - das muss der Markt tun, dieser ist zur Zeit, was Linux auf dem Desktop angeht, nicht sehr riesig, das kann sich ändern oder auch nicht - und sie sieht ihre Aufgabe auch nicht darin, auf die konkrete Gestaltung von Bibliotheken Einfluss zu nehmen, sondern sie sagt: Wenn ein Distributor eine Bibliothek mitliefern will, dann soll er Version X nehmen, wenn eine Bibliothek unterschiedlich konfiguriert werden kann, dann soll sie nach Schema Y konfiguriert werden usw.
Was die unterschiedlichen Grafik-Toolkits angeht: Man meint immer, dies sei ein Linux-spezifisches Problem, ist es aber gar nicht. Auch auf anderen Plattformen muss man sich entscheiden. Da fällt die Entscheidung oft leichter, weil die Hersteller der jeweiligen Plattform ein eigenes haben, das in der Folge dann auch überwiegend benutzt wird, aber entscheiden muss man sich immer, und man muss auch damit leben, dass man, wenn man sich mal entschieden hat, nicht ohne umfangreichere Portierung wechseln kann.
Was den Vorschlag eines Wrappers für die beiden meistbenutzen GUI-Toolkits angeht: Den Vorschlag verstehe ich nicht ganz - was soll das denn bringen? Die beiden Alternativen haben einen unterschiedlichen Umfang, so dass ein Wrapper, der beide abdeckt, nur eine Untermenge der beiden sein könnte und außerdem wäre so ein Wrapper wahrscheinlich sowieso schlechter als die Originale, was die Performance, die Qualität der API usw. angeht. Entscheide Dich einfach, auf anderen Plattformen hättest Du Dich auch entscheiden müssen.
Was wrapper angeht: Es gibt für wx einen Patch, der es gegen Qt statt gtk baut. Und so klein ist die wx-Untermenge gar nicht, es geht also. Trotzdem ziehe ich persönlich Qt vor, auch wenn in meinem Umfeld viele mit fltk arbeiten, was ich gar nicht mag/ausstehen kann.
> Es gibt für wx einen Patch, der es gegen Qt statt gtk baut.
Wie sieht es mit der Performance aus?
> Und so klein ist die wx-Untermenge gar nicht, es geht also.
Naja, da fehlt dann sicherlich die komplette Datenbankanbindung, die Qt bietet, dafür hat wxWidgets eine eigene, die aber vermutlich nicht gerade kompatibel ist usw.
> [...] auch wenn in meinem Umfeld viele mit fltk arbeiten [...]
Ob das so eine gute Idee ist? Wie sieht es bei fltk mit Barrierefreiheit und Internationalisierung aus? Unterstützt es Themes? Und wenn ja, wie?
Ohne diese Dinge geht heutzutage nicht mehr viel, allein schon wenn man daran denkt, dass Behörden überhaupt keine Software benutzen dürfen, die nicht barrierefrei ist.
wonach es dir belibt ist scheinbar eine Toolkit unabhängige Beschreibungssprache der Oberfläche, sammt Interpreter (der dann auf entsprechenden Libs setzt). Mit dem eigentlichen Programm würden dann nurnoch Signale und Daten ausgetauscht. Ein Schritt in die Richtung ist XUL oder die Gladelib (es gibt auch noch eine Reihe anderer Ansätze). Jedch seckt das alles noch in den Kinderschuhen.
Stephan schrieb: Die erste Frage die sich stellt was nehme ich denn zum programieren: QT, GTK, wxWidgets oder doch was anderes? [...] Vorallem ist das Problem, dass man sich erst mal eine Weile rein arbeiten muss und wenn man dann aufs falsche Pferd gesetzt hat, darf man wieder bei Null beginnen.
Ist zwar etwas OT, aber egel: Meinesachtens ist das nur von geringer Relevanz. Ich hab mir dazu mal einen kleine Statistik zusammengezimmert. Danach hängen unter Debian von allen Paketen, die von einem Toolkit (ohne wxWidgets oder Java-basierte Pakete) abhängen, rund 50% von GTK ab; dann folgt QT mit rund 25% und danach der ganze Rest.
Zudem ist beispielsweise GTK ist über verschiedene Sprachen hinweg wiederzuerkennen und hängt von seiner Gestaltung nicht zwingend von GNOME ab. Anders ausgedrückt: Alle Bindings, die auf GTK oder QT aufbauen, dürften hinreichend zukunftssicher sein.
Solange Du also nicht anfängst, Motif oder Lesstif zu lernen...
Bisher habe ich nur etwas von Entwicklern gellesen. Leider! Hat schon mal jemand an den Anwender gedacht? Heist das etwa, das die Installation von Software demnächst mit einem Mausklick erledigt ist??? Egal welchse Distribution oder welchse Softwarepaket ich habe, alles läuft überall? Das ist bisher meiner Meinung nach der eigentliche Grund, warum sich linux nicht im Endnutzerbereich durchgesetzt hat! ... Keine einfache Installation, keinen Nachfrage. Keine Nachfrage, keine Entwicklung. Keine Entwicklung ...
> Heist das etwa, das die Installation von Software demnächst > mit einem Mausklick erledigt ist???
Nein, das heißt es nicht - kann es aber begünstigen. Die LSB entwickelt keinen Mechanismus zur Softwareinstallation. Die LSB entwirft nur eine Laufzeitumgebung, die externe Software auf jedem System, das als kompatibel zur jeweiligen LSB-Version zertifiziert wurde, vorfinden wird.
Dazu gehört keine Software, die die Installation von Paketen per Mausklick ermöglicht. Sehr wohl gehört dazu aber die Tatsache, dass Softwarepakete in einem bestimmten Format vorliegen sollen und die Präsenz anderer Pakete voraussetzen können.
Mehr legt die LSB nicht fest und mehr braucht die LSB auch gar nicht festzulegen, denn was die Distributoren daraus machen, bleibt ihnen überlassen. Jede Distribution kann sich also überlegen, ein nettes grafisches Programm zu entwickeln und auszuliefern, das im Dateimanager mit Dateien des Typs "RPM" verknüpft ist und beim Anklicken eines RPMs aufgeht, nette Fragen stellt, an definierten Orten nach den Abhängigkeiten sucht usw.
> Egal welchse Distribution oder welchse Softwarepaket ich > habe, alles läuft überall?
Auch das stimmt nicht zwangsläufig. Man kann weiterhin nicht einfach Software auf einem x-beliebigen System mit einem x-beliebigen GCC kompilieren und davon ausgehen, dass sie dann überall läuft. Stattdessen muss man die Spezifikation lesen, genau anschauen, was die zu verpackende Software zur Laufzeit braucht und alles, was sie zur Laufzeit braucht und nicht Teil der LSB-Spezifikation ist, mit ins Paket packen, dann klappt das auch - aber nicht von selbst.
Ein Missverständnis muss man bei der Frage auch immer ausräumen: Nein, es wird auch weiterhin nicht möglich sein, Pakete vom Fedora-Server zu nehmen und auf einem SuSE-System zu benutzen. Was die LSB festlegt, richtet sich an Dritthersteller. Die eigenen Pakete der Distributoren müssen selbst nicht LSB-konform sein und können es meistens auch gar nicht, sondern sie müssen in ihrer Gesamtheit eine LSB-Umgebung bereitstellen, auf der LSB-konforme Pakete dann laufen werden.
Die LSB ermöglicht es, den Entwicklern eine Umgebung zur Verfügung zu stellen auf der sie aufbauen können. Die meisten Distributionen werden ein LSB Packet machen, das heisst, jemand der Software verteilt braucht, falls er für mehrere Distributionen was macht, sein RPM oder DEB nur mehr vom jeweiligen LSB-Packet der jeweiligen Distribution abhängig machen. Oder wenn er einen eigenen Installer mitbringt muß nur die Warnung "Achtung, das Paket LSB muß installiert sein" ausgespuckt werden, und man braucht nicht für jede Distri ein eigenes Packet bauen.
Standards sind ja schön und gut, sie müssten nur umsetzbar sein. Es wäre nur wesentlich einfacher, sich auf einige APIs zu einigen. Es gibt auch genügend Beispiel, wo das klappt: glibc, gcc, zlib, x11, cups, sane, sdl, dbus
Ich wünschte mir, die hier gehörten dazu: gtk, gstreamer, khtml, (dpkg)
ist zu 95% off topic, aber vielleicht weiss ja jemand wie ich das den default prefix beim configure script verändern kann. sprich dauerhaft auf "/usr" umstellen. "/usr/local" ist leider sehr schlecht untersützt. (desktop integration etc). vielleicht gibts ja ne enviromental variable.
Definiere dir doch in der .bashrc ein alias (sofern du denn die Bash benutzt:-) ): Der einzige Unterschied wäre bei diesem Beispiel, dass du anstatt "./configure" nun "configure" eintippern müsstest :-)
So sieht es bei mir z.B. aus: alias configure='./configure --x-includes=/usr/X11R6/include/X11 --x-libraries=/usr/X11R6/lib --prefix=/usr'
Bei dir hieße das dann: alias configure='./configure --prefix=/usr'
Ich kompiliere z.B. KOffice immer nach /usr/local und hatte noch nie irgendwelche Probleme damit. Auch bei anderen KDE-Programmen hat das bei mir immer funktioniert. Mit was hattest du denn da Probleme? Programme nach /usr zu installieren ist eine sehr schlechte Idee, da man da leicht mit der Paketverwaltung der Distribution Probleme bekommen kann.
Das scheint dann ein Gnome-spezifisches Problem zu sein. KDE Programme lassen sich bei mir unter Debian SID voellig problemlos nach /usr/local installieren (Gnome benutze ich nicht).
Von Kevin Krammer am Mi, 19. Oktober 2005 um 17:48 #
Würde mich stark wundern, wenn das nicht anpassbar ist.
Die Pfade in denen .desktop Files für die Applikationsmenüs gesucht werden sind definitiv über Umgebungsvariablen setzbar XDG_DATA_DIRS oder so ähnlich.
Dann ist deine Distribution falsch konfiguriert. Füg in der Datei /etc/ld.so.conf eine Zeile mit der Verzeichnisangabe /usr/local/lib hinzu. Dann findet ld die Libs in diesem Verzeichnis auch.
Jede Distribution, die den Benutzer nicht bevormunden will, d.h. ihm nicht die Fähigkeit zur Installation von Software aus dem Quellcode absprechen will, hat die Zeile bereits in der /etc/ld.so.conf drin.
Von Sascha Morr am Mi, 19. Oktober 2005 um 10:28 #
Hallo,
kann es sein das man den falschen Ansatz gewählt hat? Wäre es nicht sinnvoller eine Metadistribution (nennen wir sie mal Linuxbase) mit einen halbjährlichen Release zu schaffen auf der dann die anderen Distributionen aufsetzen? Aufsetzen würde in dem Fall bedeuten das sie die Oberfläche enstprechend anpassen etc, eben das Look & Feel. Natürlich wäre eine einheitliche Grafische Oberfläche noch besser aber das halte ich für nicht praktikabel, zu verhärtet sind die Fronten.
Die Vorteile wären eine einheitliche File Hierachie, ein einheitliches Paketsystem etc. Und Entwickler müßten ihre Programme und Pakete nur noch mit der jeweiligen Version der Metadistribution testen, sprich würde ich Redhat XYZ kaufen und darauf würde stehen *Kompatibel zu Linuxbase 2* und ich würde mir ein Programm kaufen/herunterladen bei dem auch *Kompatibel zu Linuxbase 2* angegeben ist und meine Systemvoraussetzungen stimmen ist es einfach zu installieren und läuft einfach so. Das selbe mit anderen auf dieser Metadistribution basierenden Distributionen.
IMHO wäre dieser Ansatz wesentlich erfolgsversprechender.
Halte ich nicht für realistisch. Ein solcher Ansatz würde nicht das Problem beheben, dass ein Binary, gebaut für "Linuxbase vom Okt. 2005", (wahrscheinlich) nicht mehr auf "Linuxbase vom Okt. 2006" läuft.
Davon abgesehen kann ich mir nicht vorstellen, dass die Debianer ihre Heilige Kuh "apt" schlachten oder RH, SuSE etc. RPM über Bord werfen.
Von Sascha Morr am Mi, 19. Oktober 2005 um 11:10 #
Hm inwiefern es realistisch ist sei dahin gestellt, es wäre eben der in meinen Augen beste Weg. Außerdem geht es nicht darum das ein Programm das 1999 gebaut wurde auch noch 2005 läuft, dazu ist die Entwicklung einfach zu schnell. Aber es würde bedeuten das wen ein Entwickler Pakete die kompatibel zu Linuxbase 4 sind diese Pakete eben auf allen Distributionen die auf dieser Linuxbase 4 basieren problemlos laufen. Das er das Paket dann eben für die verschiedenen Linuxbase Versionen neu kompilieren muß ist wiederum was anderes, dürfte aber bei weitem nicht den Aufwand bringen als wen man es für X verschiedene Distributionen in X verschiedenen Versionen machen müßte.
Das mit den Paketformaten ist in der Tat so eine Sache. Ich persönlich bin ein absoluter Beführworter von dpkg & apt aber das mögen andere anders sehen zumal es mit dahingehend ja mit yum und apt4rpm einiges an interessanten Entwicklungen gibt.
> Außerdem geht es nicht darum das ein Programm das 1999 gebaut wurde auch noch 2005 läuft
Wieso geht es nicht darum? Wenn jemand für eine größere Summe Geldes sich eine bestimmte Software gekauft hat, so wird er diese wahrscheinlich nicht nur ein oder zwei Jahre nutzen wollen. Und siehe da, bei einem hier unbeliebten Mitbewerber ist dies in 99% der Fälle möglich.
> Aber es würde bedeuten das wen ein Entwickler Pakete die kompatibel zu Linuxbase 4 > sind diese Pakete eben auf allen Distributionen die auf dieser Linuxbase 4 > basieren problemlos laufen.
Und? Wenn ein Entwickler ein Programm für Windows anbietet, kann er davon ausgehen, dass es bei >90% der Kunden funktioniert. Je nach Softwareanforderung bis hinab zu W95. Mit einem einzigen Binary wohlgemerkt.
Wenn ein Entwickler für "Linuxbase" entwickelt, muss er ja doch wieder mehrere Binaries bereitstellen, da er nicht davon ausgehen kann, dass alle Kunden immer schön ihr Linuxsystem halbjährlich upgraden. Aber insofern hast Du Recht. Es wäre ein großer Fortschritt im Vergleich zu den heutigen Zuständen.
> Paketformate
Das ist die Crux der OpenSource-Welt. Zwei Entwickler in einem Raum und drei Meinungen. Und niemand, der die Macht hat, eine Lösung durchzusetzen.
Wieso geht es nicht darum? Wenn jemand für eine größere Summe Geldes sich eine bestimmte Software gekauft hat, so wird er diese wahrscheinlich nicht nur ein oder zwei Jahre nutzen wollen. Und siehe da, bei einem hier unbeliebten Mitbewerber ist dies in 99% der Fälle möglich
Es ist aus mehrerlei Gründen nicht möglich. Zum einen weil eben diese dauernde Abwärtskompatibilität einer der größten Fehlerquellen bei Windows war und ist (frag Dich mal warum Windows XP kein DOS mehr unterstützt) und zum anderen weil bei Linux und Unix sehr stark auf Gemeinsame Komponenten gesetzt wird. Sprich eine Bibiothek wird nur einmal installiert und dann überall verwendet (Ja ich weis das es bei Windows inzwischen ähnliche Wege gibt). Klar wäre es mir lieber wen auch ein uralt Programm ohne neukompilirung noch auf nem topmodernen System laufen würde. Jedoch würde das entweder voraussetzen das die ganzen Komponenten abwärtskompatibel sind oder das das Programm alles an Komponenten was es braucht selbst mitbringt.
Und? Wenn ein Entwickler ein Programm für Windows anbietet, kann er davon ausgehen, dass es bei >90% der Kunden funktioniert. Je nach Softwareanforderung bis hinab zu W95. Mit einem einzigen Binary wohlgemerkt.
Oh kann er das? Ich frage nur weil ich ob der viel gerühmten Abwärtskompatibilität schon sehr oft erlebt habe das es eben nicht so ist.
Wenn ein Entwickler für "Linuxbase" entwickelt, muss er ja doch wieder mehrere Binaries bereitstellen, da er nicht davon ausgehen kann, dass alle Kunden immer schön ihr Linuxsystem halbjährlich upgraden. Aber insofern hast Du Recht. Es wäre ein großer Fortschritt im Vergleich zu den heutigen Zuständen.
Nun es wäre imho kein problem das selbe Paket auf verschiedenen Versionen der Linuxbase zu kompilieren. Sicher optimal wäre wen es da keine Abhängigkeiten gäbe aber ich sehe keinen Weg dorthin.
> Paketformate
Das ist die Crux der OpenSource-Welt. Zwei Entwickler in einem Raum und drei Meinungen. Und niemand, der die Macht hat, eine Lösung durchzusetzen.
Naja wohin die *Macht* führt kann man täglich bei dem Mist sehen den Microsoft mit seiner Quasimonopolstellung durchgesetzt hat...
»frag Dich mal warum Windows XP kein DOS mehr unterstützt«
Also Abwärtskompatiblität mag Probleme verursachen, aber DOS ist eine Baustelle für sich. Theoretisch hätte man die DOS VM besser realiseren können (siehe OS/2), aber ich bezweifle, dass sich dieser Aufwand wirklich gelohnt hätte. Mit AMD64 (oder wie man es auch immer nennen will) hat sich der v86er modus sowieso erledigt (zumindest ist er im long mode nichtmehr ohne weiteres nutzbar).
»Oh kann er das? Ich frage nur weil ich ob der viel gerühmten Abwärtskompatibilität schon sehr oft erlebt habe das es eben nicht so ist.«
Die ABI der win32 api ist größtenteils gleich geblieben. Dennoch verhalten sich unterschiedliche Versionen nicht identisch, was in einigen Fällen zu Problemen kommen kann. Allerdings gibt es unter Windows auch einen Haufen ABI inkompatibler Bibliotheksversionen, die entweder parallel installiert werden müssen bzw viele Programme liefern ihre DLLs gleich mit damit es nicht kracht.
Einer der größten Probleme unter win ist, dass viele (vorallem ältere) Programme nicht mit unterschiedlichen Nutzern (bzw nutzerverzeichnisen) umgehen können und sich somit nur mit Adminrechten richtig nutzen lassen. Das ist wohl auch einer der Gründe warum die Home Edition kaum gebrauch von Nutzerrechten macht, worunter auch die Nutzer leiden. Man stelle sich nurmal vor, ein normaler Nutzer kann sein DFÜ Netzwerk nichtmehr ohne zusätzliche Authentifikation einrichten. Wäre zwar der Schrecken jedes Dialeranbieters und technisch für Windows auch kein Problem, aber die Abwärtkompatiblität und die "Benutzerfreundlichkeit" verbieten sowas leider bei der Standardinstallation für 0815 Nutzer.
> Zum einen weil eben diese dauernde Abwärtskompatibilität einer der größten > Fehlerquellen bei Windows war und ist (frag Dich mal warum Windows XP > kein DOS mehr unterstützt)
DOS ist ja nun kein sehr gutes Beispiel. W95 erschien vor 10 Jahren. 10 Jahre Abwärtskompatibilität sollten doch halbwegs zufriedenstellen. Ich wär bei Linux mit 5 Jahren zufrieden.
> Jedoch würde das entweder voraussetzen das die ganzen Komponenten abwärtskompatibel sind
Was sind denn die Ursachen, wenn es nicht funktioniert? - Binärinkompatibilität in einer Lib innerhalb einer Majorversion. Theoretisch darf das nicht passieren, praktisch passiert es aber immer wieder - Libs gebaut mit inkompatiblen Buildoptionen, - instabile ABI des gcc
Und das alles sind unlösbare Probleme? Das sehe ich anders. Verschiedene Majorversionen ein und derselben Lib kann man normalerweise problemlos parallel installieren.
Im Übrigen ist Windows nicht das einzige System, das Abwärtskompatibilität sicherstellt. Solaris ist ein gutes weiteres Beispiel.
> weil ich ob der viel gerühmten Abwärtskompatibilität schon sehr oft erlebt habe das es > eben nicht so ist.
Tja, G. W. würde jetzt sagen, dass er nur in Linuxforen liest, dass das nicht funktioniert. Meiner Erfahrung nach funktionieren weit über 90% aller Win-Binaries mindestens ab W98 auf allen Win-Systemen.
> kann man täglich bei dem Mist sehen den Microsoft mit seiner Quasimonopolstellung > durchgesetzt hat...
FUD, oder hast Du da jetzt ein konkretes Beispiel?
Sorry, daß ich erst jetzt anworte, aber ich habe nicht soviel Zeit um regelmäßig ins Interet zu gehen.
Außerdem geht es nicht darum das ein Programm das 1999 gebaut wurde auch noch 2005 läuft,
Bitte? Wodrum dann?
Ich habe DOS, Win3.1 und Win95 Programme, die ich teilweise inzwiswchen fast 15 Jahre lang besitze. Unter Windows XP laufen sie alle noch.
Und was ist bei Linux? Da hatte ich mir 1999 oder 2000 Spiele von Loki-Games gekauft. Z.B. "Civilization: Call to power". Ich wollte es vor kurzem wieder auf SuSE 9.3 spielen. Geht leider nicht. Das Spiel benötigt eine ältere gtk+ Version, die wiederum auf einer älteren glib Version aufbaut.
Hätte ich damals die Windows-Version gekauft, dann hätte ich das Spiel auch heute noch spielen können. Aber ich Depp hatte gedacht, es sei besser Linux irgendwie zu unterstützen, indem ich ein Spiel für Linux kaufen. Hinzu kommt noch, daß das Spiel für Linux teurer war, als die Windows-Version.
Vielleicht hätte ich die Windows-Version auch mit WineX hinterher auf Linux zum Laufen bekommen. Seltsamerweise laufen unter Linux mit Hilfe von Wine/WineX/CrossOver sogar viel ältere Windows-Programme auf Linux als Programme, die extra für Linux kompiliert wurden.
Ich werde jedenfalls kein Closed-Source Programm mehr für Linux kaufen, solange ich nicht zusätzlich die Garantie bekomme, daß es auch auf Distributionen, die in zehn Jahren rauskommen noch laufen.
Ich moechte gern ein Paket bauen das dann auf einer echten Vielzahl von Distributionen lauffaehig ist. Weiter will ich auch in den Paketheader alle Paket-Abhaengigkeiten mit rein bringen, so dass klar ist, was alles gebraucht wird.
Bei Debian geht das ja eigentlich ganz gut, bei RedHat/Fedora/SuSE/Mandriva habe ich damit aber meine Probleme. Zudem muss das Paket auch einige Eintraege in /etc/hotplug machen, und genau hier ist bei SuSE mit jeder Version staendig alles anders und SuSE kuemmert das einen Dreck.
Zudem will ich von SuSE 8.0 bzw. RedHat 8.0 aufwaerts bis zur aktuellen Distribution alles unterstuetzen. Hierzu stelle ich mir ein deb-Paket und ein rpm-Paket vor, das rpm-Paket soll wahlweise auch nich den 64-Bit code enthalten (Fat-Binary?). Bei Windows geht das doch auch, hier kann ich doch auch einen Installer fuer Windows 95 bis zum XP machen.
Kann mir vielleicht jemand einen interessanten Link dazu geben, wie man das erreichen koennte. Auf dem letzten Linux-Tag haben die Leute von Fedora und Novell dazu nur den Kopf geschuettelt und gemeint das wuerde nicht gehen.
Aber wozu ist dann die LSB und freestandards.org gut, wenn dann sowas nicht geht, oder nur fuer Distributionen die etwa alle gleich alt sind?
> Umständen mehrere Varianten ihrer Software pflegen, sofern
> diese nicht quelloffen ist.
Stimmt doch gar nicht. Kann es sein, dass dieser Satz ein wenig tendenziös ist?
Richtig wäre meiner Meinung nach:
"Wird dies nicht erreicht, müssen Anwendungsentwickler unter Umständen mehrere Varianten ihrer Software pflegen, und zwar unabhängig davon, ob diese quelloffen ist oder nicht."
Wenn eine Bibliothek keine stabile API hat, dann erschwert dies _jedem_ Softwarehersteller, der diese Bibliothek benutzen will, die Arbeit und seine Produktivität. Es gilt eben gerade nicht der Satz: "Ist doch OSS, kannst Du doch jederzeit selbst kompilieren und selbst für Dein System zurechtpatchen."
Oder vielleicht gilt der Satz doch, es ist aber definitiv _nicht_ die Absicht, gezielt den Herstellern nicht quelloffener Software entgegenzukommen, sondern es soll eine standardisierte Umgebung für _jedermann_ geschaffen werden. Dass dies auch Software, die nicht quelloffen, einschließt, liegt in der Natur der Sache, ist aber nicht das zentrale Ziel, sondern ein Nebeneffekt.
Es wundert mich ehrlich gesagt, dass auch hier wieder diese Kategorien und Schubladen zum Vorschein kommen, um die es bei der LSB eigentlich überhaupt nicht geht. Auch der Autor einer x-beliebigen quelloffenen Software hat auf der Basis der LSB die Möglichkeit, seine Software für Linux zusätzlich zum Quellcode auch als Binärpaket anzubieten.
Auf der meistgenutzten Desktop-Plattform ist dies auch für quelloffene Software längst üblich und nützlich, unter Linux geht das zur Zeit schwierig und in einigen Fällen überhaupt nicht, genau daran arbeitet jetzt die LSB - nutzen kann die Ergebnisse _jeder_.
> Es wird die GUI-Toolkits standardisieren und sehr
> wahrscheinlich sowohl GTK+ als auch Qt umfassen.
Quellenangabe? Nach meinem Kenntnisstand ist diese Information falsch.
Oder verstehe ich die Andeutung leider richtig und Du meinst doch, dass jeder alles passend zu seinem Problem selbst kompilieren soll? Das ist zumindest der erste Gedanke, den ich bei überflüssigen Belehrungen über den Unterschied zwischen API und ABI habe. Genau das will die LSB doch überflüssig machen.
Lies dir mal den Artikel durch: Es weiß die Unterstützung von zahlreichen Firmen hinter sich, darunter Adobe, IBM, Intel, HP, Linspire, Mandriva, Novell, RealNetworks, Red Hat, Trolltech und Xandros.
Du hast dich sicher verlesen und gedacht, dort würde Ximian stehen. Ximian gehört schon seit langem zu Novell, welche zu den Unterstützerfirmen gehört, genauso wie Red Hat, die voll auf GNOME setzen.
> es ist aber definitiv _nicht_ die Absicht, gezielt den Herstellern nicht quelloffener Software entgegenzukommen, sondern es soll eine standardisierte Umgebung für _jedermann_ geschaffen werden. Dass dies auch Software, die nicht quelloffen, einschließt, liegt in der Natur der Sache, ist aber nicht das zentrale Ziel, sondern ein Nebeneffekt.
Ja,ja, niemand hat die Absicht... (Interessenlage und Hintergedanken werden stets bestritten.)
Verdrehungsrethorik ist doch nich zu übersehen. Freie Software mit Versions- und Distributionswerkzeugen ist nicht von Binärkompatibilität abhängig.
Es muß auch nicht jeder für sich kompilieren. Das ist nicht nötig, der Dezentralisierungsgrad kann nach Bedarf optimal gewählt werden.
Sourcecode kann zentralisiert upgedated werden und dabei nicht unfrei gemacht werden. Binärcode kann, wenn er zentralisiert upgedated wird, auch unfrei gemacht werden.
Von Binärkompatibilität profitieren in erster Linie proprietäre Softwarekopiermodelle. Die Arbeit haben externe Entwickler die die Binärkompatibilität gewährleisten sollen, anstatt sich mit Werkzeugen, die den Sourcecodefluß von upstream auf unterschiedliche Platformen und Distributionen verbessern, das Leben zu erleichtern.
Nebenwirkungen verändern nichts am Hauptzusammenhang.
> gemacht werden. Binärcode kann, wenn er zentralisiert upgedated wird,
> auch unfrei gemacht werden.
Wie gemein, da gibt es doch tatsächlich Leute, die für ihre Arbeit Geld haben wollen. Wie böse ist doch die Welt.
> Von Binärkompatibilität profitieren in erster Linie proprietäre Softwarekopiermodelle.
Nein, davon profitieren alle, denn es macht allen das Leben leichter.
> Die Arbeit haben externe Entwickler die die Binärkompatibilität gewährleisten sollen,
> anstatt sich mit Werkzeugen, die den Sourcecodefluß von upstream auf unterschiedliche
> Platformen und Distributionen verbessern, das Leben zu erleichtern.
Ach ja, man muss sich nur lange genug einreden, dass etwas so ist, wie es zu sein hat.
Es wird mit Sicherheit ein Vielfaches an Arbeit in zig Paket- und Installationssysteme, Binärpakete für > 300 Linuxdistris und noch ein Dutzend Unixe gesteckt als es nötig wäre, durch ein vernünftiges Konzept Binärkompatibilität sicherzustellen. Und das Wichtigste: für den Normalanwender würde Linux auf einmal benutzbar werden. Zumindest in diesem Punkt.
Kopieren macht praktisch keine Arbeit.
Geld soll für den sofortigen oder späteren Empfang von Leistung umlaufen müssen, und nicht für künstliche Knappheiten abgegeben werden müssen.
Wo mehr Geld eingenommen wird als Leistungen bezogen werden sollte es auch nicht so leicht zum Aufbau künstlicher Knappheiten verwendet werden können, weil es an anderer Stelle, zur Aufrechterhaltung der Wirtschaftskreisläufe (der Konkurenz) fehlt. (Zentralisation)
In einer gesättigten Volkswirtschaft werden absolute Gewinne theoretisch immer schwerer.
Die Knappheit macht den Preis. Was wird bei entwickelten Volkswirtschaften mit hoher Produktivität (hier und heute) teurer?
Mit privatisierten natürlichen Monopolen und Monopolrechten künstlich knappgehaltenes?
Arbeitskraft, die nicht mehr die jährliche prozentuale Kapitalrendite erwirtschaften kann?
Produktionsmittel die nicht mehr wegrationalisiert werden (Überkapazitäten)?
Geld und kurzfristige Geldforderungen die liquide gehalten werden können und bei niedrigem Renditenivau und Inflation keinem Angebotsdruck unterliegen?
----
Selbst wenn wirklich durch synchrone ABIs alle profitieren sollten, profitierten proprietäre Softwarekopierer mit der für die Verbreitung Freier Software gar nicht notwendigen Binärkompatibilität mehr.
Und zwar auf Kosten derer, die die Arbeit der Programmierer Freier Software bezahlen.
Nebenwirkungen heben noch immer keinen Hauptzusammenhang auf.
Man merkt, dass Du nur zum Hausgebrauch kopierst. Selbstverständlich macht kopieren Arbeit. Auch das Vorhalten von Kopien, der benötigten Infrastruktur etc. verursacht keineswegs geringe Kosten.
> In einer gesättigten Volkswirtschaft werden absolute Gewinne theoretisch immer schwerer.
PDS-Listenkandidat?
> profitierten proprietäre Softwarekopierer mit der für die Verbreitung Freier Software
> gar nicht notwendigen Binärkompatibilität mehr.
Und das ist ganz schlimm. Auweia, die bösen Closed-Source-Anbieter profitieren mehr davon. Lieber soll es allen schlecht gehen. Doch nicht PDS, die versprachen immerhin Luxus für alle.
> Und zwar auf Kosten derer, die die Arbeit der Programmierer Freier Software bezahlen.
Ja, wer bezahlt denn die Arbeit der OSS-Programmierer?
Entweder die Programmierer selbst, indem sie ihre freizeit opfern oder der Steuerzahler, wenn Angestellte des öffentlichen Dienstes während ihrer Arbeitszeit an OSS arbeiten.
> Nebenwirkungen heben noch immer keinen Hauptzusammenhang auf.
Ideologien scheitern immer an den Gesetzen der Ökonomie.
Das mit Hausgebrauch, dass kann man so vielleicht nicht sagen, wir stimmen darüber überein das kopieren allgemein Arbeit und Kosten macht. Abhängig von der Art und Weise der Methoden und der Medien, aber ebenso unabhängig von dem Erstellungsaufwand "in" der "Software", wie unabhängig vom Marktpreis für die Kopie.
Es liegt einfach nicht im Interesse Freier Software, aber auch nicht der Allgemeinheit Unfreiheit zu fördern oder zu sichern. Und man kann das einfach lassen sobalt man es erkannt hat, da braucht man kein Feindbild und keine Unterwerfung.
Viele Programmierer Freier Software Opfern ihre Zeit damit sie die Softare haben können wie sie sie möchten.
Als Lohnarbeiter werden sie dafür bezahlt, dass sie die Software so anpassen wie es, von dem der dafür bezahlt, gewünscht ist, oder dafür, dass sie Sicherstellen das der Betrieb möglichst störungsfrei aufrechterhalten werden kann. Es macht Sinn sie ggf. auch als Administratoren/Maintainer weiter zu bezahlen wenn gerade alles zur Zufriedenheit funktioniert.
So stellt man sicher das sie bei Bedarf sofort mit hoher Priorität vor Ort zur Verfügung stehen, und sie sich über die Vernetzung mit anderen Programmierern, Administratoren und Nutzern mit geringerer und höherer Erfahrung als sie jeweils selbst kontinuierlich Weiterbilden können.
Dies ist unabhängig davon für wen Freie Software Programmierer arbeiten, es gibt sie in privaten wie im öffentlichen Dienst.
Darüber das es im Bereich des öffentlichen Dienstes heute zu Ineffizienzen kommt, die es erlauben das dort während der Arbeitszeit teils zweckfremde oder gar ganz überflüssige Sachen gemacht werden, brauchen wir uns nicht zu streiten.
Das hat mit dem Staatsmonopol zu tun aber nichts mit Freier Software.
> Nebenwirkungen heben noch immer keinen Hauptzusammenhang auf.
Ideologien scheitern immer an den Gesetzen der Ökonomie.
Dem stimme ich vom ganzen Herzen zu.
Die Ideologie der Wachstumsökonomiker scheitert wiederholt an den Gesetzen der naturwissenschaftlichen Ökonomie.
Man schaue sich mal genauer die *Volkswirtschaflichen* Märchen an. Z.B.:
Sparen baut Staatsschulden ab. Nur private, kapitalgebundene Vorsorge hilft im Alter. Arbeit ist zu teuer.
Dabei ist klar das jeder (Kapital-) Gewinn mit einem (Kapital-) Verlust an anderer Stelle einhergehen muß, die Entropie immer zunimmt, folglich Erhaltungsarbeit nötig ist.
Richtig, aber auch trivial: so lange Softwareentwickler selber auf einer bestimmten Plattform mit Binärpaketen präsent sein wollen, müssen sie Binärpakete pflegen. Das gilt offensichtlich für Entwickler freier und unfreier Software. Aber im Unterschied zu freier Software, deren großer Vorteil bekanntermaßen ist, daß jeder den Quellcode einsehen, modifizieren und kompilieren kann und darf, müssen Entwickler unfreier Software Anpassungen zwecks Plattformkompatibilität selber vornehmen und bleiben auch auf der Erstellung von Binärpaketen hängen. Entwickler unfreier Software können entwicklungsmodellbedingt diesen Aufwand nicht ohne vorherige juristische Absprachen an Dritte abgeben.
Freie Software hingegen wird mit dem Release in die Öffentlichkeit von diesen Lasten befreit und daher findet sich meistens ein Dritter, der diese Aufgaben übernimmt und, wenn nötig, Änderungen zwecks Plattformkompatibilität vornimmt. Aus dieser Perspektive stimmt der Originalsatz zweifelsohne, denn nur Entwickler unfreier Software müssen die Binärpakete unbedingt selber erstellen.
Davon mal abgesehen ist der Satz, den Sie mockieren Teil der Berichterstattung und nicht des LSB-Statements. Ich glaube, daß die Autoren von Pro-Linux meiner Ansicht -- wie oben beschrieben -- folgen und nicht das offensichtliche wiederholen wollten. Hier gilt (oder sollte gelten) das Prinzip der Benevolenz.
>>Quellenangabe? Nach meinem Kenntnisstand ist diese Information falsch.<<
Das verlinkte Wiki zeigt die LibQT im Ratifizierungsprozeß. Dieser scheint so weit fortgeschritten, daß die Wikiautoren sicher sind, daß die LibQT Teil der ersten Runde sein wird.
Die Probleme mit dem Aussehen von GTK Programmen unter KDE und QT unter Gnome sind ja bekannt.
Vorallem ist das Problem, dass man sich erst mal eine Weile rein arbeiten muss und wenn man dann aufs falsche Pferd gesetzt hat, darf man wieder bei Null beginnen.
Vom Kompfort der Entwicklungs Umgebungen mal ganz zu schweigen. Etwas das wirklich an Sachen wie Visual Studio, Borland C++ Builder und ähnliche Sachen ran kommt und sowohl unter Linux als auch unter Windows verfügbar ist hab ich bisher noch nicht gefunden. Eclipse ist zwar schon ganz gut, aber 100% kann es noch nicht mithalten bei den Graphischen Sachen.
Was wirklich sinnvoll wäre um diese Probleme, die sicher auch genug professionelle Programierer haben zu lösen wären vereinheitlichungen bei dem Graphik Frame Works wie QT, GTK usw.
Bei der Objekt Orientierten Programmierung gibt es doch alles was man braucht: Vererbung, Geheiniss Prinzip usw.
Was spricht dagegen sich bei den wesentlichen Elementen wie Formular, Label, Edit , Button usw. auf standardisierte Bezeichnungen zu einigen.
Also praktisch werden von den vorhandenen Klassen von QT noch mal Klassen abgeleitet, die Standard bezeichnungen haben
Also statt auf einen qtButton oder GTKButton nehme ich einen Standard-Button und gebe dann beim kompilieren an wo gegen ich linken will. Schon kann ich mit einem Code, der sich an den Standard beschränkt jeder Zeit eine QT oder GTK Anwendung machen und habe eine Version die unter Gnome und eine zweite die unter KDE gut aussieht.
Vorallem kann als Programmierer beim wechsel der Bibliothek vieles machen wie bisher und muss nur bei den Zusatzsachen etwas umlernen. Also man kann so zusagen neben dem Code auch einen großen Teil der Erfahrung weiter nutzen und muss nicht alles neu lernen.
Sowas kombiniert mit guten Plattform unabhängigen Tools für die Entwicklung und schon klappt es mit den Anwendungen für Linux.
Aber darum geht es bei LSB ansich nicht, sondern um die Sicherheit für Softwarehersteller (alle, nicht nur Firmen) daß Bibliothek mit bestimmen API und ABI Versionen vorhanden sind.
Es erleichtert also weniger die Entwicklung, sondern die Verteilung/Installation.
Wenn du deine Wünsche einbringen willst, solltest du es bei der FSG versuchen. Feedback und Peer Review wird es dort genug geben.
:)
Was die unterschiedlichen Grafik-Toolkits angeht: Man meint immer, dies sei ein Linux-spezifisches Problem, ist es aber gar nicht. Auch auf anderen Plattformen muss man sich entscheiden. Da fällt die Entscheidung oft leichter, weil die Hersteller der jeweiligen Plattform ein eigenes haben, das in der Folge dann auch überwiegend benutzt wird, aber entscheiden muss man sich immer, und man muss auch damit leben, dass man, wenn man sich mal entschieden hat, nicht ohne umfangreichere Portierung wechseln kann.
Was den Vorschlag eines Wrappers für die beiden meistbenutzen GUI-Toolkits angeht: Den Vorschlag verstehe ich nicht ganz - was soll das denn bringen? Die beiden Alternativen haben einen unterschiedlichen Umfang, so dass ein Wrapper, der beide abdeckt, nur eine Untermenge der beiden sein könnte und außerdem wäre so ein Wrapper wahrscheinlich sowieso schlechter als die Originale, was die Performance, die Qualität der API usw. angeht. Entscheide Dich einfach, auf anderen Plattformen hättest Du Dich auch entscheiden müssen.
Wie sieht es mit der Performance aus?
> Und so klein ist die wx-Untermenge gar nicht, es geht also.
Naja, da fehlt dann sicherlich die komplette Datenbankanbindung, die Qt bietet, dafür hat wxWidgets eine eigene, die aber vermutlich nicht gerade kompatibel ist usw.
> [...] auch wenn in meinem Umfeld viele mit fltk arbeiten [...]
Ob das so eine gute Idee ist? Wie sieht es bei fltk mit Barrierefreiheit und Internationalisierung aus? Unterstützt es Themes? Und wenn ja, wie?
Ohne diese Dinge geht heutzutage nicht mehr viel, allein schon wenn man daran denkt, dass Behörden überhaupt keine Software benutzen dürfen, die nicht barrierefrei ist.
Ist zwar etwas OT, aber egel: Meinesachtens ist das nur von geringer Relevanz. Ich hab mir dazu mal einen kleine Statistik zusammengezimmert. Danach hängen unter Debian von allen Paketen, die von einem Toolkit (ohne wxWidgets oder Java-basierte Pakete) abhängen, rund 50% von GTK ab; dann folgt QT mit rund 25% und danach der ganze Rest.
Zudem ist beispielsweise GTK ist über verschiedene Sprachen hinweg wiederzuerkennen und hängt von seiner Gestaltung nicht zwingend von GNOME ab. Anders ausgedrückt: Alle Bindings, die auf GTK oder QT aufbauen, dürften hinreichend zukunftssicher sein.
Solange Du also nicht anfängst, Motif oder Lesstif zu lernen...
Das ist bisher meiner Meinung nach der eigentliche Grund, warum sich linux nicht im Endnutzerbereich durchgesetzt hat!
... Keine einfache Installation, keinen Nachfrage. Keine Nachfrage, keine Entwicklung. Keine Entwicklung ...
Das liegt daran, daß es sich dabei um etwas handelt, was sich primär an Entwickler richtet.
Egal welchse Distribution oder welchse Softwarepaket ich habe, alles läuft überall
LSB begünstigt das in dem es eben eine definierte Basis festlegt, auf die sich ein Hersteller dann verlassen kann.
> mit einem Mausklick erledigt ist???
Nein, das heißt es nicht - kann es aber begünstigen. Die LSB entwickelt keinen Mechanismus zur Softwareinstallation. Die LSB entwirft nur eine Laufzeitumgebung, die externe Software auf jedem System, das als kompatibel zur jeweiligen LSB-Version zertifiziert wurde, vorfinden wird.
Dazu gehört keine Software, die die Installation von Paketen per Mausklick ermöglicht. Sehr wohl gehört dazu aber die Tatsache, dass Softwarepakete in einem bestimmten Format vorliegen sollen und die Präsenz anderer Pakete voraussetzen können.
Mehr legt die LSB nicht fest und mehr braucht die LSB auch gar nicht festzulegen, denn was die Distributoren daraus machen, bleibt ihnen überlassen. Jede Distribution kann sich also überlegen, ein nettes grafisches Programm zu entwickeln und auszuliefern, das im Dateimanager mit Dateien des Typs "RPM" verknüpft ist und beim Anklicken eines RPMs aufgeht, nette Fragen stellt, an definierten Orten nach den Abhängigkeiten sucht usw.
> Egal welchse Distribution oder welchse Softwarepaket ich
> habe, alles läuft überall?
Auch das stimmt nicht zwangsläufig. Man kann weiterhin nicht einfach Software auf einem x-beliebigen System mit einem x-beliebigen GCC kompilieren und davon ausgehen, dass sie dann überall läuft. Stattdessen muss man die Spezifikation lesen, genau anschauen, was die zu verpackende Software zur Laufzeit braucht und alles, was sie zur Laufzeit braucht und nicht Teil der LSB-Spezifikation ist, mit ins Paket packen, dann klappt das auch - aber nicht von selbst.
Ein Missverständnis muss man bei der Frage auch immer ausräumen: Nein, es wird auch weiterhin nicht möglich sein, Pakete vom Fedora-Server zu nehmen und auf einem SuSE-System zu benutzen. Was die LSB festlegt, richtet sich an Dritthersteller. Die eigenen Pakete der Distributoren müssen selbst nicht LSB-konform sein und können es meistens auch gar nicht, sondern sie müssen in ihrer Gesamtheit eine LSB-Umgebung bereitstellen, auf der LSB-konforme Pakete dann laufen werden.
http://www.pro-linux.de/news/2005/8770.html
glibc, gcc, zlib, x11, cups, sane, sdl, dbus
Ich wünschte mir, die hier gehörten dazu:
gtk, gstreamer, khtml, (dpkg)
G.W. hat dazu ein gutes Posting im ersten Thread.
gruss pulp
Der einzige Unterschied wäre bei diesem Beispiel, dass du anstatt "./configure" nun "configure" eintippern müsstest :-)
So sieht es bei mir z.B. aus:
alias configure='./configure --x-includes=/usr/X11R6/include/X11 --x-libraries=/usr/X11R6/lib --prefix=/usr'
Bei dir hieße das dann:
alias configure='./configure --prefix=/usr'
Was anderes fällt mir jetzt nicht ein.
Die Pfade in denen .desktop Files für die Applikationsmenüs gesucht werden sind definitiv über Umgebungsvariablen setzbar XDG_DATA_DIRS oder so ähnlich.
Füg in der Datei /etc/ld.so.conf eine Zeile mit der Verzeichnisangabe /usr/local/lib hinzu. Dann findet ld die Libs in diesem Verzeichnis auch.
Jede Distribution, die den Benutzer nicht bevormunden will, d.h. ihm nicht die Fähigkeit zur Installation von Software aus dem Quellcode absprechen will, hat die Zeile bereits in der /etc/ld.so.conf drin.
kann es sein das man den falschen Ansatz gewählt hat? Wäre es nicht sinnvoller eine Metadistribution (nennen wir sie mal Linuxbase) mit einen halbjährlichen Release zu schaffen auf der dann die anderen Distributionen aufsetzen? Aufsetzen würde in dem Fall bedeuten das sie die Oberfläche enstprechend anpassen etc, eben das Look & Feel. Natürlich wäre eine einheitliche Grafische Oberfläche noch besser aber das halte ich für nicht praktikabel, zu verhärtet sind die Fronten.
Die Vorteile wären eine einheitliche File Hierachie, ein einheitliches Paketsystem etc. Und Entwickler müßten ihre Programme und Pakete nur noch mit der jeweiligen Version der Metadistribution testen, sprich würde ich Redhat XYZ kaufen und darauf würde stehen *Kompatibel zu Linuxbase 2* und ich würde mir ein Programm kaufen/herunterladen bei dem auch *Kompatibel zu Linuxbase 2* angegeben ist und meine Systemvoraussetzungen stimmen ist es einfach zu installieren und läuft einfach so. Das selbe mit anderen auf dieser Metadistribution basierenden Distributionen.
IMHO wäre dieser Ansatz wesentlich erfolgsversprechender.
Grüße
Sascha
Davon abgesehen kann ich mir nicht vorstellen, dass die Debianer ihre Heilige Kuh "apt" schlachten oder RH, SuSE etc. RPM über Bord werfen.
Das mit den Paketformaten ist in der Tat so eine Sache. Ich persönlich bin ein absoluter Beführworter von dpkg & apt aber das mögen andere anders sehen zumal es mit dahingehend ja mit yum und apt4rpm einiges an interessanten Entwicklungen gibt.
Grüße
Sascha
Ist aber eben die Frage, inwiefern etwas nicht realistisch umsetztbares überhaupt eine Lösung darstellt.
Der LSB Vorschlag mag vielleicht nicht optimal sein, aber er ist umsetzbar.
Grüße
Sascha
Wieso geht es nicht darum?
Wenn jemand für eine größere Summe Geldes sich eine bestimmte Software gekauft hat, so wird er diese wahrscheinlich nicht nur ein oder zwei Jahre nutzen wollen. Und siehe da, bei einem hier unbeliebten Mitbewerber ist dies in 99% der Fälle möglich.
> Aber es würde bedeuten das wen ein Entwickler Pakete die kompatibel zu Linuxbase 4
> sind diese Pakete eben auf allen Distributionen die auf dieser Linuxbase 4
> basieren problemlos laufen.
Und?
Wenn ein Entwickler ein Programm für Windows anbietet, kann er davon ausgehen, dass es bei >90% der Kunden funktioniert. Je nach Softwareanforderung bis hinab zu W95. Mit einem einzigen Binary wohlgemerkt.
Wenn ein Entwickler für "Linuxbase" entwickelt, muss er ja doch wieder mehrere Binaries bereitstellen, da er nicht davon ausgehen kann, dass alle Kunden immer schön ihr Linuxsystem halbjährlich upgraden. Aber insofern hast Du Recht. Es wäre ein großer Fortschritt im Vergleich zu den heutigen Zuständen.
> Paketformate
Das ist die Crux der OpenSource-Welt. Zwei Entwickler in einem Raum und drei Meinungen. Und niemand, der die Macht hat, eine Lösung durchzusetzen.
Grüße, Smeik
Wenn jemand für eine größere Summe Geldes sich eine bestimmte Software gekauft hat, so wird er diese wahrscheinlich nicht nur ein oder zwei Jahre nutzen wollen. Und siehe da, bei einem hier unbeliebten Mitbewerber ist dies in 99% der Fälle möglich
Es ist aus mehrerlei Gründen nicht möglich. Zum einen weil eben diese dauernde Abwärtskompatibilität einer der größten Fehlerquellen bei Windows war und ist (frag Dich mal warum Windows XP kein DOS mehr unterstützt) und zum anderen weil bei Linux und Unix sehr stark auf Gemeinsame Komponenten gesetzt wird. Sprich eine Bibiothek wird nur einmal installiert und dann überall verwendet (Ja ich weis das es bei Windows inzwischen ähnliche Wege gibt). Klar wäre es mir lieber wen auch ein uralt Programm ohne neukompilirung noch auf nem topmodernen System laufen würde. Jedoch würde das entweder voraussetzen das die ganzen Komponenten abwärtskompatibel sind oder das das Programm alles an Komponenten was es braucht selbst mitbringt.
Und?
Wenn ein Entwickler ein Programm für Windows anbietet, kann er davon ausgehen, dass es bei >90% der Kunden funktioniert. Je nach Softwareanforderung bis hinab zu W95. Mit einem einzigen Binary wohlgemerkt.
Oh kann er das? Ich frage nur weil ich ob der viel gerühmten Abwärtskompatibilität schon sehr oft erlebt habe das es eben nicht so ist.
Wenn ein Entwickler für "Linuxbase" entwickelt, muss er ja doch wieder mehrere Binaries bereitstellen, da er nicht davon ausgehen kann, dass alle Kunden immer schön ihr Linuxsystem halbjährlich upgraden. Aber insofern hast Du Recht. Es wäre ein großer Fortschritt im Vergleich zu den heutigen Zuständen.
Nun es wäre imho kein problem das selbe Paket auf verschiedenen Versionen der Linuxbase zu kompilieren. Sicher optimal wäre wen es da keine Abhängigkeiten gäbe aber ich sehe keinen Weg dorthin.
> Paketformate
Das ist die Crux der OpenSource-Welt. Zwei Entwickler in einem Raum und drei Meinungen. Und niemand, der die Macht hat, eine Lösung durchzusetzen.
Naja wohin die *Macht* führt kann man täglich bei dem Mist sehen den Microsoft mit seiner Quasimonopolstellung durchgesetzt hat...
Grüße
Sascha
Also Abwärtskompatiblität mag Probleme verursachen, aber DOS ist eine Baustelle für sich.
Theoretisch hätte man die DOS VM besser realiseren können (siehe OS/2), aber ich bezweifle, dass sich dieser Aufwand wirklich gelohnt hätte.
Mit AMD64 (oder wie man es auch immer nennen will) hat sich der v86er modus sowieso erledigt (zumindest ist er im long mode nichtmehr ohne weiteres nutzbar).
»Oh kann er das? Ich frage nur weil ich ob der viel gerühmten Abwärtskompatibilität schon sehr oft erlebt habe das es eben nicht so ist.«
Die ABI der win32 api ist größtenteils gleich geblieben.
Dennoch verhalten sich unterschiedliche Versionen nicht identisch, was in einigen Fällen zu Problemen kommen kann.
Allerdings gibt es unter Windows auch einen Haufen ABI inkompatibler Bibliotheksversionen, die entweder parallel installiert werden müssen bzw viele Programme liefern ihre DLLs gleich mit damit es nicht kracht.
Einer der größten Probleme unter win ist, dass viele (vorallem ältere) Programme nicht mit unterschiedlichen Nutzern (bzw nutzerverzeichnisen) umgehen können und sich somit nur mit Adminrechten richtig nutzen lassen.
Das ist wohl auch einer der Gründe warum die Home Edition kaum gebrauch von Nutzerrechten macht, worunter auch die Nutzer leiden.
Man stelle sich nurmal vor, ein normaler Nutzer kann sein DFÜ Netzwerk nichtmehr ohne zusätzliche Authentifikation einrichten. Wäre zwar der Schrecken jedes Dialeranbieters und technisch für Windows auch kein Problem, aber die Abwärtkompatiblität und die "Benutzerfreundlichkeit" verbieten sowas leider bei der Standardinstallation für 0815 Nutzer.
> Fehlerquellen bei Windows war und ist (frag Dich mal warum Windows XP
> kein DOS mehr unterstützt)
DOS ist ja nun kein sehr gutes Beispiel. W95 erschien vor 10 Jahren. 10 Jahre Abwärtskompatibilität sollten doch halbwegs zufriedenstellen. Ich wär bei Linux mit 5 Jahren zufrieden.
> Jedoch würde das entweder voraussetzen das die ganzen Komponenten abwärtskompatibel sind
Was sind denn die Ursachen, wenn es nicht funktioniert?
- Binärinkompatibilität in einer Lib innerhalb einer Majorversion. Theoretisch darf das nicht passieren, praktisch passiert es aber immer wieder
- Libs gebaut mit inkompatiblen Buildoptionen,
- instabile ABI des gcc
Und das alles sind unlösbare Probleme? Das sehe ich anders. Verschiedene Majorversionen ein und derselben Lib kann man normalerweise problemlos parallel installieren.
Im Übrigen ist Windows nicht das einzige System, das Abwärtskompatibilität sicherstellt. Solaris ist ein gutes weiteres Beispiel.
> weil ich ob der viel gerühmten Abwärtskompatibilität schon sehr oft erlebt habe das es
> eben nicht so ist.
Tja, G. W. würde jetzt sagen, dass er nur in Linuxforen liest, dass das nicht funktioniert. Meiner Erfahrung nach funktionieren weit über 90% aller Win-Binaries mindestens ab W98 auf allen Win-Systemen.
> kann man täglich bei dem Mist sehen den Microsoft mit seiner Quasimonopolstellung
> durchgesetzt hat...
FUD, oder hast Du da jetzt ein konkretes Beispiel?
Grüße, Smeik
Außerdem geht es nicht darum das ein Programm das 1999 gebaut wurde auch noch 2005 läuft,
Bitte? Wodrum dann?
Ich habe DOS, Win3.1 und Win95 Programme, die ich teilweise inzwiswchen fast 15 Jahre lang besitze. Unter Windows XP laufen sie alle noch.
Und was ist bei Linux? Da hatte ich mir 1999 oder 2000 Spiele von Loki-Games gekauft.
Z.B. "Civilization: Call to power".
Ich wollte es vor kurzem wieder auf SuSE 9.3 spielen. Geht leider nicht.
Das Spiel benötigt eine ältere gtk+ Version, die wiederum auf einer älteren glib Version aufbaut.
Hätte ich damals die Windows-Version gekauft, dann hätte ich das Spiel auch heute noch spielen können. Aber ich Depp hatte gedacht, es sei besser Linux irgendwie zu unterstützen, indem ich ein Spiel für Linux kaufen. Hinzu kommt noch, daß das Spiel für Linux teurer war, als die Windows-Version.
Vielleicht hätte ich die Windows-Version auch mit WineX hinterher auf Linux zum Laufen bekommen. Seltsamerweise laufen unter Linux mit Hilfe von Wine/WineX/CrossOver sogar viel ältere Windows-Programme auf Linux als Programme, die extra für Linux kompiliert wurden.
Ich werde jedenfalls kein Closed-Source Programm mehr für Linux kaufen, solange ich nicht zusätzlich die Garantie bekomme, daß es auch auf Distributionen, die in zehn Jahren rauskommen noch laufen.
Bei Debian geht das ja eigentlich ganz gut, bei RedHat/Fedora/SuSE/Mandriva habe ich damit aber meine Probleme. Zudem muss das Paket auch einige Eintraege in /etc/hotplug machen, und genau hier ist bei SuSE mit jeder Version staendig alles anders und SuSE kuemmert das einen Dreck.
Zudem will ich von SuSE 8.0 bzw. RedHat 8.0 aufwaerts bis zur aktuellen Distribution alles unterstuetzen. Hierzu stelle ich mir ein deb-Paket und ein rpm-Paket vor, das rpm-Paket soll wahlweise auch nich den 64-Bit code enthalten (Fat-Binary?). Bei Windows geht das doch auch, hier kann ich doch auch einen Installer fuer Windows 95 bis zum XP machen.
Kann mir vielleicht jemand einen interessanten Link dazu geben, wie man das erreichen koennte. Auf dem letzten Linux-Tag haben die Leute von Fedora und Novell dazu nur den Kopf geschuettelt und gemeint das wuerde nicht gehen.
Aber wozu ist dann die LSB und freestandards.org gut, wenn dann sowas nicht geht, oder nur fuer Distributionen die etwa alle gleich alt sind?