staging.inyokaproject.org

Ich bin auch für die Erläuterung an einem Beispiel. Welche exotische Software läuft denn z.B. bei openSUSE, die es nicht für Ubuntu gibt? Mir fällt da auf Anhieb nur yast ein, aber das vermisse ich nun wirklich nicht... 😉

Das Wort schrieb:

[...]

Auch ich sage Danke für die Riesenantwort.

nightsky schrieb:

Also im Prinzip hast du Recht, das mit den hundert Paketformaten ist nicht das Gelbe vom Ei.

Die Paketformate sind relativ unproblematisch. Da kann man entweder ein Programm wie epm benutzen, das mehrere Paketformate erzeugen kann, oder die Pakete mit alien konvertieren.

Problematischer sind da die unterschiedlichen Versionen der Bibliotheken usw. die auf den verschiedenen distributionen eingesetzt werden, und bestimmte distributions-abhängige Eigenheiten.

Viele Leute sehen das auch als eines der großen Probleme von Linux, denn wenn sich ein Entwickler die Frage stellt, ob er sein Programm auch für Linux anbieten will, dann denkt er sich gleich "oh, aber dann muss ich ja ziemlich viele verschiedene Pakete machen..." Denn es soll ja auf Debian Squeeze ebenso laufen wie auf Ubuntu, oder Suse, oder Arch Linux....

Unter Linux ist es üblich, sich die Arbeit zu teilen: Der Entwickler entwickelt, und der Distributor verpackt und verteilt. Die meisten Entwickler stellen ihre Software daher nur als Quellcode zur Verfügung, und vielleicht noch Pakete für die Distribution und Plattform, die sie selbst benutzen.

Da Linux auf so vielen unterschiedlichen Hardware-Architekturen läuft (Debian/Linux gibt es für 18 Architekturen), und die meisten unter Linux verwendeten Programme auch auf anderen unix-ähnlichen Betriebssytemen (*BSD, Solaris, OS X, ...), funktionieren, kann ein Entwickler da auch im besten Fall nur die verbreitetsten Fälle selbst abdecken.

Projekte wie Firefox verteilen Programmpakete, die entweder ausreichend alte Versionen von Bibliotheken voraussetzen oder passende Versionen direkt dabei haben und sich nut wenig um distributions-spezifische Eigenheiten kümmern. Das heißt für die Entwickler aber auch, dass sie sich bei allen mitgelieferten Bibliotheken usw. um Updates kümmern müssen, wenn kritische Fehler bekannt sind. Und als Anwender bekommt man da halt z.B. keine Unity-Integeration.

Astorek schrieb:

Mal sollte auch nicht vergessen, dass das Paketmanagement-System so erfolgreich ist, dass mittlerweile sogar Microsoft es in Win8 über den Store übernommen hat.

Jein. Die Stores sind einer echten Paketverwaltung nicht ebenbürtig. Dabei geht es vielmehr darum dass man Alles an einer Stelle findet und von einer authorisierten Stelle bekommt. Bei einer Paketverwaltung ist es aber irrelevant ob es sich um eine Quelle handelt.

Eine gute Abhängigkeitsverwaltung gibt es auch nicht. Meist hat man ein großes Paket (Android: apk, AppStore: app, Windows Store: exe (?)) deren Abhängigkeiten entweder im Paket enthalten sind, oder man muss manuell etwas nachinstallieren.

Bei Apple ist es meist so dass die .app-Dateien sog. Universal-Binarys sind. Das heißt das 32-bit und 64-bit in einem Paket sind. Und früher auch für intel und PPC. Bei der Installation wird einfach ein Verzeichnis in /Applications angelegt und darin befinden sich dann auch benötigte Bibliotheken, das heißt auch dass Bibliotheken oft mehrmals installiert sind. Für den Endanwender ist das natürlich toll, da er nur ein Verzeichnis löschen muss (/Applications/Magic_App). Bei Linux / konservativen Unix sind die in /lib, /usr/bin, /bin, etc… verstreut.

