staging.inyokaproject.org

Hallo Diesch,

Deine Ausführungen finde ich sehr interessant. Was wäre wenn nur der Quellcode verteilt wird und jede Distribution liefert ein eigenes "Compilerzentrum" mit aus? Bräuchte man dann auch nur ein Mega-Repo für alles und es wird beim Nutzer kompiliert?

Dafür brauchst du einen standardisierte Möglichkeit, um angeben zu können, welche Umgebung (Software, Versionen, Architektur, ...) ein Paket benötigt und um beim Kompilieren unterschiedliche Möglichkeiten berücksichtigen zu können.

Je mehr Unterschiede dieses System berücksichtigen kann, desto einfacher und schneller werden sich die Distributionen auf Änderungen einigen können. Dafür muss man dann aber auch mehr Eigenschaften angeben, wenn ein Paket veröffentlichen will. Damit ein Paket tatsächlich auf möglichst vielen Distributionen funktioniert, müssen diese Angaben möglichst unbestimmt sein, also eher z.B. "benötigt libabc Version 3.0 bis 4.7" statt "benötigt libabc Version 3.4.2alpha3". Das herauszubekommen und zu testen wird sehr schnell sehr aufwändig.

Daher werden in der Praxis die meisten Autoren entweder Angaben machen, die sie nicht ausreichend überprüft haben ("wenn es mit libabc 3.0 und 4.7 funktioniert, dann bestimmt auch mit allen Versionen dazwischen"), oder die Angaben auf einige wenige Distributionen zuschneiden. Im ersten Fall lassen sich die Pakete zwar auf vielen Distributionen installierten, funktionieren aber nicht auf allen. Im zweiten Fall kannst du die Pakete auf nur wenigen Distributionen installieren, dafür funktionieren sie da aber auch. Letztendlich also kein großer Unterschied zu dem, was wir heute schon haben.

Alternativ kann man es den Autoren auch einfacher machen und die Möglichkeiten einschränken. Dann müssen sich die Distributionen aber auf diese wenigen Möglichkeiten einigen ("libabc gibt es nur in Version 3.8.2"), was entsprechend länger dauert und oft auf mehr oder weniger sinnvolle Kompromisse hinausläuft - also das gleiche Problem wie bei den Binärpaketen.

diesch schrieb:

Dazu reicht es nicht, sich auf ein einziges Paketformat zu einigen, die Distributionen müssten auch binärkompatibel sein und Abhängigkeiten und von Paketen genutzte Verwaltungstools müssten standardisiert werden. Eine Distribution könnte nicht einfach eine neue Version veröffentlichen (rolling Releases wären sowieso nicht möglich), sondern müsste dafür erst mal alle Änderungen mit allen anderen Distributionen abstimmen. Die nötige Kommunikation und Bürokratie würde eine Menge Zeit und Geld kosten, und das Ergebnis wären meistens halbgare Kompromisse, die sich auf Software beziehen, die vor 3 Jahren aktuell war.

Sinnvoll ist also eine Schwerpunktbildung um große Distributionen wie RedHat, Debian, Ubuntu und Suse.

Dankeschön, das wollte ich schon lange gefragt haben. Schönen Sonntag. ☺

Blubbie schrieb:

https://www.youtube.com/watch?v=Sh-cnaJoGCw

Endlich werden mal die Probleme angesprochen und das auf einer Linuxkonferenz 😉. Vor allem mit xorg hat er so recht, so schlecht und trotzdem entwickelt man nichts neues besseres

So wie Wayland?

Genauso mit den Paketmanagern? Welche großen Unterschiede gibts denn noch zwischen rpm und deb usw? Warum nicht auf eines einigen. Ein Programm nur einmal paketieren und es liefe auf alle Distros das wäre doch mal was 😉.

Na immerhin haben wir da nur zwei Standards. Keine schlafenden Hunde wecken, siehe user unknowns Beitrag. 😬

V for Vortex schrieb:

Blubbie schrieb:

https://www.youtube.com/watch?v=Sh-cnaJoGCw

Endlich werden mal die Probleme angesprochen und das auf einer Linuxkonferenz 😉. Vor allem mit xorg hat er so recht, so schlecht und trotzdem entwickelt man nichts neues besseres

