Aus dem Dokument: "Es ist wesentlich einfacher ein Paket für PAPPI zu erstellen, als für jeden Paket-Manager einer Distribution."
Kein Wunder, denn derzeit werden einfach gar keine Pakete verwendet, sondern .tar.bz2-Archive. Alle Zusatzfunktionen (Signaturen etc.) fehlen. Wenn das System in Zukunft darum erweitert wird dürfte es nicht mehr viel Unterschied zu allen anderen Paket-Formaten geben.
Auch sehe Ich keine Versionsverwaltung oder sonstiges, es handelt sich um einen reinen Client für einmaligen Kauf und Installation einer Software.
Der Autor nennt im Dokument explizit Einnahmemöglichkeiten für Publisher und App-Store-Betreiber, das System hat aber irgendwo überhaupt keine Funktionen zur Rechteverwaltung. Man muss sich wohl beim App Store einloggen, da die Software aber einfach in ein Archiv gepackt wird obliegt die Absicherung gegen einfaches "Wieder-Einpacken" wohl der Hersteller selbst.
Gegenüber 0install sehe Ich nur den direkten Einbau der Emulatoren als Vorteil, ansonsten scheint mir das System ein Rückschritt zu sein. Wobei Ich solchen Lösungen generell sehr kritisch gegenüberstehe, der Benutzer kommt nur auf die Idee Software zu instalieren die er nicht haben soll oder es gibt dann plötzlich parallel zum Paketmanagement noch mehrere Installation der gleichen Software weil die User an der im System installierten Version etwas auszusetzen haben.
Im Prinzip ist das nichts anderes als ein Loki Installer als Online Variante.
Aber das Kernproblem hat er meiner Meinung nach auch gar nicht verstanden. Denn es sind ja nicht unterschiedlichen Paketformate die das Problem darstellen, denn dafür gibt's ja Konvertierungstools wie alien & Co, sondern das Problem sind die vielen unterschiedlichen Bibliotheksversionen & Binarys bei den verschiedenen Distributionen in ihren verschiedenen Versionen.
Diese sind das Kernproblem und zu denen gibt es nur 2 Möglichkeiten. Entweder man liefert wie bei Windows alle diese Systembibliotheken doppelt mit und steckt sie in den Programmordner. So wie z.B. google-earth in /opt Oder man einigt sich auf einen gemeinsammen Nenner wie die Linux Standard Base.
Apropo LSB. Wie weit ist denn hier die GTK+ und Qt Standardisierung? Gibt's da jetzt inzwischen eine feste GTK+ > 2.10 Version und Qt 3.x Version?
"das Problem sind die vielen unterschiedlichen Bibliotheksversionen & Binarys bei den verschiedenen Distributionen in ihren verschiedenen Versionen."
Das Problem wälzt er einfach komplett auf Publisher und App-Store-Betreiber ab. Diese müssen festlegen für welche Distributionen in welcher Version das Paket funktioniert. Viele werden wohl den Weg der doppelten Libraries gehen.
Ich finde diese Konzepte eigentlich gänzlich schlecht, viel besser ist da doch z.B. der Ansatz von Opera. Lieber ein paar wenige Distributionen *richtig* unterstützen (inklusive Repositories, Signaturen etc.!) als auf so ein komisches Installer-System zu setzen und damit letztendlich dem User auch keinen Gefallen zu tun.
Übrigens wird das bei der Verteilung von Emulator-Images auch nicht unbedingt besser - man müsste festgelegte Versionen der Emulatoren mit ausliefern damit man garantieren könnte dass ein angebotenes Paket auch sicher läuft.
>Ich sehe da auch keinen Vorteil. >... >Denn es sind ja nicht unterschiedlichen Paketformate die >das Problem darstellen, denn dafür gibt's ja >Konvertierungstools wie alien & Co, sondern das Problem >sind die vielen unterschiedlichen Bibliotheksversionen & >Binarys bei den verschiedenen Distributionen in ihren >verschiedenen Versionen.
Maple, Matlab und Mathematica liefern auch die ganzen Systembibliotheken mit. Und tatsächlich kann man sowas nur sehr schlecht in einem RPM-Paket ausliefern. Da ist es schon besser, wenn die Programme in ihrem eigenen Verzeichnis leben.
>Apropo LSB. >Wie weit ist denn hier die GTK+ und Qt Standardisierung? Nicht existent? ^^
> Maple, Matlab und Mathematica liefern auch die ganzen > Systembibliotheken mit. Und tatsächlich kann man > sowas nur sehr schlecht in einem RPM-Paket ausliefern. > Da ist es schon besser, wenn die Programme in ihrem > eigenen Verzeichnis leben.
Was hat das Paketformat mit dem Ort der Daten zu tun? Also bitte, wenn du schon postest, dann informiere dich erstmal.
Wie weit ist denn hier die GTK+ und Qt Standardisierung?
GTK+, Qt (3 und 4) sind im lsb-desktop Modul.
Gibt's da jetzt inzwischen eine feste GTK+ > 2.10 Version und Qt 3.x Version?
Ich glaube die aktuellste LSB ist immer noch 4.0, d.h. GTK+ 2.8, Qt 3.3 und Qt 4.2
Das Problem ist, wie ich schon mal erläutert habe, die zu starke Fokusierung auf Red Hats und Novells "Enterprise Desktop" und zu wenig Feedback der Desktopsoftwarehersteller.
Es ist irgendwo fraglich wie wichtig die LSB für Software-Hersteller generell ist. Schaut man sich reale Beispiele an (Opera, World of Goo etc.) fällt auf dass ein halbwegs gescheiter Hersteller es sehr wohl auch einfach so hinkriegt Software zu bauen die auf den allermeisten Distributionen out-of-the-box läuft. Effektiv machen die sogar einen besseren Job, Opera z.B. läuft auch auf Distributionen die ab Werk gar nicht LSB-konform sind (Ubuntu, Debian).
Software die tatsächlich mit dem Label "LSB-compliant" verkauft würde hab Ich noch nie gesehen.
Ich denke es gibt da vermutlich unterschiedliche Ansätze für unterschiedliche Art von Software.
Die Integration in das Hauptpaketsystem und dessen Updatemechanismus hat sicher seine Vorteile, bedeutet aber auch, dass mehr Wissen um die korrekte Paketierung nötig ist.
Manche Hersteller arbeiten lieber autark und investieren ihre Resourcen dann in eigene Distributionskanäle/-technologien, Updatemechanismen, etc.
Hersteller dieser Kategorie hätten die Möglichkeit, durch entsprechendes Feedback zu einer bessern Ausgangssituation zu kommen, anstatt sich in die üblichen Ausreden zu flüchten.
Von legacy krämer am Di, 16. Februar 2010 um 02:34 #
Ist das dann auch abwärtskompatibel? Also ist garantiert, dass man LSB 4 Software auch noch mit LSB 6 ausführen kann? Ich hatte neulich erst wieder versucht, eine alte (2005) proprietäre Software zum laufen zu bringen - ein 32bit Binary, dass libstdc++5 benötigt, auf einem 64bit System. Die Lösung bestand dann darin, das entsprechende 32bit Paket einer alten Version der Distribution mit dpkg --force zu installieren, bei 'einfachen' wie der libstdc++ mag das noch gehen, wenn es aber Komplexere Dinge sind, wie z.b. qt, kann man das ganz vergessen. Wer vor 10 Jahren eine Anwendung in qt2 geschrieben hat, kann die heute eigentlich nur noch wegwerfen oder in einer VM betreiben - das ist total krank imho.
> Wer vor 10 Jahren eine Anwendung in qt2 geschrieben hat, kann die heute eigentlich nur noch wegwerfen oder in einer VM betreiben - das ist total krank imho.
Das war damals ein Sonderfall, da der C++ Compiler g++ 2.x eine andere ABI verwendete, als spätere Versionen wie z.B. der g++ 3.4. Siehe auch: http://de.wikipedia.org/wiki/Bin%C3%A4rschnittstelle
Um dein Problem zu lösen müßtest du also schauen welche Bibliotheken du für deine Anwendung brauchst und dann müßtest du diese mit einer g++ Compilerversion erstellen, die die gleiche ABI verwendet wie damals deine Anwendung. Am leichtesten geht das, in dem du einfach schaust welcher Compiler damals in deiner Distribution verwendet wurde, mit dem diese Qt ANwendung lief. Ich würde spontan mal auf g++ 2.9x tippen.
Um dein Problem zu lösen müßtest du also schauen welche Bibliotheken du für deine Anwendung brauchst und dann müßtest du diese mit einer g++ Compilerversion erstellen, die die gleiche ABI verwendet wie damals deine Anwendung. Am leichtesten geht das, in dem du einfach schaust welcher Compiler damals in deiner Distribution verwendet wurde, mit dem diese Qt ANwendung lief. Ich würde spontan mal auf g++ 2.9x tippen. Das ist doch ein schlechter Scherz. Und das setzt auch noch voraus, dass man den Quellcode der Software hat. Liegt das binär vor, kann man's offenbar gleich vergessen? Ich rede hier ja nicht von Uralt Software, aber wenn man sich z.b. Spiele anschaut, unter Windows 7 laufen fast alle Spiele, die 2000 oder sogar früher geschrieben wurden, ja sogar manche, die noch für Windows 98 geschrieben wurden - und da wurde in der Zwischenzeit der komplette Kernel ausgetauscht. Dagegen hat man unter Linux schon Probleme, heutzutage noch Sound aus Quake III herauszubekommen, wenn man entsprechende symlinks auf Bibliotheken gesetzt hat, damit es überhaupt startet - da ist man froh, wenn es überhaupt Spiele für Linux gibt, und dann funktionieren sie nach ner weile nicht mehr..
Eine Lösung besteht darin, das Linuxsystem beizubehalten, auf welchem Deine proprietäre Software zum letzten Mal vernünftig lief.
In der Windowswelt gibt es tatsächlich ähnliche Probleme. Denke nur einmal an all die Spiele, die speziell für 3Dfx-Voodoo-Grafikkarten geschrieben worden sind (z.B. bestimmte Unreal Tournament-Versionen). 3Dfx ist jetzt tot, Glide auch, benutzt halt etwas "Moderneres"? Nein, lieber nicht. Das alte System läuft im Hinblick auf seine wenigen "Aufgaben" noch ganz hervorragend.
Aber das ist doch schon ein Unterschied, ob eine Software nun tot und die Firma nicht mehr existiert (und sogar da gibt's afaik einen Glide Wrapper), oder ob es sich einfach um zwei Major Releases unterscheidet - selbst als KDE 3.5 noch aktuell war, gab es in den meisten Distributionen keine Möglichkeit, noch an qt2 Pakete zu kommen. Das Problem ist ja nicht, dass die Software nicht funktionieren würde, das Problem ist einfach, dass es keine Pakete mit den Abhängigkeiten gibt. (bzw. dass sich die nicht sonvoll installieren lassen, z.B. qt aus einer alten Version der Distribution)
Mit Qt2 liegst Du - genauso wie Nutzer "legacy krämer" (s.o.) - definitiv falsch. Qt2 lässt sich auch noch für aktuelle Distros kompilieren und damit verwenden. Ein Beispiel ist OpenSuse 11.1: Eine KDE2/Qt2-Live-CD mit der Bezeichnung "KDE-Two-Live.i686-2.2.2-Build1.1.iso" kannst Du Dir hier herunterladen: http://download.opensuse.org/repositories/KDE:/Medias/images/iso Die QT2-Pakete für OpenSuse 11.1 und 11.2 findest Du hier: http://download.opensuse.org/repositories/home:/ars3niy/openSUSE_11.1/i586/ und http://download.opensuse.org/repositories/home:/ars3niy/openSUSE_11.2/i586/
Von Hans Peter Müller am Mo, 15. Februar 2010 um 10:19 #
Sorry, aber wenn ich schon Sätze lese wie "... der Benutzer kommt nur auf die Idee Software zu installieren die er nicht haben soll ...". Solchen Aussagen stehe ich sehr kritisch gegenüber. Wer bist du, dass du dir anmaßt Usern vorzuschreiben, was sie installieren dürfen und was nicht? Solch eine totalitäre Denke geht mir richtig gegen den Strich. Es ist verdammt nochmal die Entscheidung des Users was er installiert und wie oft. Überhaupt ist es seine Sache, was er mit seinem privaten Rechner anstellt.
Mich wuerde mal interessieren, wie du das denn bisher handhabst?
Also ich kann so ziemlich jedes Programm (wenn es kein setuid root braucht) in meinem Homeverzeichnis installieren. Mach ich schon lange so, bevor ich hundertmal zu ihrgendwelchen tollen Admins renne, die meinen vi brauch ich nicht, wir haben ja emacs installiert...
Fuer alle Leidgeplagten kann ich da nur pkgsrc empfehlen. Nur auf die Quota achten :)
> Also ich kann so ziemlich jedes Programm (wenn es kein setuid root braucht) in meinem Homeverzeichnis installieren. >Mach ich schon lange so, bevor ich hundertmal zu ihrgendwelchen tollen Admins renne, die meinen vi brauch ich nicht, wir haben ja emacs installiert...
Verhindern kannst du es nicht, und das muss auch nicht unbedingt sein. Es geht einfach um die Balance. Ich habe kein Problem damit dass erfahrenere User notfalls selbst Software in ihre Home-Verzeichnisse installieren, denn diese Leute werden eher an die Konsequenzen denken. Ein unerfahrener User hat normalerweise nicht die Kenntnisse selbst Archive auszupacken und Programme auszuführen, also ist er wohl oder übel gezwungen mit dem Admin zu reden.
Ein grafisches Tool mit dem unerfahrene User ohne große Hürden ungeprüfte Software aus unbekannten Quellen installieren können macht diese Balance komplett kaputt.
Das "Argument", dass es für Hersteller proprietärer Software soooooooooo schwer ist, das Programm so hinzubekommen, dass es auf allen gängigen Distris läuft, ist einfach nur kompletter Schwachsinn. Zum einen Gibt es genügend Gegenbeispiele (z. B. läuft Opera unter allen mir bekannten Distris absolut perfekt), zum anderen unterscheiden sich die allermeisten Distris schlicht und einfach nicht so sehr von einander, zumindest aus der Sicht einer installierten Software, dass es nennenswerte Probleme geben könnte. Dies ist einfach nur eine Ausrede von Leute, die unfähig sind, ihre Programme nach Linux zu portieren, oder es schlicht und einfach garnicht wirklich wollen.
Das anbieten eines Paketes für eine bestimmte Distribution ist primär Aufgabe des Distributors. Daher hinkt auch das Argument, Pakete für jede einzelne Distri anzubieten, sei für Closed-Source-Programmierer so aufwändig.
Und zu guterletzt: Wenn ich für jede Closed-Source-Crapware, die ich nutzen will, auch noch Geld bezahlen soll, dann kann ich auch direkt bei Windows bleiben. Ich sehe schlicht und einfach nicht die Notwendigkeit, für Programme Geld zu bezahlen. Für alles, was ich mit dem Rechner mache, habe ich sehr gute Open-Source-Programme direkt aus dem Paketmanager der Distribution (und ich nutze den Rechner wirklich intensiv, bin definitiv kein klassischer Internet-Email-Office-Nutzer).
Ich sehe in Linux nicht nur den Vorteil, dass es einfach besser ist, als z. B. Windows, sondern dass es das Potential hat, auch Politisch (Open Source) etwas zu bewegen. Und genau an dem Punkt wäre dieses Projekt komplett kontraproduktiv, und würde auch sonst keine wirklichen Vorteile bringen.
Du sprichst genau die Dinge an, die das Problem sind, nur ohne sie als Problem zu erkennen.
Viele Hersteller wollen nicht auf Linux portieren. Sie sehen keinen Gewinnbringenden Markt. (Die Erde ist flach!)
Distribution ist primär Aufgabe des Distributors aber Firmen, die gewohnt sind geschlossen zu arbeiten, tun sich sehr schwer für Distribution, Test und Pflege der Software mit vielen anderen Firmen zusammenzuarbeiten.
Für Produktiv genutzte Software, ist die Paketverwaltung super und Open Source Software zu empfehlen. (siehe unten) Was ist aber mit dem Spaßfaktor. Willst Du dem Nutzer das nächste "Moorhun schießen" verwehren, dass er für jede andre Plattform für 3 Euro kaufen kann.
Wenn Du Nutzern, die Vorteile von einer Open Source Produktivumgebung näher bringen willst, musst Du schon dafür sorgen, dass sie das System gerne nutzen. Dazu gehört auch, dass sie mit all der "Closed-Source-Crapware" rumspielen können, die sie haben wollen.
Das Verhältnis zur Paketverwaltung
Technisch gesehen arbeitet der Installer (PAPPI) in Verbindung mit dem App Store völlig unabhängig von der Paketverwaltung. Auch in der Zielsetzung unterscheidet sich PAPPI und das "App Store"-Konzept stark von der Paketverwaltung. Die Paketverwaltung erlaubt ein langfristig stabiles und konsistentes Produktivsystem aufzusetzen und auf Stand zu halten. Die Paketerstellung erfolgt meist aus dem Quellcode und ist besonders für Open Sorce Software geeignet. Es kennt Abhängigkeiten und eng mit der jeweiligen Distribution verwoben. Das "App Store"-Konzept sieht dagegen vor Programme zu packen, die bereits in Binärform vorliegen. Die Programme sind dabei von völlig unabhängig und nicht mit dem darunter liegenden System verwoben. Stattdessen stellt ein System mit PAPPI verschiedene (starre) Fähigkeiten und Schnittstellen bereit, die den Programmen als Laufzeitumgebung dienen. Hierbei wird die Laufzeitungen an das Angebot bestehender Applikationen angepasst, die häufig bereits für andere Plattformen existieren. Zum Beispiel kommen Emulatoren für Amiga, DOS oder Nintendo 64 zum Einsatz.
Muss Linux für die ganzen Anbieter von Kommerz-Software überhaupt einen Markt bieten? Ich rede hier jetzt nicht von Wissenschaftlichen Programmen wie Mathematica (die haben mit der Linux-Unterstützung lustiger Weise irgendwie keine Probleme, wenn sie denn wollen), sondern von z. B. den von dir Angesprochenen 3€-Spielen, etc. pp. Wie gesagt: Es gibt kaum noch einen Bereich, der nicht gut mit Open Source-Programmen abgedeckt ist.
Wer absolut nicht in der Lage ist, mal alternative Programme für den gleichen Verwendungszweck zu finden und zu verwenden, wird meiner Ansicht nach sowieso kaum mit Linux glücklich werden. Alleine schon, weil diese Leute den Umstieg von Windows zu Linux _niemals_ wollen oder sogar schaffen werden. Um jetzt mal dein Beispiel aufzugreifen: wenn jemand absolut nicht in der Lage ist, statt Moorhuhn irgendwas anderes (kdegames, gnome-games, frozen bubble, etc. pp. zu Spielen, soll einfach ein anderes Betriebssystem verwenden als Linux, wem es hingegen keine Probleme bereitet, der könnte mit Linux glücklich werden.
Warum soll Linux genau die Leute als Zielgruppe haben, die lieber Windows oder Mac möchten? Die Leute, die der Meinung sind, sie würden Linux dann benutzen, wenn es sich bedienen lässt, wie Windows, sollen doch bittebitte bei Windows bleiben. Ich bin der Meinung, dass verschiedene Betriebssysteme für verschiedene Arten von Nutzern da sind.
Davon abgesehen ist es wie gesagt nicht so das große Problem, Closed-Source Programme so zu schreiben, dass sie unter allen gängigen Distris läuft, und auch das paketieren usw. wird von den Distris in aller Regel gerne übernommen. Neben Opera seien noch GoogleEarth, Picassa, Skype oder der FoxitReader als Beispiele genannt: Alles Programme, die in so ziemlich jeder 0815-Distri direkt im Paketmanager zu finden sind.
Es geht nicht darum, ob der Benutzer auch ein anderes Spiel findet, das er spielen kann. Er möchte ein bestimmtes haben, weil ihn das anspricht.
Du hast recht, dass der Nutzer nicht glücklich wird, wenn er nicht in der Lage ist auf das zu verzichten, was er will und eben zu einer Alternative zu greifen. Genau das soll sich doch ändern.
Bei produktiver Software ist die Sache relativ einfach. Der Nutzer möchte nicht Word benutzen, sondern einen Brief schreiben. Er verlangt nur nach Word, weil er nichts anderes kennt, das dieses Bedürfnis angemessen erfüllt. Sobald er Writer kennen gelernt hat, ist das Problem erledigt.
Die meisten Menschen wollen aber eigentlich kein bestimmtes Betriebssystem. Denen ist das völlig Schnuppe. Sie möchten dass Ihre Bedürfnisse befriedigt werden. Wenn das nur mit Windows geht, kaufen sie Windows. Wenn es mit einem Mac besser geht und sie das wissen, kaufen sie einen Mac. Wenn es mit Linux geht und sie das wissen, ist Ihnen Linux genauso recht.
Die Leute, die danach schreien, dass Linux so wie Windows sein soll (Beispiel: "Linux braucht eine einfache Setup.exe!", "Linux soll endlich eine Registry bekommen.") tun dies doch nur, weil das die Mittel sind mit denen Sie gelernt haben, das zu erreichen, was sie haben wollen.
Die gleichen Leute nutzen aber auch ein iPhone, das nicht im geringsten ist, wie Windows und finden es toll. Diese Leute werden auch Linux gut finden, wenn es Ihre Bedürfnisse erfüllt und sie sich daran gewöhnt haben. Dann schimpfen sie über andere Systeme, die nicht so sind, wie das was sie kennen und schätzen.
Ich betreue eine Reihe von Nutzern, die nichts mit der Technik am Hut haben. Ich biete Ihnen fertige Systeme, die praktisch nicht kaputt gehen und für alle Alltagsaufgaben gerüstet sind. (Einer meiner Nutzer hat nicht mal Admin-Rechte auf seinem eigenen Notebook.) Es macht wesentlich mehr Spaß, für jemanden ein angepasstes System zusammenzustellen, als ständig Windows-Kisten zu flicken, an denen der Konzern, der die Software verbrochen hat, einen Haufen Geld verdient, wobei ich den Ärger habe.
> Muss Linux für die ganzen Anbieter von Kommerz- > Software überhaupt einen Markt bieten? Ich rede hier > jetzt nicht von Wissenschaftlichen Programmen wie > Mathematica (die haben mit der Linux-Unterstützung > lustiger Weise irgendwie keine Probleme, wenn sie denn > wollen), sondern von z. B. den von dir Angesprochenen > 3€-Spielen, etc. pp.
> Wie gesagt: Es gibt kaum noch einen Bereich, der > nicht gut mit Open Source-Programmen abgedeckt ist.
Nenne mir bitte ein Open Source Programm mit dem man Rommé (ein Kartenspiel) spielen kann. Ich habe bis heute kein gutes gefunden.
Unter Windows gibt es duzende Romméspiele zum Kaufen.
Und was ist mit den High-End A+ Spielen? Die hätte ich auch gerne unter Linux.
Und das Open Source Konzept funktioniert auch gar nicht überall. Gerade Spiele mit Story gehören da nicht dazu. Denn eine OSS Entwicklung dauert eine Ewigkeit,aber das Spiel ist in 10 h durchgespielt. Es braucht hier also ein anderes Entwicklungsmodell, wenn man den Konsumenten dauerhaft auf Laune halten möchte. Es reicht einfach nicht, wenn man ihm nur ein Open Source Adventure hinsetzt mit dem er sich dann ein ganzes Jahr beschäftigen soll. Das würde nur funktionieren wenn es möglich wäre, ständig vollwertige High End Open Source Spiele herauszubringen, aber dann müßten die Entwickler Vollzeit arbeiten und damit wären wir beim Lieben Geld. Denn die Entwickler brauchen ja auch etwas zum Essen.
Im Klartext: Bei High End Spielen funktioniert das Open Source Konzept nicht.
> Wer absolut nicht in der Lage ist, mal alternative > Programme für den gleichen Verwendungszweck zu > finden und zu verwenden, wird meiner Ansicht nach > sowieso kaum mit Linux glücklich werden.
Es gibt durchaus Programme zu denen es kein Open Source Pendant gibt, das auch nur annähernd an den Funktionsumfang und an die Qualität herankommt. Bei Videoschnittsoftware könnten wir hier anfangen.
> Warum soll Linux genau die Leute als Zielgruppe > haben, die lieber Windows oder Mac möchten? Die > Leute, die der Meinung sind, sie würden Linux dann > benutzen, wenn es sich bedienen lässt, wie Windows, > sollen doch bittebitte bei Windows bleiben. > Ich bin der Meinung, dass verschiedene > Betriebssysteme für verschiedene Arten von Nutzern > da sind.
Und schon wieder Schwachsinn. Bitte bringe nicht Plattformfeeling und Anwendungsangebot durcheinander.
Ein OS wie Linux darf sich anders anfühlen und verhalten als Windows, aber dennoch muß es ein gleich gutes Anwendungsangebot haben wie Windows.
Denn die Kernaufgabe eines Betriebssystems ist es, eine Abstraktionsebene für die darunterliegende Hardware anzubieten auf dem dann Anwendungsprogramme aufsetzen können.
Es ist nicht die Aufgabe eines Betriebssystems die Benutzer in ideologische Anwendungsgruppen aufzuteilen!
Aus diesem Grund muß Linux jede Art von Anwendungssoftware bieten, die auch Windows bietet.
Sprich, auch Linux braucht nen Bowser, eine Textverarbeitung, ein E-Mailprogramm, Videoschnittsoftware, Spiele usw. Es geht nicht, daß du z.B. den Browser und die Textverarbeitung einfach wegläßt mit der Begründung, daß es in der Linuxusercommunity nicht üblich wäre, im Internet zu surfen. Nur so mal zur Veranschaulichung als Beispiel.
Linuxuser haben die gleichen Bedürfnisse wie Windowsuser. Auch sie wollen ihre Videos auf ihrem OS schneiden können.
> Stattdessen stellt ein System mit PAPPI verschiedene (starre) Fähigkeiten und Schnittstellen bereit, die den Programmen als Laufzeitumgebung dienen.
Nein, so weit geht das Konzept nicht mal. PAPPI ist ein einfaches Shell-Script das mittels Zenity Dialog-Boxen anzeigt und die heruntergeladenen Pakete einfach entpackt. Das einzige derzeit verfügbare Paket (Open Sonic) bringt seine kompletten Libraries selbst mit. PAPPI kümmert sich weder um Architekturen (das Paket ist für x86 gebaut, Ich habe x86_64) noch um Sicherheit oder sonstwas. Der Autor liße verlauten dass diese Features Ihn derzeit nur bei der Entwicklung stören würden.
Das Skript "pappi" ist tatsächlich ein relativ dummes Shellskript.
Das Konzept ist aber nicht vollständig in dieser einen Datei implementiert. Wirft man einen Blick in das "install.sh" - Skript, sieht man, dass dort Pakete installiert werden. Diese stellen praktisch die Laufzeitumgebung dar.
Der größte Teil des Konzepts ist ohnehin noch nicht in Quelltext gegossen. Deswegen wird es wohl als "proof of concept" bezeichnet.
Wenn man sich das Video anschaut, sieht man dass schon eine Reihe von Paketen bestehen, die leider aus rechtlichen Gründen nicht zur Verfügung gestellt werden können.
> Wenn man sich das Video anschaut, sieht man dass schon eine Reihe von Paketen bestehen, die leider aus rechtlichen Gründen nicht zur Verfügung gestellt werden können.
Nett dass der Autor hier auch schreibt
Es wäre mal nett zu hören was außer der Emulator-Geschichte jetzt an PAPPI besser ist als an andere App Stores und Lösungen wie 0install. Und warum es nicht möglich war diese anderen Lösungen deinen Wünschen gerecht anzupassen.
PAPPI ist einfacher. Es gehörte nicht viel dazu, es zu entwickeln. Man muss nicht viel können, um ein Paket zusammenzuschrauben. Man braucht keine tief greifenden Kenntnisse. Wenn man ein Programm bei sich zum laufen bekommt, kann man es auch verpacken. Trotzdem erfüllt es seinen Zweck gut. Das Zusammenspiel mit einem App Store, der eine reine Webanwendung darstellt, klappt wunderbar.
Es lässt sich sehr leicht anpassen. Das wird vor allem dann wichtig, wenn man es zum Beispiel in eine HTPC integrieren will oder eine Linux-Spielkonsole bauen möchte.
Ich erhebe hier keinen Anspruch ein toller Entwickler zu sein. Ich mache mir nur Gedanken darüber, wie man den Nutzern das bestmögliche bieten kann und beschreite den einfachsten Weg dahin.
> Technisch gesehen arbeitet der Installer (PAPPI) in > Verbindung mit dem App Store völlig unabhängig von > der Paketverwaltung. > Auch in der Zielsetzung unterscheidet sich PAPPI und > das "App Store"-Konzept stark von der Paketverwaltung.
Firmen von Closed Source Anwendungen wollen aber gar keinen Appstore.
Denn ein Appstore bedeutet doch nur, daß unter der Rubrik Skatspiele gleich 20 verschiedene Konkurrenten aufgeführt werden, die ebenfalls ein Skat Spiel anbieten.
Warum soll man sich als Unternehmen das antun und der Konkurrenz auch eine Chance lassen?
Nein, das beste Appstore ist das, bei dem man das Alleinstellungsmerkmal und keine Konkurrenz hat. So etwas ist aber praktisch nicht möglich, es sei denn man kümmert sich selbst um ein eigenes Appstore Konzept und genau so wird es auch gemacht.
Bsp. Es gibt verschiedene Antivirensoftwarehersteller die auch Produkte für Linux anbieten. Aber keiner von denen will in ein allgemeines Appstorekonezpt rein. Die bieten alle ihre eigene Softwarevertriebsplattform an.
Fazit: Was bei Open Source mit Paketmanagern funktioniert, muß bei Closed Source noch lange nicht funktionieren, da es politisch gar nicht gewollt ist.
Firmen von Closed Source Anwendungen wollen aber gar keinen Appstore.
Denn ein Appstore bedeutet doch nur, daß unter der Rubrik Skatspiele gleich 20 verschiedene Konkurrenten aufgeführt werden, die ebenfalls ein Skat Spiel anbieten.
Warum soll man sich als Unternehmen das antun und der Konkurrenz auch eine Chance lassen?
Ja, deshalb werden solche Spiele auch nie in Elektronik oder Spielemärkten verkauft, denn da würden die ja auch nach Kategorien sortiert im Regal landen.
> Ich sehe schlicht und einfach nicht die Notwendigkeit, für Programme Geld zu bezahlen.
Wie arm bist du?
Gute Programme verdienen es, das man dafür Geld ausgibt. Die Entwickler wollen schließlich auch von etwas leben.
Das kostenlose Open Source Programme deine Anforderungen erfüllen ist ja ok, aber generell zu sagen, daß man für Software nichts bezahlen will ist einfach Schwachsinnig.
Unter Windows raubkopierst du also wohl, denn du willst für Software ja kein Geld ausgeben. Mit anderen Worten, für dich hat Software keinen Wert. Das drückst du mit deinem Satz all zu deutlich aus.
denn gerade dort bietet sich ein Markt, der mit den "Apple Apps" konkurieren muss. Viele der Kunden eines solchen Telephons sind bereit, für "Apps" zu zahlen - sie kennen es nicht anders. Und grundsätzlich ist am Geschäftsmodell "Software gegen Geld" Nichts falsch. Den Massenmarkt erreicht man wohl besser durch praktische Lösungen, als dirch ideologische Überlegungen, daher: Daumen hoch
Andererseits wäre mir ein Programm, mit dem ich von meinem PC auf Android Telephone zugreifen kann, noch viel wichtiger. Dass es noch nichts Derartiges gibt (zumal wir derzeit alle recht "nahe" Kernel benutzen) ist schon bestürzend.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 15. Feb 2010 um 10:25.
Gute Frage. Wie konnte ich bei den Stichworten Linux und App Store nur auf das Handy-OS Android kommen? Manchmal verstehe ich meine Assoziationsketten selbst kaum ...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 15. Feb 2010 um 11:53.
> Android 1.5 (Firmware Version meines Handys) läuft auf und mit dem Linux Kernel 2.6.27.
Hast du dich mal näher mit der Plattform beschäftigt? Sämtliche Anwendungen laufen in der Dalvik-VM, einer Java-Abart, nur gelegentlich wird mittels NDK direkt auf das darunter liegende System zugegriffen. Android abstrahiert das Betriebssystem völlig, der Linux-Kern kann theoretisch morgen gegen etwas Anderes ausgetauscht werden.
Google hat darüber hinaus quasi alle gewohnten Userspace-Lösungen (GNU oder nicht) gegen eigene Ideen ausgetauscht und Kernel-Erweiterungen eingeführt die es sonst nirgends gibt.
Android ist zwar eigenartig, aber schon frei, oder? Und ein Linux Kernel kommt auch zum Einsatz. Klar man könnte den Austauschen. Aber ich kann auch den linux Kernel auf meinem Laptop gegen ein BSD Kern austauschen und hätte trotzdem noch freie Software drauf am laufen.
... die Lösung heißt "LSB". Es ist an den Herstellern von Drittsoftware, entweder ihre Anwendungen dagegen zu linken, oder aber Verbesserungsvorschläge zu machen, falls ihnen etwas fehlt. Der dreiundneunzigste Installeransatz mit "jetzt noch runderen Rädern" ist jedenfalls keine Option. Vor allem dann nicht, wenn er einen Rückschritt darstellt, selbst in der Nische, die er ausfüllen möchte.
Dazu fällt mir ein: - Abgespeckte RPM-Version als Paketformat vorgeschrieben, wer das nicht will muss einen Binär-Installer ausliefern - Schreibt SYS V Init vor - Keine Bash - Multimedia beschränkt sich auf die libasound und OpenGL - /sys und /proc sind nicht spezifiziert - Keine Hardware Specification für ARM, die nach x86 und x86_64 wichtigste Architektur - Nur Python und Perl als Script-Sprachen - Nur gzip, kein bzip2
Man hat als Hersteller zwar eine definierte Umgebung, aber die ist schon sehr eingeschränkt.
wenn die LSB so viele lücken aufweißt, warum setzt man sich nicht mal wieder zusammen und schließt diese? (nur nur "daran arbeiten") das heißt dann aber auch sich auf einen einheitlichen Packetmanager zu einigen. ob das nun dpkg oder rpm (oder auch ein anderer/neuer) ist dürfte den meisten egal sein. Nur hätten wir dann mal ne Basis um Konkurenzfähig zu werden, das jeder bastelt seinen eigenen schrott funzt auf dauer nicht!
Wenn man das mal hätte könnte man daran gehen Programme zu Entwickeln die Softwarepackete im Homeverzeichnis installieren.
> sich auf einen einheitlichen Packetmanager zu einigen
Einheitslösungen funktionieren nie. Die Paketmanager sind auch gar nicht das Problem.
> hätten wir dann mal ne Basis um Konkurenzfähig zu werden
Öhm konkurrenzfähig gegenüber wem genau? Windows? Die haben nicht mal ein Paketmanagement...
> Programme zu Entwickeln die Softwarepackete im Homeverzeichnis installieren
Warum sollte man das denn bitte wollen? Damit jeder User eine andere Version der gleichen Software manuell installiert, keine Updates eingespielt werden, die Backup-Medien sinnlos vollaufen und der Administrator das Durcheinander auch noch supporten muss?
Es wurde hier schon oft geschrieben: Korrektes Packaging ist Aufgabe des Herstellers oder der Distribution, viele Hersteller machen das auch schon richtig, und wenn ein Hersteller es falsch macht dann muss man dem eben klar machen wie es richtig funktioniert - und nicht Krücken-Lösungen erfinden oder ewig die gleich falschen Argumente verbreiten.
>Die Paketmanager sind auch gar nicht das Problem. Natürlich sind sie das Problem. Wenn sie einheitlich wären, dann bräuchte man nurnoch ein Packet pro Prozessorarchitektur bauen und jeder könnte es nutzen. Man kann den Riesenaufwand für jede Distri ein Packet zu bauen nicht an die Entwickler abwälzen. Das gilt nicht nur für für propärietäre Entwickler sonder auch für Hobby entwickler die sich dann viel Arbeit sparen. Man kann auch nicht von jedem User (v.a. Anfänger) erwarten sich ein Programm selbst zu bauen
>Windows? Die haben nicht mal ein Paketmanagement... Nein hab sie nicht, aber die Installation von Programmen geht einfacher (zumindest gegenüber von Programmen, die nicht in den Distri-Repos liegen)
>Warum sollte man das denn bitte wollen? gut das ist ein Punkt, andererseits kann dann der Admin auch sagen wenn ihr Software im Homeverzeichnis Installiert, müsst ihr euch selbst darum kümmern. Die Sicherheit des restlichen Systems ist dadurch ja nicht gefährdet. Man davon abgesehen dass das auch jetzt schon geht, nur ohne Packetmanager (siehe FF binärpacket von der Homepage). Mit Packetmanager der das kann hat man dann den Vorteil, dass man es leicht wieder los wird und man es updaten kann. Fedora wollte imo in ihr letztes Release so ein System einbauen nur war es eben noch nicht fertig bzw. man konnte die Packete nicht mehr loswerden.
> Natürlich sind sie das Problem. Wenn sie einheitlich wären, dann bräuchte man nurnoch ein Packet pro Prozessorarchitektur bauen und jeder könnte es nutzen
Nein, das sind sie nicht.
Wenn sie einheitlich wären, dann hättest du weiterhin das Problem mit unterschiedlichen Bibliotheksversionen auf jeder Distribution die binär zueinander inkompatibel sind.
>Die Paketmanager sind auch gar nicht das Problem. Natürlich sind sie das Problem. Wenn sie einheitlich wären, dann bräuchte man nurnoch ein Packet pro Prozessorarchitektur bauen und jeder könnte es nutzen. Man kann den Riesenaufwand für jede Distri ein Packet zu bauen nicht an die Entwickler abwälzen. Das gilt nicht nur für für propärietäre Entwickler sonder auch für Hobby entwickler die sich dann viel Arbeit sparen. Man kann auch nicht von jedem User (v.a. Anfänger) erwarten sich ein Programm selbst zu bauen
>Windows? Die haben nicht mal ein Paketmanagement... Nein hab sie nicht, aber die Installation von Programmen geht einfacher (zumindest gegenüber von Programmen, die nicht in den Distri-Repos liegen)
>Warum sollte man das denn bitte wollen? gut das ist ein Punkt, andererseits kann dann der Admin auch sagen wenn ihr Software im Homeverzeichnis Installiert, müsst ihr euch selbst darum kümmern. Die Sicherheit des restlichen Systems ist dadurch ja nicht gefährdet. Man davon abgesehen dass das auch jetzt schon geht, nur ohne Packetmanager (siehe FF binärpacket von der Homepage). Mit Packetmanager der das kann hat man dann den Vorteil, dass man es leicht wieder los wird und man es updaten kann. Fedora wollte imo in ihr letztes Release so ein System einbauen nur war es eben noch nicht fertig bzw. man konnte die Packete nicht mehr loswerden.
> hätten wir dann mal ne Basis um Konkurenzfähig zu werden
Öhm konkurrenzfähig gegenüber wem genau? Windows? Die haben nicht mal ein Paketmanagement... Dafür aber einen funktionierenden Mechanismus, Software von Drittanbietern zu installieren.
wenn die LSB so viele lücken aufweißt, warum setzt man sich nicht mal wieder zusammen und schließt diese? (nur nur "daran arbeiten") das heißt dann aber auch sich auf einen einheitlichen Packetmanager zu einigen. ob das nun dpkg oder rpm (oder auch ein anderer/neuer) ist dürfte den meisten egal sein. Nur hätten wir dann mal ne Basis um Konkurenzfähig zu werden, das jeder bastelt seinen eigenen schrott funzt auf dauer nicht!
Wenn man das mal hätte könnte man daran gehen Programme zu Entwickeln die Softwarepackete im Homeverzeichnis installieren.
> - Multimedia beschränkt sich auf die libasound und OpenGL > Man hat als Hersteller zwar eine definierte Umgebung, aber die ist schon sehr eingeschränkt.
Das ist aber kein Problem.
Denn die LSB bietet eine gemeinsamme Basis.
Wenn du noch zusätzliche Bibliotheken brauchst. Z.B. OpenAL, dann führst du diese einfach mit deinem Programm im Programmverzeichnis mit, aber du baust deine OpenAL Lib auf das bestehende LSB Basisystem auf.
Von Warum nicht den opensuse build am Mo, 15. Februar 2010 um 11:17 #
Wenn closed source im buildservice verwendet werden soll, dann liefern Die eben object code aus und lassen den auf dem buildservice einfach nur linken.
Und wenn man bezahlen muss, muss man zum Freischalten eben einen Lizenzschlüssel eingeben.
Aus dem Dokument: "Es ist wesentlich einfacher ein Paket für PAPPI zu erstellen, als für jeden Paket-Manager einer Distribution."
Kein Wunder, denn derzeit werden einfach gar keine Pakete verwendet, sondern .tar.bz2-Archive. Alle Zusatzfunktionen (Signaturen etc.) fehlen. Wenn das System in Zukunft darum erweitert wird dürfte es nicht mehr viel Unterschied zu allen anderen Paket-Formaten geben.
Auch sehe Ich keine Versionsverwaltung oder sonstiges, es handelt sich um einen reinen Client für einmaligen Kauf und Installation einer Software.
Der Autor nennt im Dokument explizit Einnahmemöglichkeiten für Publisher und App-Store-Betreiber, das System hat aber irgendwo überhaupt keine Funktionen zur Rechteverwaltung. Man muss sich wohl beim App Store einloggen, da die Software aber einfach in ein Archiv gepackt wird obliegt die Absicherung gegen einfaches "Wieder-Einpacken" wohl der Hersteller selbst.
Gegenüber 0install sehe Ich nur den direkten Einbau der Emulatoren als Vorteil, ansonsten scheint mir das System ein Rückschritt zu sein. Wobei Ich solchen Lösungen generell sehr kritisch gegenüberstehe, der Benutzer kommt nur auf die Idee Software zu instalieren die er nicht haben soll oder es gibt dann plötzlich parallel zum Paketmanagement noch mehrere Installation der gleichen Software weil die User an der im System installierten Version etwas auszusetzen haben.
Ich sehe da auch keinen Vorteil.
Im Prinzip ist das nichts anderes als ein Loki Installer als Online Variante.
Aber das Kernproblem hat er meiner Meinung nach auch gar nicht verstanden.
Denn es sind ja nicht unterschiedlichen Paketformate die das Problem darstellen, denn dafür gibt's ja Konvertierungstools wie alien & Co, sondern das Problem sind die vielen unterschiedlichen Bibliotheksversionen & Binarys bei den verschiedenen Distributionen in ihren verschiedenen Versionen.
Diese sind das Kernproblem und zu denen gibt es nur 2 Möglichkeiten.
Entweder man liefert wie bei Windows alle diese Systembibliotheken doppelt mit und steckt sie in den Programmordner. So wie z.B. google-earth in /opt
Oder man einigt sich auf einen gemeinsammen Nenner wie die Linux Standard Base.
Apropo LSB.
Wie weit ist denn hier die GTK+ und Qt Standardisierung?
Gibt's da jetzt inzwischen eine feste GTK+ > 2.10 Version und Qt 3.x Version?
"das Problem sind die vielen unterschiedlichen Bibliotheksversionen & Binarys bei den verschiedenen Distributionen in ihren verschiedenen Versionen."
Das Problem wälzt er einfach komplett auf Publisher und App-Store-Betreiber ab. Diese müssen festlegen für welche Distributionen in welcher Version das Paket funktioniert. Viele werden wohl den Weg der doppelten Libraries gehen.
Ich finde diese Konzepte eigentlich gänzlich schlecht, viel besser ist da doch z.B. der Ansatz von Opera. Lieber ein paar wenige Distributionen *richtig* unterstützen (inklusive Repositories, Signaturen etc.!) als auf so ein komisches Installer-System zu setzen und damit letztendlich dem User auch keinen Gefallen zu tun.
Übrigens wird das bei der Verteilung von Emulator-Images auch nicht unbedingt besser - man müsste festgelegte Versionen der Emulatoren mit ausliefern damit man garantieren könnte dass ein angebotenes Paket auch sicher läuft.
>Ich sehe da auch keinen Vorteil.
>...
>Denn es sind ja nicht unterschiedlichen Paketformate die
>das Problem darstellen, denn dafür gibt's ja
>Konvertierungstools wie alien & Co, sondern das Problem
>sind die vielen unterschiedlichen Bibliotheksversionen &
>Binarys bei den verschiedenen Distributionen in ihren
>verschiedenen Versionen.
Maple, Matlab und Mathematica liefern auch die ganzen Systembibliotheken mit. Und tatsächlich kann man sowas nur sehr schlecht in einem RPM-Paket ausliefern. Da ist es schon besser, wenn die Programme in ihrem eigenen Verzeichnis leben.
>Apropo LSB.
>Wie weit ist denn hier die GTK+ und Qt Standardisierung?
Nicht existent? ^^
> >Wie weit ist denn hier die GTK+ und Qt Standardisierung?
> Nicht existent? ^^
LSB-Desktop 4.0 umfasst Qt 3.3.6, Qt 4.3 und GTK 2.8.
> Maple, Matlab und Mathematica liefern auch die ganzen
> Systembibliotheken mit. Und tatsächlich kann man
> sowas nur sehr schlecht in einem RPM-Paket ausliefern.
> Da ist es schon besser, wenn die Programme in ihrem
> eigenen Verzeichnis leben.
Was hat das Paketformat mit dem Ort der Daten zu tun?
Also bitte, wenn du schon postest, dann informiere dich erstmal.
> Nicht existent? ^^
Das ist auch nicht korrekt.
Informiere dich!
Wie weit ist denn hier die GTK+ und Qt Standardisierung?
GTK+, Qt (3 und 4) sind im lsb-desktop Modul.
Gibt's da jetzt inzwischen eine feste GTK+ > 2.10 Version und Qt 3.x Version?
Ich glaube die aktuellste LSB ist immer noch 4.0, d.h. GTK+ 2.8, Qt 3.3 und Qt 4.2
Das Problem ist, wie ich schon mal erläutert habe, die zu starke Fokusierung auf Red Hats und Novells "Enterprise Desktop" und zu wenig Feedback der Desktopsoftwarehersteller.
> zu wenig Feedback der Desktopsoftwarehersteller
Es ist irgendwo fraglich wie wichtig die LSB für Software-Hersteller generell ist. Schaut man sich reale Beispiele an (Opera, World of Goo etc.) fällt auf dass ein halbwegs gescheiter Hersteller es sehr wohl auch einfach so hinkriegt Software zu bauen die auf den allermeisten Distributionen out-of-the-box läuft. Effektiv machen die sogar einen besseren Job, Opera z.B. läuft auch auf Distributionen die ab Werk gar nicht LSB-konform sind (Ubuntu, Debian).
Software die tatsächlich mit dem Label "LSB-compliant" verkauft würde hab Ich noch nie gesehen.
Ich denke es gibt da vermutlich unterschiedliche Ansätze für unterschiedliche Art von Software.
Die Integration in das Hauptpaketsystem und dessen Updatemechanismus hat sicher seine Vorteile, bedeutet aber auch, dass mehr Wissen um die korrekte Paketierung nötig ist.
Manche Hersteller arbeiten lieber autark und investieren ihre Resourcen dann in eigene Distributionskanäle/-technologien, Updatemechanismen, etc.
Hersteller dieser Kategorie hätten die Möglichkeit, durch entsprechendes Feedback zu einer bessern Ausgangssituation zu kommen, anstatt sich in die üblichen Ausreden zu flüchten.
Ist das dann auch abwärtskompatibel? Also ist garantiert, dass man LSB 4 Software auch noch mit LSB 6 ausführen kann?
Ich hatte neulich erst wieder versucht, eine alte (2005) proprietäre Software zum laufen zu bringen - ein 32bit Binary, dass libstdc++5 benötigt, auf einem 64bit System.
Die Lösung bestand dann darin, das entsprechende 32bit Paket einer alten Version der Distribution mit dpkg --force zu installieren, bei 'einfachen' wie der libstdc++ mag das noch gehen, wenn es aber Komplexere Dinge sind, wie z.b. qt, kann man das ganz vergessen.
Wer vor 10 Jahren eine Anwendung in qt2 geschrieben hat, kann die heute eigentlich nur noch wegwerfen oder in einer VM betreiben - das ist total krank imho.
> Ist das dann auch abwärtskompatibel? Also ist garantiert, dass man LSB 4 Software auch noch mit LSB 6 ausführen kann?
Siehe:
http://en.wikipedia.org/wiki/Linux_Standard_Base#Backwards_compatibility
> Wer vor 10 Jahren eine Anwendung in qt2 geschrieben hat, kann die heute eigentlich nur noch wegwerfen oder in einer VM betreiben - das ist total krank imho.
Das war damals ein Sonderfall, da der C++ Compiler g++ 2.x eine andere ABI verwendete, als spätere Versionen wie z.B. der g++ 3.4.
Siehe auch:
http://de.wikipedia.org/wiki/Bin%C3%A4rschnittstelle
Um dein Problem zu lösen müßtest du also schauen welche Bibliotheken du für deine Anwendung brauchst und dann müßtest du diese mit einer g++ Compilerversion erstellen, die die gleiche ABI verwendet wie damals deine Anwendung.
Am leichtesten geht das, in dem du einfach schaust welcher Compiler damals in deiner Distribution verwendet wurde, mit dem diese Qt ANwendung lief.
Ich würde spontan mal auf g++ 2.9x tippen.
Um dein Problem zu lösen müßtest du also schauen welche Bibliotheken du für deine Anwendung brauchst und dann müßtest du diese mit einer g++ Compilerversion erstellen, die die gleiche ABI verwendet wie damals deine Anwendung.
Am leichtesten geht das, in dem du einfach schaust welcher Compiler damals in deiner Distribution verwendet wurde, mit dem diese Qt ANwendung lief.
Ich würde spontan mal auf g++ 2.9x tippen.
Das ist doch ein schlechter Scherz. Und das setzt auch noch voraus, dass man den Quellcode der Software hat. Liegt das binär vor, kann man's offenbar gleich vergessen?
Ich rede hier ja nicht von Uralt Software, aber wenn man sich z.b. Spiele anschaut, unter Windows 7 laufen fast alle Spiele, die 2000 oder sogar früher geschrieben wurden, ja sogar manche, die noch für Windows 98 geschrieben wurden - und da wurde in der Zwischenzeit der komplette Kernel ausgetauscht. Dagegen hat man unter Linux schon Probleme, heutzutage noch Sound aus Quake III herauszubekommen, wenn man entsprechende symlinks auf Bibliotheken gesetzt hat, damit es überhaupt startet - da ist man froh, wenn es überhaupt Spiele für Linux gibt, und dann funktionieren sie nach ner weile nicht mehr..
Eine Lösung besteht darin, das Linuxsystem beizubehalten, auf welchem Deine proprietäre Software zum letzten Mal vernünftig lief.
In der Windowswelt gibt es tatsächlich ähnliche Probleme. Denke nur einmal an all die Spiele, die speziell für 3Dfx-Voodoo-Grafikkarten geschrieben worden sind (z.B. bestimmte Unreal Tournament-Versionen). 3Dfx ist jetzt tot, Glide auch, benutzt halt etwas "Moderneres"?
Nein, lieber nicht. Das alte System läuft im Hinblick auf seine wenigen "Aufgaben" noch ganz hervorragend.
Aber das ist doch schon ein Unterschied, ob eine Software nun tot und die Firma nicht mehr existiert (und sogar da gibt's afaik einen Glide Wrapper), oder ob es sich einfach um zwei Major Releases unterscheidet - selbst als KDE 3.5 noch aktuell war, gab es in den meisten Distributionen keine Möglichkeit, noch an qt2 Pakete zu kommen.
Das Problem ist ja nicht, dass die Software nicht funktionieren würde, das Problem ist einfach, dass es keine Pakete mit den Abhängigkeiten gibt. (bzw. dass sich die nicht sonvoll installieren lassen, z.B. qt aus einer alten Version der Distribution)
Mit Qt2 liegst Du - genauso wie Nutzer "legacy krämer" (s.o.) - definitiv falsch.
Qt2 lässt sich auch noch für aktuelle Distros kompilieren und damit verwenden.
Ein Beispiel ist OpenSuse 11.1: Eine KDE2/Qt2-Live-CD mit der Bezeichnung "KDE-Two-Live.i686-2.2.2-Build1.1.iso" kannst Du Dir hier herunterladen:
http://download.opensuse.org/repositories/KDE:/Medias/images/iso
Die QT2-Pakete für OpenSuse 11.1 und 11.2 findest Du hier:
http://download.opensuse.org/repositories/home:/ars3niy/openSUSE_11.1/i586/
und
http://download.opensuse.org/repositories/home:/ars3niy/openSUSE_11.2/i586/
Sorry, aber wenn ich schon Sätze lese wie "... der Benutzer kommt nur auf die Idee Software zu installieren die er nicht haben soll ...". Solchen Aussagen stehe ich sehr kritisch gegenüber. Wer bist du, dass du dir anmaßt Usern vorzuschreiben, was sie installieren dürfen und was nicht? Solch eine totalitäre Denke geht mir richtig gegen den Strich.
Es ist verdammt nochmal die Entscheidung des Users was er installiert und wie oft. Überhaupt ist es seine Sache, was er mit seinem privaten Rechner anstellt.
> Es ist verdammt nochmal die Entscheidung des Users was er installiert und wie oft.
Falls "User" und "Administrator" die Selbe Person sind: ja.
Falls nicht: Nein.
Selbst im privaten Umfeld hat man ja oft mehr als einen User pro System.
Mich wuerde mal interessieren, wie du das denn bisher handhabst?
Also ich kann so ziemlich jedes Programm (wenn es kein setuid root braucht) in meinem Homeverzeichnis installieren.
Mach ich schon lange so, bevor ich hundertmal zu ihrgendwelchen tollen Admins renne, die meinen vi brauch ich nicht, wir haben ja emacs installiert...
Fuer alle Leidgeplagten kann ich da nur pkgsrc empfehlen.
Nur auf die Quota achten :)
> Also ich kann so ziemlich jedes Programm (wenn es kein setuid root braucht) in meinem Homeverzeichnis installieren.
>Mach ich schon lange so, bevor ich hundertmal zu ihrgendwelchen tollen Admins renne, die meinen vi brauch ich nicht, wir haben ja emacs installiert...
Verhindern kannst du es nicht, und das muss auch nicht unbedingt sein. Es geht einfach um die Balance. Ich habe kein Problem damit dass erfahrenere User notfalls selbst Software in ihre Home-Verzeichnisse installieren, denn diese Leute werden eher an die Konsequenzen denken. Ein unerfahrener User hat normalerweise nicht die Kenntnisse selbst Archive auszupacken und Programme auszuführen, also ist er wohl oder übel gezwungen mit dem Admin zu reden.
Ein grafisches Tool mit dem unerfahrene User ohne große Hürden ungeprüfte Software aus unbekannten Quellen installieren können macht diese Balance komplett kaputt.
>Verhindern kannst du es nicht, und das muss auch nicht >unbedingt sein.
noexec? ist eh sinnvoll für homes... ^^
der ist gut!
Ich nehm /tmp
> noexec? ist eh sinnvoll für homes...
Dann funktionieren Skripte aber auch nicht mehr.
$ sh
Wozu braucht man sowas?
Das "Argument", dass es für Hersteller proprietärer Software soooooooooo schwer ist, das Programm so hinzubekommen, dass es auf allen gängigen Distris läuft, ist einfach nur kompletter Schwachsinn.
Zum einen Gibt es genügend Gegenbeispiele (z. B. läuft Opera unter allen mir bekannten Distris absolut perfekt), zum anderen unterscheiden sich die allermeisten Distris schlicht und einfach nicht so sehr von einander, zumindest aus der Sicht einer installierten Software, dass es nennenswerte Probleme geben könnte.
Dies ist einfach nur eine Ausrede von Leute, die unfähig sind, ihre Programme nach Linux zu portieren, oder es schlicht und einfach garnicht wirklich wollen.
Das anbieten eines Paketes für eine bestimmte Distribution ist primär Aufgabe des Distributors. Daher hinkt auch das Argument, Pakete für jede einzelne Distri anzubieten, sei für Closed-Source-Programmierer so aufwändig.
Und zu guterletzt: Wenn ich für jede Closed-Source-Crapware, die ich nutzen will, auch noch Geld bezahlen soll, dann kann ich auch direkt bei Windows bleiben. Ich sehe schlicht und einfach nicht die Notwendigkeit, für Programme Geld zu bezahlen. Für alles, was ich mit dem Rechner mache, habe ich sehr gute Open-Source-Programme direkt aus dem Paketmanager der Distribution (und ich nutze den Rechner wirklich intensiv, bin definitiv kein klassischer Internet-Email-Office-Nutzer).
Ich sehe in Linux nicht nur den Vorteil, dass es einfach besser ist, als z. B. Windows, sondern dass es das Potential hat, auch Politisch (Open Source) etwas zu bewegen. Und genau an dem Punkt wäre dieses Projekt komplett kontraproduktiv, und würde auch sonst keine wirklichen Vorteile bringen.
Schon mal einem technisch wenig versierten Nutzer Linux vorgesetzt?
Ist eigentlich toll. Das bekommt er nicht Kaputt, wie Windows. Das heißt also auch nicht alle fünf Monate zur Reparatur springen müssen.
Doch dann kommt's: "Da ist ein lustiges Spiel. Das will ich haben!"
Das ist der Moment in dem der Nutzer enttäuscht wird und sich wieder ein System wünscht, mit dem seine "Will haben ..."-Anfälle befriedigt werden.
Das macht auch das iPhone sehr attraktiv: "Für alles gibt es ein App!"
Du sprichst genau die Dinge an, die das Problem sind, nur ohne sie als Problem zu erkennen.
Das Verhältnis zur Paketverwaltung
Technisch gesehen arbeitet der Installer (PAPPI) in Verbindung mit dem App Store völlig unabhängig von der Paketverwaltung.
Auch in der Zielsetzung unterscheidet sich PAPPI und das "App Store"-Konzept stark von der Paketverwaltung.
Die Paketverwaltung erlaubt ein langfristig stabiles und konsistentes Produktivsystem aufzusetzen und auf Stand zu halten. Die Paketerstellung erfolgt meist aus dem Quellcode und ist besonders für Open Sorce Software geeignet. Es kennt Abhängigkeiten und eng mit der jeweiligen Distribution verwoben.
Das "App Store"-Konzept sieht dagegen vor Programme zu packen, die bereits in Binärform vorliegen. Die Programme sind dabei von völlig unabhängig und nicht mit dem darunter liegenden System verwoben.
Stattdessen stellt ein System mit PAPPI verschiedene (starre) Fähigkeiten und Schnittstellen bereit, die den Programmen als Laufzeitumgebung dienen.
Hierbei wird die Laufzeitungen an das Angebot bestehender Applikationen angepasst, die häufig bereits für andere Plattformen existieren. Zum Beispiel kommen Emulatoren für Amiga, DOS oder Nintendo 64 zum Einsatz.
Muss Linux für die ganzen Anbieter von Kommerz-Software überhaupt einen Markt bieten? Ich rede hier jetzt nicht von Wissenschaftlichen Programmen wie Mathematica (die haben mit der Linux-Unterstützung lustiger Weise irgendwie keine Probleme, wenn sie denn wollen), sondern von z. B. den von dir Angesprochenen 3€-Spielen, etc. pp.
Wie gesagt: Es gibt kaum noch einen Bereich, der nicht gut mit Open Source-Programmen abgedeckt ist.
Wer absolut nicht in der Lage ist, mal alternative Programme für den gleichen Verwendungszweck zu finden und zu verwenden, wird meiner Ansicht nach sowieso kaum mit Linux glücklich werden. Alleine schon, weil diese Leute den Umstieg von Windows zu Linux _niemals_ wollen oder sogar schaffen werden.
Um jetzt mal dein Beispiel aufzugreifen: wenn jemand absolut nicht in der Lage ist, statt Moorhuhn irgendwas anderes (kdegames, gnome-games, frozen bubble, etc. pp. zu Spielen, soll einfach ein anderes Betriebssystem verwenden als Linux, wem es hingegen keine Probleme bereitet, der könnte mit Linux glücklich werden.
Warum soll Linux genau die Leute als Zielgruppe haben, die lieber Windows oder Mac möchten? Die Leute, die der Meinung sind, sie würden Linux dann benutzen, wenn es sich bedienen lässt, wie Windows, sollen doch bittebitte bei Windows bleiben.
Ich bin der Meinung, dass verschiedene Betriebssysteme für verschiedene Arten von Nutzern da sind.
Davon abgesehen ist es wie gesagt nicht so das große Problem, Closed-Source Programme so zu schreiben, dass sie unter allen gängigen Distris läuft, und auch das paketieren usw. wird von den Distris in aller Regel gerne übernommen. Neben Opera seien noch GoogleEarth, Picassa, Skype oder der FoxitReader als Beispiele genannt: Alles Programme, die in so ziemlich jeder 0815-Distri direkt im Paketmanager zu finden sind.
Es geht nicht darum, ob der Benutzer auch ein anderes Spiel findet, das er spielen kann. Er möchte ein bestimmtes haben, weil ihn das anspricht.
Du hast recht, dass der Nutzer nicht glücklich wird, wenn er nicht in der Lage ist auf das zu verzichten, was er will und eben zu einer Alternative zu greifen. Genau das soll sich doch ändern.
Bei produktiver Software ist die Sache relativ einfach. Der Nutzer möchte nicht Word benutzen, sondern einen Brief schreiben. Er verlangt nur nach Word, weil er nichts anderes kennt, das dieses Bedürfnis angemessen erfüllt. Sobald er Writer kennen gelernt hat, ist das Problem erledigt.
Die meisten Menschen wollen aber eigentlich kein bestimmtes Betriebssystem. Denen ist das völlig Schnuppe. Sie möchten dass Ihre Bedürfnisse befriedigt werden. Wenn das nur mit Windows geht, kaufen sie Windows. Wenn es mit einem Mac besser geht und sie das wissen, kaufen sie einen Mac. Wenn es mit Linux geht und sie das wissen, ist Ihnen Linux genauso recht.
Die Leute, die danach schreien, dass Linux so wie Windows sein soll (Beispiel: "Linux braucht eine einfache Setup.exe!", "Linux soll endlich eine Registry bekommen.") tun dies doch nur, weil das die Mittel sind mit denen Sie gelernt haben, das zu erreichen, was sie haben wollen.
Die gleichen Leute nutzen aber auch ein iPhone, das nicht im geringsten ist, wie Windows und finden es toll. Diese Leute werden auch Linux gut finden, wenn es Ihre Bedürfnisse erfüllt und sie sich daran gewöhnt haben. Dann schimpfen sie über andere Systeme, die nicht so sind, wie das was sie kennen und schätzen.
Ich betreue eine Reihe von Nutzern, die nichts mit der Technik am Hut haben. Ich biete Ihnen fertige Systeme, die praktisch nicht kaputt gehen und für alle Alltagsaufgaben gerüstet sind. (Einer meiner Nutzer hat nicht mal Admin-Rechte auf seinem eigenen Notebook.)
Es macht wesentlich mehr Spaß, für jemanden ein angepasstes System zusammenzustellen, als ständig Windows-Kisten zu flicken, an denen der Konzern, der die Software verbrochen hat, einen Haufen Geld verdient, wobei ich den Ärger habe.
> Muss Linux für die ganzen Anbieter von Kommerz-
> Software überhaupt einen Markt bieten? Ich rede hier
> jetzt nicht von Wissenschaftlichen Programmen wie
> Mathematica (die haben mit der Linux-Unterstützung
> lustiger Weise irgendwie keine Probleme, wenn sie denn
> wollen), sondern von z. B. den von dir Angesprochenen
> 3€-Spielen, etc. pp.
> Wie gesagt: Es gibt kaum noch einen Bereich, der
> nicht gut mit Open Source-Programmen abgedeckt ist.
Nenne mir bitte ein Open Source Programm mit dem man Rommé (ein Kartenspiel) spielen kann.
Ich habe bis heute kein gutes gefunden.
Unter Windows gibt es duzende Romméspiele zum Kaufen.
Und was ist mit den High-End A+ Spielen?
Die hätte ich auch gerne unter Linux.
Und das Open Source Konzept funktioniert auch gar nicht überall.
Gerade Spiele mit Story gehören da nicht dazu.
Denn eine OSS Entwicklung dauert eine Ewigkeit,aber das Spiel ist in 10 h durchgespielt.
Es braucht hier also ein anderes Entwicklungsmodell, wenn man den Konsumenten dauerhaft auf Laune halten möchte.
Es reicht einfach nicht, wenn man ihm nur ein Open Source Adventure hinsetzt mit dem er sich dann ein ganzes Jahr beschäftigen soll.
Das würde nur funktionieren wenn es möglich wäre, ständig vollwertige High End Open Source Spiele herauszubringen, aber dann müßten die Entwickler Vollzeit arbeiten und damit wären wir beim Lieben Geld.
Denn die Entwickler brauchen ja auch etwas zum Essen.
Im Klartext: Bei High End Spielen funktioniert das Open Source Konzept nicht.
> Wer absolut nicht in der Lage ist, mal alternative
> Programme für den gleichen Verwendungszweck zu
> finden und zu verwenden, wird meiner Ansicht nach
> sowieso kaum mit Linux glücklich werden.
Es gibt durchaus Programme zu denen es kein Open Source Pendant gibt, das auch nur annähernd an den Funktionsumfang und an die Qualität herankommt.
Bei Videoschnittsoftware könnten wir hier anfangen.
> Warum soll Linux genau die Leute als Zielgruppe
> haben, die lieber Windows oder Mac möchten? Die
> Leute, die der Meinung sind, sie würden Linux dann
> benutzen, wenn es sich bedienen lässt, wie Windows,
> sollen doch bittebitte bei Windows bleiben.
> Ich bin der Meinung, dass verschiedene
> Betriebssysteme für verschiedene Arten von Nutzern
> da sind.
Und schon wieder Schwachsinn.
Bitte bringe nicht Plattformfeeling und Anwendungsangebot durcheinander.
Ein OS wie Linux darf sich anders anfühlen und verhalten als Windows, aber dennoch muß es ein gleich gutes Anwendungsangebot haben wie Windows.
Denn die Kernaufgabe eines Betriebssystems ist es, eine Abstraktionsebene für die darunterliegende Hardware anzubieten auf dem dann Anwendungsprogramme aufsetzen können.
Es ist nicht die Aufgabe eines Betriebssystems die Benutzer in ideologische Anwendungsgruppen aufzuteilen!
Aus diesem Grund muß Linux jede Art von Anwendungssoftware bieten, die auch Windows bietet.
Sprich, auch Linux braucht nen Bowser, eine Textverarbeitung, ein E-Mailprogramm, Videoschnittsoftware, Spiele usw.
Es geht nicht, daß du z.B. den Browser und die Textverarbeitung einfach wegläßt mit der Begründung, daß es in der Linuxusercommunity nicht üblich wäre, im Internet zu surfen.
Nur so mal zur Veranschaulichung als Beispiel.
Linuxuser haben die gleichen Bedürfnisse wie Windowsuser. Auch sie wollen ihre Videos auf ihrem OS schneiden können.
> Stattdessen stellt ein System mit PAPPI verschiedene (starre) Fähigkeiten und Schnittstellen bereit, die den Programmen als Laufzeitumgebung dienen.
Nein, so weit geht das Konzept nicht mal. PAPPI ist ein einfaches Shell-Script das mittels Zenity Dialog-Boxen anzeigt und die heruntergeladenen Pakete einfach entpackt. Das einzige derzeit verfügbare Paket (Open Sonic) bringt seine kompletten Libraries selbst mit. PAPPI kümmert sich weder um Architekturen (das Paket ist für x86 gebaut, Ich habe x86_64) noch um Sicherheit oder sonstwas. Der Autor liße verlauten dass diese Features Ihn derzeit nur bei der Entwicklung stören würden.
0install erscheint mir da deutlich intelligenter.
Das Skript "pappi" ist tatsächlich ein relativ dummes Shellskript.
Das Konzept ist aber nicht vollständig in dieser einen Datei implementiert. Wirft man einen Blick in das "install.sh" - Skript, sieht man, dass dort Pakete installiert werden. Diese stellen praktisch die Laufzeitumgebung dar.
Der größte Teil des Konzepts ist ohnehin noch nicht in Quelltext gegossen. Deswegen wird es wohl als "proof of concept" bezeichnet.
Wenn man sich das Video anschaut, sieht man dass schon eine Reihe von Paketen bestehen, die leider aus rechtlichen Gründen nicht zur Verfügung gestellt werden können.
> Wenn man sich das Video anschaut, sieht man dass schon eine Reihe von Paketen bestehen, die leider aus rechtlichen Gründen nicht zur Verfügung gestellt werden können.
Nett dass der Autor hier auch schreibt
Es wäre mal nett zu hören was außer der Emulator-Geschichte jetzt an PAPPI besser ist als an andere App Stores und Lösungen wie 0install. Und warum es nicht möglich war diese anderen Lösungen deinen Wünschen gerecht anzupassen.
Definiere besser: "Kann mehr?", "Ist schneller?", "Ist kompakter?"
PAPPI ist einfacher. Es gehörte nicht viel dazu, es zu entwickeln. Man muss nicht viel können, um ein Paket zusammenzuschrauben. Man braucht keine tief greifenden Kenntnisse. Wenn man ein Programm bei sich zum laufen bekommt, kann man es auch verpacken.
Trotzdem erfüllt es seinen Zweck gut. Das Zusammenspiel mit einem App Store, der eine reine Webanwendung darstellt, klappt wunderbar.
Es lässt sich sehr leicht anpassen. Das wird vor allem dann wichtig, wenn man es zum Beispiel in eine HTPC integrieren will oder eine Linux-Spielkonsole bauen möchte.
Ich erhebe hier keinen Anspruch ein toller Entwickler zu sein. Ich mache mir nur Gedanken darüber, wie man den Nutzern das bestmögliche bieten kann und beschreite den einfachsten Weg dahin.
> Technisch gesehen arbeitet der Installer (PAPPI) in
> Verbindung mit dem App Store völlig unabhängig von
> der Paketverwaltung.
> Auch in der Zielsetzung unterscheidet sich PAPPI und
> das "App Store"-Konzept stark von der Paketverwaltung.
Firmen von Closed Source Anwendungen wollen aber gar keinen Appstore.
Denn ein Appstore bedeutet doch nur, daß unter der Rubrik
Skatspiele gleich 20 verschiedene Konkurrenten aufgeführt werden, die ebenfalls ein Skat Spiel anbieten.
Warum soll man sich als Unternehmen das antun und der Konkurrenz auch eine Chance lassen?
Nein, das beste Appstore ist das, bei dem man das Alleinstellungsmerkmal und keine Konkurrenz hat.
So etwas ist aber praktisch nicht möglich, es sei denn man kümmert sich selbst um ein eigenes Appstore Konzept und genau so wird es auch gemacht.
Bsp.
Es gibt verschiedene Antivirensoftwarehersteller die auch Produkte für Linux anbieten.
Aber keiner von denen will in ein allgemeines Appstorekonezpt rein.
Die bieten alle ihre eigene Softwarevertriebsplattform an.
Fazit:
Was bei Open Source mit Paketmanagern funktioniert, muß bei Closed Source noch lange nicht funktionieren, da es politisch gar nicht gewollt ist.
Firmen von Closed Source Anwendungen wollen aber gar keinen Appstore.
Denn ein Appstore bedeutet doch nur, daß unter der Rubrik
Skatspiele gleich 20 verschiedene Konkurrenten aufgeführt werden, die ebenfalls ein Skat Spiel anbieten.
Warum soll man sich als Unternehmen das antun und der Konkurrenz auch eine Chance lassen?
Ja, deshalb werden solche Spiele auch nie in Elektronik oder Spielemärkten verkauft, denn da würden die ja auch nach Kategorien sortiert im Regal landen.
> Ich sehe schlicht und einfach nicht die Notwendigkeit, für Programme Geld zu bezahlen.
Wie arm bist du?
Gute Programme verdienen es, das man dafür Geld ausgibt.
Die Entwickler wollen schließlich auch von etwas leben.
Das kostenlose Open Source Programme deine Anforderungen erfüllen ist ja ok, aber generell zu sagen, daß man für Software nichts bezahlen will ist einfach Schwachsinnig.
Unter Windows raubkopierst du also wohl, denn du willst für Software ja kein Geld ausgeben.
Mit anderen Worten, für dich hat Software keinen Wert.
Das drückst du mit deinem Satz all zu deutlich aus.
denn gerade dort bietet sich ein Markt, der mit den "Apple Apps" konkurieren muss. Viele der Kunden eines solchen Telephons sind bereit, für "Apps" zu zahlen - sie kennen es nicht anders. Und grundsätzlich ist am Geschäftsmodell "Software gegen Geld" Nichts falsch. Den Massenmarkt erreicht man wohl besser durch praktische Lösungen, als dirch ideologische Überlegungen, daher: Daumen hoch
Andererseits wäre mir ein Programm, mit dem ich von meinem PC auf Android Telephone zugreifen kann, noch viel wichtiger. Dass es noch nichts Derartiges gibt (zumal wir derzeit alle recht "nahe" Kernel benutzen) ist schon bestürzend.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 15. Feb 2010 um 10:25.Was hat Android mit diesem Posting zu tun?
Gute Frage. Wie konnte ich bei den Stichworten Linux und App Store nur auf das Handy-OS Android kommen? Manchmal verstehe ich meine Assoziationsketten selbst kaum ...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 15. Feb 2010 um 11:53.Android hat mit Linux konkret gar nichts zu tun. Die Anwendungen würden außerhalb der Android-Umgebung gar nicht laufen.
Hmmmm - Android 1.5 (Firmware Version meines Handys) läuft auf und mit dem Linux Kernel 2.6.27.
Es mag nix mit GNU zu tun haben, aber ich denke, dass es ALLERHAND mit Linux zu schaffen hat.
> Android 1.5 (Firmware Version meines Handys) läuft auf und mit dem Linux Kernel 2.6.27.
Hast du dich mal näher mit der Plattform beschäftigt? Sämtliche Anwendungen laufen in der Dalvik-VM, einer Java-Abart, nur gelegentlich wird mittels NDK direkt auf das darunter liegende System zugegriffen. Android abstrahiert das Betriebssystem völlig, der Linux-Kern kann theoretisch morgen gegen etwas Anderes ausgetauscht werden.
Google hat darüber hinaus quasi alle gewohnten Userspace-Lösungen (GNU oder nicht) gegen eigene Ideen ausgetauscht und Kernel-Erweiterungen eingeführt die es sonst nirgends gibt.
Das ist am Ende ein proprietäres System.
http://de.wikipedia.org/wiki/Propriet%C3%A4r
Android ist zwar eigenartig, aber schon frei, oder? Und ein Linux Kernel kommt auch zum Einsatz. Klar man könnte den Austauschen. Aber ich kann auch den linux Kernel auf meinem Laptop gegen ein BSD Kern austauschen und hätte trotzdem noch freie Software drauf am laufen.
... die Lösung heißt "LSB". Es ist an den Herstellern von Drittsoftware, entweder ihre Anwendungen dagegen zu linken, oder aber Verbesserungsvorschläge zu machen, falls ihnen etwas fehlt. Der dreiundneunzigste Installeransatz mit "jetzt noch runderen Rädern" ist jedenfalls keine Option. Vor allem dann nicht, wenn er einen Rückschritt darstellt, selbst in der Nische, die er ausfüllen möchte.
lg
Erik
> ... die Lösung heißt "LSB".
Dazu fällt mir ein:
- Abgespeckte RPM-Version als Paketformat vorgeschrieben, wer das nicht will muss einen Binär-Installer ausliefern
- Schreibt SYS V Init vor
- Keine Bash
- Multimedia beschränkt sich auf die libasound und OpenGL
- /sys und /proc sind nicht spezifiziert
- Keine Hardware Specification für ARM, die nach x86 und x86_64 wichtigste Architektur
- Nur Python und Perl als Script-Sprachen
- Nur gzip, kein bzip2
Man hat als Hersteller zwar eine definierte Umgebung, aber die ist schon sehr eingeschränkt.
Jupp, kein Wunder, dass sich niemand an die Spezifikationen hält.
wenn die LSB so viele lücken aufweißt, warum setzt man sich nicht mal wieder zusammen und schließt diese? (nur nur "daran arbeiten")
das heißt dann aber auch sich auf einen einheitlichen Packetmanager zu einigen. ob das nun dpkg oder rpm (oder auch ein anderer/neuer) ist dürfte den meisten egal sein. Nur hätten wir dann mal ne Basis um Konkurenzfähig zu werden, das jeder bastelt seinen eigenen schrott funzt auf dauer nicht!
Wenn man das mal hätte könnte man daran gehen Programme zu Entwickeln die Softwarepackete im Homeverzeichnis installieren.
> sich auf einen einheitlichen Packetmanager zu einigen
Einheitslösungen funktionieren nie. Die Paketmanager sind auch gar nicht das Problem.
> hätten wir dann mal ne Basis um Konkurenzfähig zu werden
Öhm konkurrenzfähig gegenüber wem genau? Windows? Die haben nicht mal ein Paketmanagement...
> Programme zu Entwickeln die Softwarepackete im Homeverzeichnis installieren
Warum sollte man das denn bitte wollen? Damit jeder User eine andere Version der gleichen Software manuell installiert, keine Updates eingespielt werden, die Backup-Medien sinnlos vollaufen und der Administrator das Durcheinander auch noch supporten muss?
Es wurde hier schon oft geschrieben: Korrektes Packaging ist Aufgabe des Herstellers oder der Distribution, viele Hersteller machen das auch schon richtig, und wenn ein Hersteller es falsch macht dann muss man dem eben klar machen wie es richtig funktioniert - und nicht Krücken-Lösungen erfinden oder ewig die gleich falschen Argumente verbreiten.
>Die Paketmanager sind auch gar nicht das Problem.
Natürlich sind sie das Problem. Wenn sie einheitlich wären, dann bräuchte man nurnoch ein Packet pro Prozessorarchitektur bauen und jeder könnte es nutzen. Man kann den Riesenaufwand für jede Distri ein Packet zu bauen nicht an die Entwickler abwälzen. Das gilt nicht nur für für propärietäre Entwickler sonder auch für Hobby entwickler die sich dann viel Arbeit sparen. Man kann auch nicht von jedem User (v.a. Anfänger) erwarten sich ein Programm selbst zu bauen
>Windows? Die haben nicht mal ein Paketmanagement...
Nein hab sie nicht, aber die Installation von Programmen geht einfacher (zumindest gegenüber von Programmen, die nicht in den Distri-Repos liegen)
>Warum sollte man das denn bitte wollen?
gut das ist ein Punkt, andererseits kann dann der Admin auch sagen wenn ihr Software im Homeverzeichnis Installiert, müsst ihr euch selbst darum kümmern. Die Sicherheit des restlichen Systems ist dadurch ja nicht gefährdet. Man davon abgesehen dass das auch jetzt schon geht, nur ohne Packetmanager (siehe FF binärpacket von der Homepage). Mit Packetmanager der das kann hat man dann den Vorteil, dass man es leicht wieder los wird und man es updaten kann. Fedora wollte imo in ihr letztes Release so ein System einbauen nur war es eben noch nicht fertig bzw. man konnte die Packete nicht mehr loswerden.
> Natürlich sind sie das Problem. Wenn sie einheitlich wären, dann bräuchte man nurnoch ein Packet pro Prozessorarchitektur bauen und jeder könnte es nutzen
Nein, das sind sie nicht.
Wenn sie einheitlich wären, dann hättest du weiterhin das Problem mit unterschiedlichen Bibliotheksversionen auf jeder Distribution die binär zueinander inkompatibel sind.
>Die Paketmanager sind auch gar nicht das Problem.
Natürlich sind sie das Problem. Wenn sie einheitlich wären, dann bräuchte man nurnoch ein Packet pro Prozessorarchitektur bauen und jeder könnte es nutzen. Man kann den Riesenaufwand für jede Distri ein Packet zu bauen nicht an die Entwickler abwälzen. Das gilt nicht nur für für propärietäre Entwickler sonder auch für Hobby entwickler die sich dann viel Arbeit sparen. Man kann auch nicht von jedem User (v.a. Anfänger) erwarten sich ein Programm selbst zu bauen
>Windows? Die haben nicht mal ein Paketmanagement...
Nein hab sie nicht, aber die Installation von Programmen geht einfacher (zumindest gegenüber von Programmen, die nicht in den Distri-Repos liegen)
>Warum sollte man das denn bitte wollen?
gut das ist ein Punkt, andererseits kann dann der Admin auch sagen wenn ihr Software im Homeverzeichnis Installiert, müsst ihr euch selbst darum kümmern. Die Sicherheit des restlichen Systems ist dadurch ja nicht gefährdet. Man davon abgesehen dass das auch jetzt schon geht, nur ohne Packetmanager (siehe FF binärpacket von der Homepage). Mit Packetmanager der das kann hat man dann den Vorteil, dass man es leicht wieder los wird und man es updaten kann. Fedora wollte imo in ihr letztes Release so ein System einbauen nur war es eben noch nicht fertig bzw. man konnte die Packete nicht mehr loswerden.
>Die Sicherheit des restlichen Systems ist dadurch ja nicht gefährdet.
Bugs die dir root rechte geben könnten?
> hätten wir dann mal ne Basis um Konkurenzfähig zu werden
Öhm konkurrenzfähig gegenüber wem genau? Windows? Die haben nicht mal ein Paketmanagement...
Dafür aber einen funktionierenden Mechanismus, Software von Drittanbietern zu installieren.
wenn die LSB so viele lücken aufweißt, warum setzt man sich nicht mal wieder zusammen und schließt diese? (nur nur "daran arbeiten")
das heißt dann aber auch sich auf einen einheitlichen Packetmanager zu einigen. ob das nun dpkg oder rpm (oder auch ein anderer/neuer) ist dürfte den meisten egal sein. Nur hätten wir dann mal ne Basis um Konkurenzfähig zu werden, das jeder bastelt seinen eigenen schrott funzt auf dauer nicht!
Wenn man das mal hätte könnte man daran gehen Programme zu Entwickeln die Softwarepackete im Homeverzeichnis installieren.
> - Multimedia beschränkt sich auf die libasound und OpenGL
> Man hat als Hersteller zwar eine definierte Umgebung, aber die ist schon sehr eingeschränkt.
Das ist aber kein Problem.
Denn die LSB bietet eine gemeinsamme Basis.
Wenn du noch zusätzliche Bibliotheken brauchst.
Z.B. OpenAL, dann führst du diese einfach mit deinem Programm im Programmverzeichnis mit, aber du baust deine OpenAL Lib auf das bestehende LSB Basisystem auf.
Wenn closed source im buildservice verwendet werden soll,
dann liefern Die eben object code aus und
lassen den auf dem buildservice einfach nur linken.
Und wenn man bezahlen muss,
muss man zum Freischalten eben einen Lizenzschlüssel eingeben.