Auch wird immer das ganze .app-Paket bei der Aktualisierung heruntergeladen. Wenn sich eine Bibliothek ändert muss bei Apple das ganze Paket herunter geladen werden. Bei Linux wird dann nur das Paket der Bibliothek aktualisiert, das Paket der Anwendung nicht. Bei Spielen gibt es Pakete die auch mehrere hundert Megabyte groß sein können, etwa weil darin die Texturen sind. Leider wird da momentan noch das ganze Paket heruntergeladen. Das heißt wenn sich 10% der Texturen ändern lädt man 90% des Pakets umsonst herunter.

Delta-Updates sind da die Lösung, dort wird nur der Teil herunter geladen der sich wirklich geändert hat. In apt ist das leider noch nicht drin. Ich glaube Google plant das auch schon seit langem, aber bisher gibts die noch nicht. Für apt gibt es zwar Möglichkeiten delta-Updates zu laden, allerdings ist das nicht gut integriert bzw. offiziell und damit auch immer etwas später.

Edit: Apple gibt mittlerweile Delta-Updates für deren Sicherheitsaktualisierungen heraus. Aber nicht im App-Store. Android macht das auch, aber nur bei Systemaktualisierungen (Over the Air…), nicht aber bei den Anwendung. \edit Ebenso bei Windows seit XP. \end2

Bei echten Paketverwaltungen gibt es auch keinen Unterschied zwischen Systemupdates und Anwendungsaktualisierungen. So empfinde ich das und nutze das um zwischen einem Store-System und einer Paketverwaltung zu unterscheiden.

Die Software gibts übrigens. Bei RPM ist es dabei. Für Debianpakete gibt es apt-sync und deb-delta.

Link zum Thema: Thread auf AskUbuntu

Button drücken, schon werden aktualisierte Versionen heruntergeladen und vollautomatisch installiert...

Eigentlich überflüssig. Ich lass das automatisch machen. Ich habe seit mehr als 15 Monaten nicht mehr Updates eingespielt. Letztens saß ich dann an einem Windows und ein Adobe-Produkt (Reader oder Flash, naja vielleicht auch Java). Als ich das Popup-Fenster gesehen habe habe ich mich selbst gefragt warum ich auf meinem System eigentlich keine Aktualisierungen brauche, bis mir eingefallen ist dass mein System das vollständig und ohne Interaktion macht ☺

Das Wort schrieb:

bis mir eingefallen ist dass mein System das vollständig und ohne Interaktion macht ☺

Ich möchte schon wissen was wann abläuft, man fühlt sich dann einfach sicherer.

barzefutz schrieb:

Warum selber kompilieren? Gibt es nicht vorkompilierte Programme? Wenn ich z.B. den Firefox als .tar.gz runterlade, muss ich das dann kompilieren?

Dafür gibt es eben die Repros oder auch PPAs. Dort ist eben schon alles, mehr oder weniger, vorkonfiguriert und ablauffähig. Der Firefox nimmt dabei eine Sonderstellung ein - siehe nächsten Punkt. Eine wichtige Unterscheidung ist z.B., ob der Rechner mit einem 32- oder 64 Bit-System läuft. Auch die installierte Hardware spielt dabei eine Rolle. Der Standard-Kernel berücksichtig z.B. "jede Menge" Hardware, während man sich beim selbst kompilieren nur auf die tatsächliche Umgebung konzentrieren kann.

Und zu den Abhängigkeiten: Sind das denn immer so viele? Es kommt doch bestimmt auch vor dass es gar keine Abhängigkeiten gibt. Bei Firefox z.B. dürfte es doch nicht so viele geben. Oder bei irgendwelchen kleinen Tools doch auch eher nicht.

Du hast schon mal die "Frikeltools" angeschnitten. Die Philosophie bei Linux ist eigentlich "ein Programm für einen Aufgabe" und das richtig und gut (klappt nicht immer, dennoch).