So wie Wayland?

Genau das spricht das Video ja auch an, es geht diesbezüglich nichts vorwärts, der Einsatz von Wayland wird immer weiter hinausgezögert und letztlich weiterhin x.org eingesetzt.

Mit den Paketmangern waren Beispiele, nämlich die 2 am meist verbreiteten, natürlich gibts unzählige mehr, aber das ändert ja nix daran, dass es letztlich egal ist, welchen man einsetzt, hauptsache man einigt sich mal auf enien und diverse Libs, die überall vorhanden sind. Es ist einfach ein graus Software für Linux zu veröffentlichen, deshalb schreibt ja jeder Anbieter proprietärer Software ein eigenes Installskript, was dann das ganze außerhalb des Paketsystems installiert.

diesch schrieb:

, oder die Angaben auf einige wenige Distributionen zuschneiden. Im ersten Fall lassen sich die Pakete zwar auf vielen Distributionen installierten, funktionieren aber nicht auf allen. Im zweiten Fall kannst du die Pakete auf nur wenigen Distributionen installieren, dafür funktionieren sie da aber auch. Letztendlich also kein großer Unterschied zu dem, was wir heute schon haben.

Sinnvoll ist also eine Schwerpunktbildung um große Distributionen wie RedHat, Debian, Ubuntu und Suse.

Blubbie schrieb:

V for Vortex schrieb:

So wie Wayland?

Genau das spricht das Video ja auch an, es geht diesbezüglich nichts vorwärts, der Einsatz von Wayland wird immer weiter hinausgezögert und letztlich weiterhin x.org eingesetzt.

Nun gut, es ist grundsätzlich ersteinmal sinnvoll, Bewährtes beizubehalten, bis der geplante Ersatz wirklich funktioniert. Ansonsten habe ich zu wenig Ahnung von der technischen und personellen Lage Waylands, um die Entwicklungsgeschwindigkeit einschätzen zu können. Letztlich gehöre ich als Noch-10.04-Nutzer auch nicht unbedingt zur Hauptzielgruppe Waylands. 😉

Allgemein ist es halt schwierig, etablierte Techniken und Standards von Grund auf zu ersetzen. Das ist nicht nur im Computersektor so.

Mit den Paketmangern waren Beispiele, nämlich die 2 am meist verbreiteten, natürlich gibts unzählige mehr.

Mir persönlich wäre es schon homogen genug, wenn es nur diese zwei gäbe. Viele externe Anbieter beschränken sich ja so schon oft nur auf ein Format – wenn nicht gleich per eigenem Skript oder Binary, wie Du schon meintest.

Es ist einfach ein graus Software für Linux zu veröffentlichen

Und doch machen es eher mehr als weniger Entwickler. Bei den Humble Bundles – die ich fast alle besitze und deren Spiele ich durch Bindung an meinen dortigen Account in einer einzigen langen Liste angezeigt bekomme – sind geschätzt 2/3 neben .bin und .tar.gz auch als .rpm und .deb erhältlich, mit einer leichten Mehrzahl an deb-Paketen.

Blubbie schrieb:

Vor allem mit xorg hat er so recht, so schlecht und trotzdem entwickelt man nichts neues besseres, da müssten halt mald ie Distributoren zusammenarbeiten.

Ich weiß nicht wieso, aber ich persönlich habe es jetzt nicht so eilig, schon wieder die nächste Sau an Änderungen durch's Linuxdorf zu treiben. Ich komm mit Xorg und X-Forwarding super klar, mir fehlt da im Alltag absolut nichts. Auch die Leistung ist tip-top, kann da nicht meckern. Weiß gar nicht, was manche da haben - vielleicht gar kein Linux und nur mal irgendwo was gehört, was man kritisieren könnte? 😉

Welche großen Unterschiede gibts denn noch zwischen rpm und deb usw?

Das sind schon noch einige. Z.B. gibt es bei deb keine Delta-Updates, bei rpm schon. Das heißt, bei Änderungen muss nicht ein ganzes Paket neu heruntergeladen werden, sondern nur die Differenzen. Desweiteren kann man bei rpm mal eben schnell im Installationsbefehl eine andere Quelle angeben, was bei deb schon wieder mit Änderung an der sources.list(.d) vor und nach der Änderung, jeweils mit folgendem Listenupdate, verbunden ist.

Frag mal die Entwickler, warum sie nicht die Vorteile beider Methoden auf beiden Systemen anbieten. Wie man bei Gnome 2 sieht, hat das auch immer was mit Ressourcen (Entwickler) und Schwerpunkten bzw. gesehenen oder übersehenen Notwendigkeiten zu tun. Und vielleicht hat die Starrheit von deb in obigen Punkten auch ihre Vorteile, in dem man etwa eher den großen Pool an Programmen aus den Standardquellen nutzt und so andere Probleme vermeidet. Delta wird vielleicht als - für die Entwickler - zu komplex, wartungsaufwändig oder fehlerträchtig erachtet, wer weiß. Bzw. kann man nicht mal eben etwas komplett umstellen oder in solchen Details erweitern.

Warum nicht auf eines einigen. Ein Programm nur einmal paketieren und es liefe auf alle Distros das wäre doch mal was 😉.

Welches Problem hast du als Endanwender denn damit, dass es deb UND rpm gibt? Das kann dir doch eigentlich egal sein. Du gehst einfach in deine Paketverwaltung, klickst deine Software an und sie wird installiert. Gehst du auf eine Firmenhomepage, werden meist beide Formate für den Endanwender angeboten oder eine simple .tar.gz - gibt ja unter Windows neben exe auch com sowie zip, was entfernt vergleichbar ist.

Was man gewöhnt ist, möchte man nutzen. Man könnte doch auch den Mac-Nutzern sagen, nehmt Windows, ein System reicht doch. Aber sie sind etwas anderes gewöhnt und/ oder finden das WIE der Bedienung eines anderen Systems besser - oder dessen Optik oder Stabilität. Warum sollte das nun ausgerechnet bei Linux anders sein? Und wie ich schon schrieb, ich finde RPM aufgrund seiner Vorteile durchaus reizvoll, gewöhnt bin ich aber in der Breite und Tiefe der Optionen eher deb und das Ökosystem dieser deb-Systeme.

Da sitzt jeder Handgriff einfach besser, wie in der eigenen Westentasche. Man muss kaum nachschlagen. Und schau dir mal die Manpages zu den vielen Paketverwaltungstools an - da gibt es eine ganze Menge Unterschiede in der Syntax. Wenn man eine gewohnt ist, kann die andere zunächst völlig verwirrend wirken - man muss also häufiger etwas nachschlagen. Und da es nun mal historisch so entstanden ist, kann doch jeder das nehmen, was er mal gelernt hat oder das Paketformat des Systems, dessen Gesamtheit er am gelungensten findet.

Wenn man nun Ubuntu mit RPM betreiben möchte, müsste man sich vielleicht, damit das ordentlich läuft, mit LFS befassen, also sein eigenes Linux designen. Dann hätten wir aber wieder eine Variante mehr - die aber auch nur mehr ist durch eine neue Kombination aus der Summe von anderen Einzelteilen bzw. Einzelteilen in anderer Anordnung und Größe/ Gewichtung (als Beispiel etwa auch die ganzen Bootkonzepte wie System V, Upstart, Systemd). 😉

Wirklich Probleme macht die Vielfalt auch dem Admin oder Programmierer eigentlich nicht unbedingt. Wenn er ein anderes System einsetzen will oder muss, arbeitet er sich ein und entdeckt Parallelen und Unterschiede. Natürlich müssen beide mehr testen und anlesen, aber es heißt nun mal "lebenslanges Lernen". Da soll mal noch einer sagen, die "ollen Unixhasen" wollen nur nix neues lernen. 😉

Kennt man einmal 1-2 Konzepte, z.B. beim Booten oder bei Programmiersprachen, arbeitet man sich rasch auch in konkurrierende Konzepte ein. Ist ja nicht so, dass man da trotz der Unterschiede gleich wieder bei Null anfangen müsste und das alles ein so großes Problem wäre. Nichtsdestotrotz, in irgendeinem System fühlt man sich wohl mehr zuhause als in einem anderen - oder man ist auf jedem System zufrieden, auf dem man seinen Browser, sein Terminal oder seine Bash hat. 😉

Grüße, Benno