Ein Beispiel: Es gibt viele Programme die mit der Videobearbeitung zu tun haben. Viele davon setzen dabei auf ffmpeg auf und legen einfach eine GUI darüber. Intern wird dann ffmpeg mit den entsprechenden Parametern aufgerufen und macht eben das, was man erwartet. Unter Windows gibt es z.B. ein Tool namens SUPER oder WinFF (auch für Linux), die auch auf dieses Frickeltool aufbauen. Man spart sich also das selbst erfinden des Umkodierens. Unter Windows gibt es viele Programme, die mehr oder weniger autonom funktionieren und dabei immer wieder "das Rad" neu erfinden - unter Linux kaum bzw. selten (bei Videos gibt es neben ffmpeg auch noch das Projekt mplayer), da man versucht auf dem Bewährten aufzubauen und diese Programme als Unterprogramme nutzt (= Abhängigkeiten).

Beim Firefox geht man auch nach diesem Schema vor. Das was den Grundbrowser ausmacht, das baut nicht auf irgendwelchen externen Programmen auf, sondern ist reines Firefox-Gedöns (Gecko, xul, Libraries oder DLLs etc.), daher ist er zum "surfen" bereits einsatzfähig. Das integrierte Plugin-System öffnet den Broweser aber für diese "Frickeltools", d.h. man kann sie dort einbinden und ausführbar machen. Dadurch kann man z.B. "Flash", oder "PDF-View", oder den "Video-Downloader inkl. Konvertierung (auf Basis von ffmpeg) der Audio-/Video-Dateien benutzen usw. Da der Firefox für verschiedene Platformen entwickelt wird, sieht er nach aussen immer gleich aus, obwohl intern, je Platform, andere "Frickeltools" bzw. andere Zuriffsformen auf diese ausgeführt werden.

Hinweis: Das oben genannte ist eine Vereinfachung um es anschaulich zu gestalten.

Aber das mit den Abhängigkeiten kann doch auch Nachteile mit sich bringen. Nehmen wir mal an, ich habe so ein Videoschnittprogramm, was ffmpeg benutzt. Dann update ich irgendwann mein System und das ffmpeg wird mit geupdatet. In der neuen Version von ffmpeg haben sich dann aber die Kommandozeilenparameter geändert und mein Schnittprogramm funktioniert plötzlich nicht mehr.

Wenn dagegen beide Programme, also das Videoschnittprogramm und ffmpeg, als "Bundle" ausgeliefert werden, gibts dieses Problem ja nicht mehr, weil dann sichergestellt ist, dass beide Tools in der jeweiligen Version zusammenarbeiten.

Hat also alles seine Vor- und Nachteile, oder?

-totschka- schrieb:

Ich bin auch für die Erläuterung an einem Beispiel. Welche exotische Software läuft denn z.B. bei openSUSE, die es nicht für Ubuntu gibt? Mir fällt da auf Anhieb nur yast ein, aber das vermisse ich nun wirklich nicht... 😉

Habe da leider kein konkretes Beispiel. Das Problem ist bei mir glaube ich noch nie in echt aufgetreten, außer in meinem Kopf 😉

Mir fällt schon wieder eine neue Frage ein, diesmal bezüglich der Desktopumgebung: Kann es auch sein, dass ein Programm z.b. mit GNOME funktioniert, aber mit XFCE nicht?

barzefutz schrieb:

Hat also alles seine Vor- und Nachteile, oder?

Nahezu alles hat Vor- und Nachteile. In Sachen Paketverwaltung finde ich, dass die Vorteile überwiegen. Andere mögen andere Prioritäten haben und das anders sehen.

barzefutz schrieb:

Mir fällt schon wieder eine neue Frage ein, diesmal bezüglich der Desktopumgebung: Kann es auch sein, dass ein Programm z.b. mit GNOME funktioniert, aber mit XFCE nicht?