Benno-007 schrieb:

Ich weiß nicht wieso, aber ich persönlich habe es jetzt nicht so eilig, schon wieder die nächste Sau an Änderungen durch's Linuxdorf zu treiben. Ich komm mit Xorg und X-Forwarding super klar, mir fehlt da im Alltag absolut nichts. Auch die Leistung ist tip-top, kann da nicht meckern. Weiß gar nicht, was manche da haben - vielleicht gar kein Linux und nur mal irgendwo was gehört, was man kritisieren könnte? 😉

Schau dir das Video an, da wirds schön erklärt, Inkompatibilität mit Treibern bei neuen Versionen, siehe Intel Grafikkarten, schlechte Performance (siehe Flash, Java usw. Performance, ja selbst Firefox, Chrome laufen alle unter Windows, MacOSX performanter, siehe diverse Benchmarks)

X-Forwarding braucht man nicht, es gibt genug alternative Wege umd ähnlichtes zu erreichen. Xorg ist ein einziger Dinosaurier, der schon längst hätte ausgestorben sein müssen, aber man hat halt nichts besseres oder will nichts besseres programmieren. Warum setzt den Google bei Android xorg nicht ein bzw. Apple bei Mac OSX? Weils so geil ist?

Das sind schon noch einige. Z.B. gibt es bei deb keine Delta-Updates, bei rpm schon. Das heißt, bei Änderungen muss nicht ein ganzes Paket neu heruntergeladen werden, sondern nur die Differenzen. Desweiteren kann man bei rpm mal eben schnell im Installationsbefehl eine andere Quelle angeben, was bei deb schon wieder mit Änderung an der sources.list(.d) vor und nach der Änderung, jeweils mit folgendem Listenupdate, verbunden ist.

Also wenn das alles ist. Die meisten Linuxuser laden sich zig Distributionen runter, um die zu testen, als ob es da jetzt drauf an kommt ob man nun das Delta herunterlädt, oder das ganze Paket. Und falls man es unbedingt haben will, kann man es ja mit geballter manpower auch in das Paketformat integrieren, für das man sich letztlich entscheidet.

Welches Problem hast du als Endanwender denn damit, dass es deb UND rpm gibt? Das kann dir doch eigentlich egal sein. Du gehst einfach in deine Paketverwaltung, klickst deine Software an und sie wird installiert. Gehst du auf eine Firmenhomepage, werden meist beide Formate für den Endanwender angeboten oder eine simple .tar.gz - gibt ja unter Windows neben exe auch com sowie zip, was entfernt vergleichbar ist.

Direkt erst mal gar nicht. Indirekt aber schon, wenn die Anwendungsprogramme fehlen, weil die Softwarefehler wegen des großen Entwicklungsaufwands lieber auf Linuxportierungen verzichten. Warum zertifiziert Oracle denn z. B. die Software nur für RedHat und Suse? Weil sie genau wissen, dass es zu Problemen bei anderen Distributionen kommen kann und deshalb unterstützen sie diese auch nicht. Im Serverbereich hat Linux allerdings eine weit größere Verbreitung, daher lohnt es sich dort für spezielle Distributionen zu entwickeln, auf dem Desktop schaut das anders aus.

Was man gewöhnt ist, möchte man nutzen. Man könnte doch auch den Mac-Nutzern sagen, nehmt Windows, ein System reicht doch. Aber sie sind etwas anderes gewöhnt und/ oder finden das WIE der Bedienung eines anderen Systems besser - oder dessen Optik oder Stabilität. Warum sollte das nun ausgerechnet bei Linux anders sein? Und wie ich schon schrieb, ich finde RPM aufgrund seiner Vorteile durchaus reizvoll, gewöhnt bin ich aber in der Breite und Tiefe der Optionen eher deb und das Ökosystem dieser deb-Systeme.

Das sind verchiedene Betriebsystem, oder sollte man jede Distribution jetzt auch als eigenes Betriebsystem sehen, dann schauts aber mit dem Marktanteilen recht düster aus, wenn man das getrennt sieht, oder wieviel % hat Ubuntu da auf dem Desktop, wenn ganz Linux 1-2% hat?

Da sitzt jeder Handgriff einfach besser, wie in der eigenen Westentasche. Man muss kaum nachschlagen. Und schau dir mal die Manpages zu den vielen Paketverwaltungstools an - da gibt es eine ganze Menge Unterschiede in der Syntax. Wenn man eine gewohnt ist, kann die andere zunächst völlig verwirrend wirken - man muss also häufiger etwas nachschlagen. Und da es nun mal historisch so entstanden ist, kann doch jeder das nehmen, was er mal gelernt hat oder das Paketformat des Systems, dessen Gesamtheit er am gelungensten findet.

Was interessiert mich die Syntax? Im besten Fall sollte sich weder ein Programmierer, noch ein Anwender groß damit beschäftigen müssen. Pakete sollten automatisch erstellt werden, die dann auf allen Distributionen laufen.

Ich kann mir auch von Eclipse direkt ein APK Paket erstellen lassen, ohne dass ich Ahnung habe, wie das Teil genau aufgebaut ist.

Wirklich Probleme macht die Vielfalt auch dem Admin oder Programmierer eigentlich nicht unbedingt. Wenn er ein anderes System einsetzen will oder muss, arbeitet er sich ein und entdeckt Parallelen und Unterschiede. Natürlich müssen beide mehr testen und anlesen, aber es heißt nun mal "lebenslanges Lernen". Da soll mal noch einer sagen, die "ollen Unixhasen" wollen nur nix neues lernen. 😉

Ja sonst hätten die ja nichts mehr zu tun, hast ja recht 😉.

Kennt man einmal 1-2 Konzepte, z.B. beim Booten oder bei Programmiersprachen, arbeitet man sich rasch auch in konkurrierende Konzepte ein. Ist ja nicht so, dass man da trotz der Unterschiede gleich wieder bei Null anfangen müsste und das alles ein so großes Problem wäre. Nichtsdestotrotz, in irgendeinem System fühlt man sich wohl mehr zuhause als in einem anderen - oder man ist auf jedem System zufrieden, auf dem man seinen Browser, sein Terminal oder seine Bash hat. 😉

Die Probleme beginnen beim Testen, kannst Du alle Distributions/-versions Kombinationen testen? Warum gibts denn so viele Probleme, wenn eine Distribution die Version erhöht? Inkompatibilitäten, weil man die Kombination nicht testen konnte.

Blubbie schrieb:

Warum zertifiziert Oracle denn z. B. die Software nur für RedHat und Suse? Weil sie genau wissen, dass es zu Problemen bei anderen Distributionen kommen kann und deshalb unterstützen sie diese auch nicht.

Ja, Du kennst Dich aus!

Ich hatte mal ein Oracle installiert, welches nur für RedHat und Suse zertifiziert war, und sich nicht installieren lassen wollte. Die Installationsroutine - war gar nicht leicht zu finden - prüfte nur eine Datei 'redhat-release' o.s.ä. musste die heißen, und eine Versionsnummer x.y enthalten. Angelegt, neuprobiert, und schwupps - ließ es sich installieren.

Zu welchen Problemen soll es denn kommen? Wenn es Abhängigkeiten gibt, wieso prüfen sie nicht auf Abhängigkeiten? Weil sie Support anbieten, und nicht wissen was wie in Distribution X ohne zu kucken wie gelöst ist - ob der Systemstart über Sys-V-Init läuft oder etwas anderes. Aber wenn man eine Oracle-Datenbank betreibt, dann reserviert man dafür i.d.R. einen eigenen Rechner; wieso der User da auf Ubuntu oder Mint bestehen soll ist auch unklar.

bei Wayland hieß es, daß z.B. Nvidia keine Treiber anbieten will. ☹ Dann würden zwar Intel-Grafikkarten gut laufen...Wahrscheinlich sind auch noch zu viele Bugs in Wayland.

Ein Paketformat und wer entscheidet welches. Bei Redhat und Suse werden sie ihre Firmenkunden nicht verprellen wollen, indem sie Versuche mit deb als Paketformat machen. Wahrscheinlich auch eine Frage wieviel Manpower so der Entwicklungsaufwand dafür kostet.
Oder Debian auf rpm. Die ganzen Server müßten beim Upgrade das Paketformat wechseln. Das gäbe ein Chaos. Wenn Ubuntu auf Kleingeräte installierbar ist wird Ubuntu speziell dieser Hardware angepaßt. Da muß auf dem Gerät keine andere Linuxdistri für den Laien installierbar laufen.