Das ist mir noch nicht passiert. Die Paketverwaltung löst alle Abhängigkeiten auf und installiert eben die paar hundert MB für ein halbes Gnome (oder KDE, kommt auf die Anwendung an) eben gleich mit, falls man ein Gnome- oder KDE-Programm unbedingt in XFCE haben will. 😉

barzefutz schrieb:

Aber das mit den Abhängigkeiten kann doch auch Nachteile mit sich bringen. Nehmen wir mal an, ich habe so ein Videoschnittprogramm, was ffmpeg benutzt. Dann update ich irgendwann mein System und das ffmpeg wird mit geupdatet. In der neuen Version von ffmpeg haben sich dann aber die Kommandozeilenparameter geändert und mein Schnittprogramm funktioniert plötzlich nicht mehr.

Bei einem Systemupdate bekommst du aber auch eine neue Version des Schnittprogramms und in der Regel schauen die Maintainer der Programme nach ob solche Fehler auftreten. Haarig wird es eigentlich nur, wenn du z.B. per PPA FFMPEG aktualisiert und das Schnittprogramm nicht und es tatsächlich eine Änderung der Parameter gibt. Dann muss man wohl oder übel darauf hoffen, dass es auch eine neuere Version des Schnittprogramms per PPA gibt (Am besten kommen dann beide Programme aus dem gleichen PPA).

Wenn dagegen beide Programme, also das Videoschnittprogramm und ffmpeg, als "Bundle" ausgeliefert werden, gibts dieses Problem ja nicht mehr, weil dann sichergestellt ist, dass beide Tools in der jeweiligen Version zusammenarbeiten.

Das ist richtig. Das betrifft aber nur eine Installation eines externen Programms, das sich am Paketmanager vorbeiinstalliert. Hat man das Programm dagegen als passendes Paket für die verwendete Distributionsversion vorliegen, kann man eigentlich sicher sein, dass das Programm mit der System-eigenen Version von FFMPEG zusammenspielt.

Hat also alles seine Vor- und Nachteile, oder?

Natürlich. Für mich überwiegen aber auch die Vorteile die Nachteile. Ich könnte jedes Mal kotzen, wenn ich bei einem Bekannten nach dem Rechner (Windows) schauen soll, das Problem innerhalb von fünf Minuten löse und dann mindestens eine Stunde beschäftigt bin, alle vorhandenen Programme auf den aktuellsten Stand zu bringen.

Kann es auch sein, dass ein Programm z.b. mit GNOME funktioniert, aber mit XFCE nicht?

Nicht das mir so ein Fall jemals untergekommen ist.

barzefutz schrieb:

Hat also alles seine Vor- und Nachteile, oder?

Wie V for Vortex bereits schrieb:

Nahezu alles hat Vor- und Nachteile. In Sachen Paketverwaltung finde ich, dass die Vorteile überwiegen. Andere mögen andere Prioritäten haben und das anders sehen.

Aber auch Dein angeschnittenes Problem (Optionenänderungen) hat eine Lösung gefunden und nennt sich Abwärtskompatibilität.

• Neue Funktionen werden integriert, aber die alten bleiben erhalten.

  • Selbst bei einer Umbenennung von Optionen (aus welchen Gründen auch immer) findet man neben dem neuen Optionsbezeichner auch noch den "alten" und kann diesen auch nutzen.

• Bei dem Beispiel Videoprogramm kenne ich auch oft die Möglichkeit, dass man sich die dahinterliegende Kommandozeile anzeigen lassen kann bzw. veränderbar ist.

Nichts desto Trotz gibt es auch Versionswechsel, die nicht mehr so ohne weiteres ablauffähig sind (z.B. Python 2>3 ?). Wobei dann auch die Frage aufkommt: "Wenn es schon eine neue,verbesserte Version gibt, warum sollte ich dann eine "alte" einsetzten bzw. auf ein veraltetes System setzen?"

glasenisback hat ebenfalls eine "guten" Grund für die "Frickelprogramme" genannt. Anstatt bei einem Update n-MB herunterzuladen, reicht oft eine kleiner KB-Update. Die entsprechende Datei wird einfach im laufenden System ausgetauscht, ohne das System neu zu starten, und man merkt so gut wie garnichts davon.

pitt-admin schrieb:

Ich möchte schon wissen was wann abläuft, man fühlt sich dann einfach sicherer.

Ich kenne apt lange genug um in etwa zu wissen wie es funktioniert und ihm zu vertrauen. Ich hatte noch nie Probleme mit apt wegen einer Aktualisierung. Wenn ich Probleme hatte dann immer weil ich etwas manuell gemacht habe 😉 Und außerdem gibt es ja die Log-Dateien wenn man die Aktualisierung eines Programmes nachvollziehen muss/will.

barzefutz schrieb:

Aber das mit den Abhängigkeiten kann doch auch Nachteile mit sich bringen. Nehmen wir mal an, ich habe so ein Videoschnittprogramm, was ffmpeg benutzt. Dann update ich irgendwann mein System und das ffmpeg wird mit geupdatet. In der neuen Version von ffmpeg haben sich dann aber die Kommandozeilenparameter geändert und mein Schnittprogramm funktioniert plötzlich nicht mehr.

Das ist dann aber eher das Problem eines schlechten Programmierers oder Maintainers (das ist die Person die ein Paket verwaltet) nicht ein Problem des Konzeptes Paketverwaltung.

Wenn dagegen beide Programme, also das Videoschnittprogramm und ffmpeg, als "Bundle" ausgeliefert werden, gibts dieses Problem ja nicht mehr, weil dann sichergestellt ist, dass beide Tools in der jeweiligen Version zusammenarbeiten.

Auch bei einer Paketverwaltung kann man ein Bundle anbieten, das hat halt den Nachteil es es mehr Speicherplatz braucht.

Im besten Fall möchte man dass ein Programm eine Dynamische Bibliothek verwendet. Das heißt im groben dass die Datei erst geladen wird wenn diese gebraucht wird.

Als Entwickler kann man sich auch entscheiden eine Bibliothek statisch zu verlinken, das heißt dass die Bibliothek teil des Programms wird. Der Nachteil ist dass du mehr Speicherplatz brauchst wenn die Bibliothek schon installiert wurde. Außerdem wird die Bibliothek auch in den Arbeitsspeicher geladen wenn diese gar nicht gebraucht wird, da diese ja Teil des Kompilats ist. Der Vorteil ist aber, dass dir völlig egal sein kann, was im Repository der Distribution vorhanden ist. Etwa eine andere Version oder gar nicht vorhanden. Wenn man also etwas entwickelt und will sich nicht die Mühe machen kann man Bibliotheken statisch verlinken, oder wenn man weiß das die neue Version der Bibliothek eine benötigte Funktion nicht mehr bereitstellt.

Statisches linken macht also nur Sinn wenn der Programmierer schlecht oder faul ist und gaaaanz seltenen anderen Fällen.

Bei Spielen (kommerzielle nicht die FOSS Spiele wie 0ad) unter Linux gibt es SEHR häufig den Fall das Bibliotheken statisch gelinkt sind weil das Spiel meist nur einmal entwickelt wird und danach noch Verkauft werden soll wenn die Versionen in den Paketquellen schon andere sind. Oder wenn man ein Spieleentwickler ist der proprietäre Software schreibt, sich aber nur um das Spiel und nicht um den Code kümmern will. Bei Freier Software kann jeder mit entsprechendem Wissen ein Paket erstellen.

Dieser Wunsch von Spieleentwickler ist völlig legitim, schließlich geht es bei Spielen um Geschichten und Erlebnisse, wenn man sich da noch um Sicherheitslücken kümmern müsste… 😉

Das Problem ist bei mir glaube ich noch nie in echt aufgetreten, außer in meinem Kopf 😉