V for Vortex schrieb:

Bei den Humble Bundles – die ich fast alle besitze und deren Spiele ich durch Bindung an meinen dortigen Account in einer einzigen langen Liste angezeigt bekomme – sind geschätzt 2/3 neben .bin und .tar.gz auch als .rpm und .deb erhältlich, mit einer leichten Mehrzahl an deb-Paketen.

Ein Erfolg von Ubuntu?

Blubbie schrieb:

Inkompatibilität mit Treibern bei neuen Versionen, siehe Intel Grafikkarten, schlechte Performance (siehe Flash, Java usw.

Betrifft mich alles nicht wirklich - habe wohl die richtige Hardware gewählt. Auch für Flash ausreichend Leistung vorhanden.

X-Forwarding braucht man nicht, es gibt genug alternative Wege umd ähnlichtes zu erreichen.

Ich möchte aber genau das, aus Vorliebe und gewissen Vorzügen. ☺ Alternativen aufgezwungen bekommen möchte keiner, solange man die Wahlfreiheit hat.

Also wenn das alles ist. Die meisten Linuxuser laden sich zig Distributionen runter, um die zu testen, als ob es da jetzt drauf an kommt ob man nun das Delta herunterlädt, oder das ganze Paket.

Stichwort UMTS- und LTE-Opfer mit Volumentarifen oder gar Analogmodemopfer.

Und falls man es unbedingt haben will, kann man es ja mit geballter manpower auch in das Paketformat integrieren, für das man sich letztlich entscheidet.

Es gibt sogar ein Paket dafür, aber vermutlich keine Paketquelle dazu. Vielleicht zu viel Aufwand, Speicher?

Indirekt aber schon, wenn die Anwendungsprogramme fehlen, weil die Softwarefehler wegen des großen Entwicklungsaufwands lieber auf Linuxportierungen verzichten. Warum zertifiziert Oracle denn z. B. die Software nur für RedHat und Suse?

Auch das klingt wieder sehr theoretisch - du bist persönlich nicht betroffen, genauso wenig wie ich. Es gibt die wichtigste Software, die man für Linux erwarten könnte, als .tar.gz oder oft sogar als deb und rpm. Was will man mehr.

Was interessiert mich die Syntax? Im besten Fall sollte sich weder ein Programmierer, noch ein Anwender groß damit beschäftigen müssen.

Die Paketverwaltung kann eben noch viel mehr als bloß Programme zu suchen, anzuzeigen und zu installieren. Und wie schon erwähnt, es gibt Abhängigkeiten und verschiedene Paketquellen. Es gibt Befehle, die nur die Konfiguration anfassen oder nur die Programme. Es gibt Prioritäten von Paketquellen und gepinnte oder gesperrte Versionen. Es gibt diverse clean-, force-Aktionen und der Artikel Paketverwaltung/Problembehebung gibt einen Einblick über die Komplexität so einer Paketverwaltung.

So ein stabiles, komfortables und schnelles System bekommt man nicht geschenkt, da steckt richtig viel Technik dahinter. Und viel Flexibilität. Sobald man diese braucht oder Probleme lösen muss, muss man was wissen oder können - oder eben neuinstallieren und sich dann in Foren beschweren, wie schlecht Linux sei.

Pakete sollten automatisch erstellt werden, die dann auf allen Distributionen laufen.

Dann schreib dir ein Script (gibt's auch bestimmt schon, a la checkinstall). Aber vergiss nicht, die Abhängigkeiten einzutragen...

HasserDesErfolges schrieb:

V for Vortex schrieb:

Bei den Humble Bundles – die ich fast alle besitze und deren Spiele ich durch Bindung an meinen dortigen Account in einer einzigen langen Liste angezeigt bekomme – sind geschätzt 2/3 neben .bin und .tar.gz auch als .rpm und .deb erhältlich, mit einer leichten Mehrzahl an deb-Paketen.

Ein Erfolg von Ubuntu?

Teilweise bestimmt, aber .deb stammt von Debian und war schon vorher weit verbreitet.