Geht mir oft auch so, wenn du wüsstest wie oft ich hier schon Supporter mit theoretische Problemen in den Wahnsinn getrieben habe. barzefutz das ist ein gutes Zeichen und Teil des Lernprozesses, also höre bloß nicht damit auf 👍

Edit:

Dynamische Bibliotken werden auch bei Windows gerne eingesetzt. Der Name der .DLL-Dateien ist nicht ohne Grund dynamic linked libraries . Leider werden Programme bei Windows nicht in einer einheitlichen Verzeichnisstruktur installiert, weshalb es sein kann dass es eine Bibliothek zwar gibt, aber das Programm sich nicht finden könnte das sie nicht weiß wo diese ist. Denn wenn etwas unter C:\\Windows\Programms\Tolles_Programm_3000 installiert ist, weiß ein anderes Programm ja nicht dass dieses Programm die Bibliothek dabei hat geschweige denn wie das Programm(-ordner) heißt. Deshalb bringen Bei Windows viele Programme eigene DLLs mit. Bei Linux / Unix ist "alles" unter /lib, zumindest was die Bibliotheken angeht. Naja und /usr/lib für Programme der Anwender.

Aber auch bei Microsoft gibt es solche Verzeichnisse, allerdings halten sich viele Entwickler nicht daran. ☹

Edit2: Wenn du ein Programm an der Paketverwaltung vorbei installieren will das nutze ein/das opt-Verzeichnis. Denn wenn du die Sache in den normalen Verzeichnissen installieren willst, dann fällt zum einen Das erstellen eines Backups schwerer. Zum anderen kannst du dich und die Paketverwaltung verwirren! Naja hauptsächlich dich. 😉

glasenisback schrieb:

barzefutz schrieb:

Aber das mit den Abhängigkeiten kann doch auch Nachteile mit sich bringen. Nehmen wir mal an, ich habe so ein Videoschnittprogramm, was ffmpeg benutzt. Dann update ich irgendwann mein System und das ffmpeg wird mit geupdatet. In der neuen Version von ffmpeg haben sich dann aber die Kommandozeilenparameter geändert und mein Schnittprogramm funktioniert plötzlich nicht mehr.

Bei einem Systemupdate bekommst du aber auch eine neue Version des Schnittprogramms und in der Regel schauen die Maintainer der Programme nach ob solche Fehler auftreten.

Genau das was barzefutz schrieb ist mir auch schon passiert (das betraf damals kdenlive und ffmpeg bzw melt). Auch mit lame oder der Druckerverwaltung von KDE. Aber ich würde einen solchen Fehler nicht den Maintainern direkt in die Schuhe schieben. Es ist bei manchen Programmen einfach unmöglich zu schauen ob alle Optionen mit allen Programmen noch funktionieren. Ich sehe es mehr als ein Ressourcenproblem (zu wenige Tester).

glasenisback schrieb:

Wenn ich das jetzt mal mit Windows vergleiche, da ist es ja (fast immer) so, das ein und dasselbe Programm sowohl unter Windows XP als auch unter Vista und Windows 7 läuft.

Der Vorteil an einem Paketmanager ist, dass das System sich um die Aktualisierung aller dort registrierten Programme kümmert (Voraussetzung ist nur, dass das Paket per Paketquelle und nicht händisch installiert wurde). Das andauernde händische Aktualisieren, die nervigen Update-Popups der diversen Programme (Adobe, Java, Apple, usw.) existieren unter Linux nicht.

Tjo unter Windows habe ich die neueste Firefox Version, die Sicherheitslücken behebt dafür auch etwas schneller 😉. Hat alles seine Vor- und Nachteile.

Blubbie schrieb:

Tjo unter Windows habe ich die neueste Firefox Version, die Sicherheitslücken behebt dafür auch etwas schneller 😉. Hat alles seine Vor- und Nachteile.

Kannst Du mit Ubuntu auch haben, entweder bequem per PPA (= über die Paketverwaltung) oder manuell. Dabei sollte Dir aber das potentielle Risiko von Fremdquellen bewusst sein.