Ja, ja… die Canonical Eigenentwicklungen… aber darüber wurde ja schon ausreichend diskutiert. Diese Paketformate machen m.E. aber erst Sinn wenn das Sandboxing vernünftig und vor allem auch sicher funktioniert. Bei den Snaps gab es zu diesem (frühen) Stadium ja auch schon die Sicherheitsdiskussion. Ich persönlich würde eher auf die Gnome-Apps setzen, da diese plattformunabhängiger sind.
Zu Snap und Mir gab es zu Begin der Entwicklung keine funktionierende alternative. Es ist open source, so whats your problem? Find es gut das es soviele package formate gibt da ich mir auch noch nicht sicher bin was die beste alternative ist, z.B. was ist es mit package dependencies...
Mit Mir wollte Canonical Wayland ausstechen, dessen Entwicklung schon weit gediehen war.
Mit Unity wollte Canonical die Gnomeshell und Gnome 3 ausbremsen. Die Programme von Gnome nimmt Canonical für Ubuntu natürlich gerne.
Auch glaube ich kaum, dass Entwickler begeistert sind, wenn sie unzählige verschiedene Pakete packen müssen. Kein Wunder, dass kaum kommerzielle Softwareunternehmen Software auch für Linux auf den Markt bringen, wenn unzählige Pakete veröffentlicht werden müssen, damit die Software auf möglichst vielen Distributionen installiert werden kann. Oder soll wieder jeder selber kompilieren müssen? Canonical defragmntiert Linux und sorgt für mehr Inkompatibiltät.
Was Canonical offensichtlich nicht will, ist sich an der Community beteiligen.
Mit Unity wollte Canonical die Gnomeshell und Gnome 3 ausbremsen. Die Programme von Gnome nimmt Canonical für Ubuntu natürlich gerne.
Nein, Unity soll eine Oberfläche für existierende Programme sein, vorallem für bereits existierende GTK+ Programme. Programme solten IMHO sowieso unäbhängig vom verwendeten Desktop sein.
Bedenklich ist bei Unity und anderen Canonical-Projekten eher, das wenn man sein Urheberrecht abgeben muss, damit Canonical den Beitrag propritär re-lizenzieren kann.
Auch glaube ich kaum, dass Entwickler begeistert sind, wenn sie unzählige verschiedene Pakete packen müssen.
Dafür gibt es Tools, die einem das Ganze in diverse Format einpacken bzw. umpacken. Gibt ja auch die Distributionsunabhängigen Pakete, die mir meistens lieber, als wenn sich das Zeugs über das komplette System verteilt.
Canonical defragmntiert Linux und sorgt für mehr Inkompatibiltät.
Klar, wenn man etwas neues entwickelt, dann defragmentiert man damit das ein vorhandene System, aber nur so entwickelt sich das System auch weiter. In der Natur nennt man sowas Evolution
Was Canonical offensichtlich nicht will, ist sich an der Community beteiligen.
die Idee ist nicht neu und ob das Canonical-Format erfolgreich sein wird, muss sich noch herausstellen. Grundsätzlich halte ich aber den Weg, alle Binaries, Bibliotheken, Konfigurations- und sonstigen Dateien eines Programms in einem eigenen Paket bereit zu stellen wirklich gut. Das ermöglicht auch nach Jahren eine LTS-Distribution (Debian, Ubuntu, RHEL, SLES,...) mit aktuellen Programmversionen zu versorgen ohne dass Inkompatibilitäten mit alten benötigten Bibliotheken auftreten.
Flatpak (XDG-Apss) sind auch eine Eigenentwicklung. AppImage auch. Klik ebenso. 0install ist auch nie projekt-übergreifend gewesen.
Im Grunde ist Open Source auch mit freedesktop immer noch eine riesengroße Sammlung an einzelne Projekten die kaum zusammenarbeiten. Und außer .desktop-Files und ein bisschen dbus-Zusammenarbeit hat freedesktop auch nicht bewirkt. Die Interessen sind einfach zu verschieden.
Mehr Koordination zwischen Distributionen und Desktopumgebungen wäre besser. Freedesktop wäre dafür der richtige Ort gewesen, leider konnte man sich dort entweder nur auf den kleinsten gemeinsamen Nenner einigen oder man hat eine sehr große Distribution (... Ubuntu), die meint es besser zu können als alle anderen ( Wer brauchte Mir, nachdem Wayland schon da war?).
Schlimm ist das ja nicht bei ner normalen Applikation, wenn es z.B. Gimp und Krita gibt, oder Dolphin und Konqueror, usw. usf., dann ist es wirklich mehr Auswahl und Bereicherung.
Gerade bei zentralen Komponenten wie dem Display Server und Ähnlichen kann man doch keine tausend Protokolle brauchen/wollen, wenn man irgendwann auf nen grünen Zweig kommen will.
Es wäre auch in Ordnung ne alternative Implementation vom gleichen Protokoll, meinetwegen mit Erweiterungen, zu entwickeln.
Aber nervig wird es für Entwickler/Anwender, wenn plötzlich systemnahe Komponenten miteinander inkompatibel sind.
Es wird z.B. gemunkelt, dass Ubuntu deswegen nicht auf Wayland gesetzt hat, weil Wayland zum größten Teil von Redhat Entwicklern vorangetrieben wird. Anscheinend will man sich von Redhat nichts "diktieren" lassen.
Man bräuchte eigentlich eine informelle Tagung oder eine Art Vermittlungsstelle zwischen Distributionen. Bei dieser dürfte keine Distro dominieren. Es müsste demokratisch sein, aber nicht bindend.
Das Ziel müsste sein gemeinsame Ziele zu finden (machen wir den besten Display Server, den man sich vorstellen kann), und möglichst das "Not Invented Here"-Syndrom zu bekämpfen.
Andererseits ist es auch wieder die Freiheit, seinen eigenen Weg gehen zu dürfen, und alles anders zu machen, auch wenn jeder denkt es wäre doof.
Vielleicht sollte man sich mal auf ein einheitliches Distroformat und einheitliche Grundstruktur distroübergreifend (freedesktop) beschränken dann bräuchte man nicht ein neues Monsterpaketformat, das es auch schon wieder in mehreren Eigenentwicklungen gibt.
Problem erkannt aber Umsetzung auf ein weiteres ausgelagert, das nen Rattenschwanz weiterer Probleme mitbringt.
Das ist einfach nur bescheuert was hier "entwickelt" wird.
So funktioniert das nicht. Nicht jede app bringt alle ihre abhängigkeiten mit, sondern es gibt eine kette von runtimes. Z.b. eine gtk runtime, eine java runtime etc. Und das office flatpak setzt dann einfach die entsprechenden runtimes voraus. Im office flatpak wären nur sachen enthalten die relativ speziell mit office zusammenhängen. Natürlich gibt es die runtimes auch in verschiedenen versionen, aber halt für alle distributionen gleich.
Wenn office sagt ich brauche die gtk-runtime-1.2 und die office-runtime-1.3 dann sind die runtimes gleich egal ob unter debian oder fedora. Doppelt hast du die nur auf der platte wenn z.b. libreoffice und calligra unterschiedliche versionen der office-runtime benutzen würden(das wären so sachen wie cups, libjpeg und pdf export support schätze ich). Es ist wirklich ein ganz erheblicher fortschritt, im endeffekt geht es darum das der entwickler eines programms nicht nur vorgeben kann welche lib versionen sein programm nutzt, sondern er kann davon ausgehen das die ganze dependency chain seines programms beim user identisch ist zu der auf seinem entwicklungssystem. Das erleichtert die fehlersuche enorm(reproduzierbarkeit), was wiederum die zuverlässigkeit erhöht.
Das könnte ganz erheblich den arbeitsaufwand reduzieren den distros wie debian oder fedora haben. Die haben eh schon probleme für alle pakete maintainer zu finden, wenn da grosse softwarepakete wie firefox und libreoffice direkt vom "hersteller" kommen ...
Dem müsste dann auch vorgebeugt werden, indem LibreOffice eben nicht auf das neueste Gtk setzt wenn das gar nicht wirklich einen Mehrwert bringt. Nur so können wir verhindern, dass dann 20 Gtk Versionen auf der Platte sind.
In Acht geben müssen wir uns dann vor diesen faulen Skript Kiddies, die übernacht mal eben ein Programm geschrieben haben und alle Flags auf die neuesten Runtimes setzen, weil es eben cool ist. Da müsste es strenge Regeln geben. Z.B. auch eine komplette IDE, die so was leichter macht. Da klickt man dann "ich brauche Funktion X" und die IDE weiß, dass das eben schon in allen Gtk Versionen enthalten ist und zwingt dann den Dev, die älteste mögliche Version zu nutzen, die noch Sicherheitsupdates erfährt. Und primär sollten natürlich die Distro-eigenen Libs benutzt werden.
Die herausgabe der GTK runtimes wäre sache z.b. der gnome foundation, nicht der drittverwerter. Mit anderen worten es gibt da eine runtime die enthält xy, und wenn dann der herausgeber der Runtime meint er hätte einen interessanten mehrwert in seinen entwicklungen dann bringt er eine neue runtime raus. Der drittverwerter, z.b. libreoffice, schaut sich das dann an und entscheidet ob er die neue runtime nutzen will oder nicht. Wenn er sie nutzen will wird sie gründlich getestet und dann als neue dependency als neuer unterbau eingespielt. Der flatpak manager prüft dann im anschluss ob die alte runtime noch von jemand anderem genutzt wird oder nicht und löscht sie entweder oder hält sie auf vorrat.
Das ist wie gesagt auch nicht für jedes kleine miniprogramm gedacht. Wird sicherlich auch "triviale" software geben die einfach sagt "ich will eine gtk runtime > 1.2" und die keine extrawurst braucht weil der entwickler halt drauf achtet wie künfitige runtimes mit seinem programm funktionieren. Ist ja jetzt auch nicht anders mit libraries oder neuem gcc. Man muss halt schauen das sein programm lauffähig bleibt.
Wenn natürlich die entwickler der libraries ein bisschen deppert sind und wegen jedem furz ne neue 400MB runtime rausbringen ... aber dann hast du eh ein anderes problem. Wenn der upstream spinnt, dann spinnt der halt.
>Die herausgabe der GTK runtimes wäre sache z.b. der gnome foundation, nicht der drittverwerter.
Hmm... glaub nicht, dass das z.B. bei Debian oder Slackware so funktionieren wird. Da wird so weit wie möglich auf die Distro internen Libs zurücggegriffen werden (weiß nicht wie möglich das bei Flatpak zur Zeit ist).
> Ist ja jetzt auch nicht anders mit libraries oder neuem gcc. Man muss halt schauen das sein programm lauffähig bleibt.
Daher meine Angst, denn ich glaube, dass manchmal Projekte zu früh einen Bump auf neue lib Versionen machen, ohne wirklich die Features zu brauchen. Und dann kannst du z.B. ein einfaches GUI Programm nicht mal eben so bei Debian kompilieren, usw.
>Wenn natürlich die entwickler der libraries ein bisschen deppert sind und wegen jedem furz ne neue 400MB runtime rausbringen ... aber dann hast du eh ein anderes problem. Wenn der upstream spinnt, dann spinnt der halt.
Da habe ich auch die Angst, dass ich dann irgendwann, falls Linux mal erfolgreicher bin, ein Programm nutzen muss (das hippste Chatprogramm, das alle nutzen oder ein Frontend irgendeiner Behörde...), dass jemand mal eben so programmiert hat und einfach alle neuesten Sachen beim Building gesetzt hat. Und dann gibt es schon die 400MB Szenarien für poplige Frontends.
Ja, ja… die Canonical Eigenentwicklungen… aber darüber wurde ja schon ausreichend diskutiert. Diese Paketformate machen m.E. aber erst Sinn wenn das Sandboxing vernünftig und vor allem auch sicher funktioniert. Bei den Snaps gab es zu diesem (frühen) Stadium ja auch schon die Sicherheitsdiskussion. Ich persönlich würde eher auf die Gnome-Apps setzen, da diese plattformunabhängiger sind.
Canonical erinnert mich mit seinen ewigen Sonderwegen auch immer mehr an Microsoft.
Zu Snap und Mir gab es zu Begin der Entwicklung keine funktionierende alternative. Es ist open source, so whats your problem? Find es gut das es soviele package formate gibt da ich mir auch noch nicht sicher bin was die beste alternative ist, z.B. was ist es mit package dependencies...
Mit Mir wollte Canonical Wayland ausstechen, dessen Entwicklung schon weit gediehen war.
Mit Unity wollte Canonical die Gnomeshell und Gnome 3 ausbremsen. Die Programme von Gnome nimmt Canonical für Ubuntu natürlich gerne.
Auch glaube ich kaum, dass Entwickler begeistert sind, wenn sie unzählige verschiedene Pakete packen müssen. Kein Wunder, dass kaum kommerzielle Softwareunternehmen Software auch für Linux auf den Markt bringen, wenn unzählige Pakete veröffentlicht werden müssen, damit die Software auf möglichst vielen Distributionen installiert werden kann. Oder soll wieder jeder selber kompilieren müssen? Canonical defragmntiert Linux und sorgt für mehr Inkompatibiltät.
Was Canonical offensichtlich nicht will, ist sich an der Community beteiligen.
Nein, Unity soll eine Oberfläche für existierende Programme sein, vorallem für bereits existierende GTK+ Programme. Programme solten IMHO sowieso unäbhängig vom verwendeten Desktop sein.
Bedenklich ist bei Unity und anderen Canonical-Projekten eher, das wenn man sein Urheberrecht abgeben muss, damit Canonical den Beitrag propritär re-lizenzieren kann.
Dafür gibt es Tools, die einem das Ganze in diverse Format einpacken bzw. umpacken. Gibt ja auch die Distributionsunabhängigen Pakete, die mir meistens lieber, als wenn sich das Zeugs über das komplette System verteilt.
Klar, wenn man etwas neues entwickelt, dann defragmentiert man damit das ein vorhandene System, aber nur so entwickelt sich das System auch weiter. In der Natur nennt man sowas Evolution
Das beruht eher auf Gegenseitigkeit.
die Idee ist nicht neu und ob das Canonical-Format erfolgreich sein wird, muss sich noch herausstellen. Grundsätzlich halte ich aber den Weg, alle Binaries, Bibliotheken, Konfigurations- und sonstigen Dateien eines Programms in einem eigenen Paket bereit zu stellen wirklich gut. Das ermöglicht auch nach Jahren eine LTS-Distribution (Debian, Ubuntu, RHEL, SLES,...) mit aktuellen Programmversionen zu versorgen ohne dass Inkompatibilitäten mit alten benötigten Bibliotheken auftreten.
Flatpak (XDG-Apss) sind auch eine Eigenentwicklung.
AppImage auch.
Klik ebenso.
0install ist auch nie projekt-übergreifend gewesen.
Im Grunde ist Open Source auch mit freedesktop immer noch eine riesengroße Sammlung an einzelne Projekten die kaum zusammenarbeiten. Und außer .desktop-Files und ein bisschen dbus-Zusammenarbeit hat freedesktop auch nicht bewirkt.
Die Interessen sind einfach zu verschieden.
schreibst ist leider richtig.
Mehr Koordination zwischen Distributionen und Desktopumgebungen wäre besser. Freedesktop wäre dafür der richtige Ort gewesen, leider konnte man sich dort entweder nur auf den kleinsten gemeinsamen Nenner einigen oder man hat eine sehr große Distribution (... Ubuntu), die meint es besser zu können als alle anderen ( Wer brauchte Mir, nachdem Wayland schon da war?).
Schlimm ist das ja nicht bei ner normalen Applikation, wenn es z.B. Gimp und Krita gibt, oder Dolphin und Konqueror, usw. usf., dann ist es wirklich mehr Auswahl und Bereicherung.
Gerade bei zentralen Komponenten wie dem Display Server und Ähnlichen kann man doch keine tausend Protokolle brauchen/wollen, wenn man irgendwann auf nen grünen Zweig kommen will.
Es wäre auch in Ordnung ne alternative Implementation vom gleichen Protokoll, meinetwegen mit Erweiterungen, zu entwickeln.
Aber nervig wird es für Entwickler/Anwender, wenn plötzlich systemnahe Komponenten miteinander inkompatibel sind.
Es wird z.B. gemunkelt, dass Ubuntu deswegen nicht auf Wayland gesetzt hat, weil Wayland zum größten Teil von Redhat Entwicklern vorangetrieben wird. Anscheinend will man sich von Redhat nichts "diktieren" lassen.
Man bräuchte eigentlich eine informelle Tagung oder eine Art Vermittlungsstelle zwischen Distributionen. Bei dieser dürfte keine Distro dominieren. Es müsste demokratisch sein, aber nicht bindend.
Das Ziel müsste sein gemeinsame Ziele zu finden (machen wir den besten Display Server, den man sich vorstellen kann), und möglichst das "Not Invented Here"-Syndrom zu bekämpfen.
Andererseits ist es auch wieder die Freiheit, seinen eigenen Weg gehen zu dürfen, und alles anders zu machen, auch wenn jeder denkt es wäre doof.
wenn jedes Paket die ganzen Abhängigkeitne mitbringt?
Office braucht:
tausende Libs + Java + Python +....
Vielleicht sollte man sich mal auf ein einheitliches Distroformat und einheitliche Grundstruktur distroübergreifend (freedesktop) beschränken dann bräuchte man nicht ein neues Monsterpaketformat, das es auch schon wieder in mehreren Eigenentwicklungen gibt.
Problem erkannt aber Umsetzung auf ein weiteres ausgelagert, das nen Rattenschwanz weiterer Probleme mitbringt.
Das ist einfach nur bescheuert was hier "entwickelt" wird.
So funktioniert das nicht. Nicht jede app bringt alle ihre abhängigkeiten mit, sondern es gibt eine kette von runtimes. Z.b. eine gtk runtime, eine java runtime etc. Und das office flatpak setzt dann einfach die entsprechenden runtimes voraus. Im office flatpak wären nur sachen enthalten die relativ speziell mit office zusammenhängen. Natürlich gibt es die runtimes auch in verschiedenen versionen, aber halt für alle distributionen gleich.
Wenn office sagt ich brauche die gtk-runtime-1.2 und die office-runtime-1.3 dann sind die runtimes gleich egal ob unter debian oder fedora. Doppelt hast du die nur auf der platte wenn z.b. libreoffice und calligra unterschiedliche versionen der office-runtime benutzen würden(das wären so sachen wie cups, libjpeg und pdf export support schätze ich). Es ist wirklich ein ganz erheblicher fortschritt, im endeffekt geht es darum das der entwickler eines programms nicht nur vorgeben kann welche lib versionen sein programm nutzt, sondern er kann davon ausgehen das die ganze dependency chain seines programms beim user identisch ist zu der auf seinem entwicklungssystem. Das erleichtert die fehlersuche enorm(reproduzierbarkeit), was wiederum die zuverlässigkeit erhöht.
Das könnte ganz erheblich den arbeitsaufwand reduzieren den distros wie debian oder fedora haben. Die haben eh schon probleme für alle pakete maintainer zu finden, wenn da grosse softwarepakete wie firefox und libreoffice direkt vom "hersteller" kommen ...
Dem müsste dann auch vorgebeugt werden, indem LibreOffice eben nicht auf das neueste Gtk setzt wenn das gar nicht wirklich einen Mehrwert bringt. Nur so können wir verhindern, dass dann 20 Gtk Versionen auf der Platte sind.
In Acht geben müssen wir uns dann vor diesen faulen Skript Kiddies, die übernacht mal eben ein Programm geschrieben haben und alle Flags auf die neuesten Runtimes setzen, weil es eben cool ist. Da müsste es strenge Regeln geben. Z.B. auch eine komplette IDE, die so was leichter macht. Da klickt man dann "ich brauche Funktion X" und die IDE weiß, dass das eben schon in allen Gtk Versionen enthalten ist und zwingt dann den Dev, die älteste mögliche Version zu nutzen, die noch Sicherheitsupdates erfährt. Und primär sollten natürlich die Distro-eigenen Libs benutzt werden.
Die herausgabe der GTK runtimes wäre sache z.b. der gnome foundation, nicht der drittverwerter. Mit anderen worten es gibt da eine runtime die enthält xy, und wenn dann der herausgeber der Runtime meint er hätte einen interessanten mehrwert in seinen entwicklungen dann bringt er eine neue runtime raus. Der drittverwerter, z.b. libreoffice, schaut sich das dann an und entscheidet ob er die neue runtime nutzen will oder nicht. Wenn er sie nutzen will wird sie gründlich getestet und dann als neue dependency als neuer unterbau eingespielt. Der flatpak manager prüft dann im anschluss ob die alte runtime noch von jemand anderem genutzt wird oder nicht und löscht sie entweder oder hält sie auf vorrat.
Das ist wie gesagt auch nicht für jedes kleine miniprogramm gedacht. Wird sicherlich auch "triviale" software geben die einfach sagt "ich will eine gtk runtime > 1.2" und die keine extrawurst braucht weil der entwickler halt drauf achtet wie künfitige runtimes mit seinem programm funktionieren. Ist ja jetzt auch nicht anders mit libraries oder neuem gcc. Man muss halt schauen das sein programm lauffähig bleibt.
Wenn natürlich die entwickler der libraries ein bisschen deppert sind und wegen jedem furz ne neue 400MB runtime rausbringen ... aber dann hast du eh ein anderes problem. Wenn der upstream spinnt, dann spinnt der halt.
>Die herausgabe der GTK runtimes wäre sache z.b. der gnome foundation, nicht der drittverwerter.
Hmm... glaub nicht, dass das z.B. bei Debian oder Slackware so funktionieren wird. Da wird so weit wie möglich auf die Distro internen Libs zurücggegriffen werden (weiß nicht wie möglich das bei Flatpak zur Zeit ist).
> Ist ja jetzt auch nicht anders mit libraries oder neuem gcc. Man muss halt schauen das sein programm lauffähig bleibt.
Daher meine Angst, denn ich glaube, dass manchmal Projekte zu früh einen Bump auf neue lib Versionen machen, ohne wirklich die Features zu brauchen. Und dann kannst du z.B. ein einfaches GUI Programm nicht mal eben so bei Debian kompilieren, usw.
>Wenn natürlich die entwickler der libraries ein bisschen deppert sind und wegen jedem furz ne neue 400MB runtime rausbringen ... aber dann hast du eh ein anderes problem. Wenn der upstream spinnt, dann spinnt der halt.
Da habe ich auch die Angst, dass ich dann irgendwann, falls Linux mal erfolgreicher bin, ein Programm nutzen muss (das hippste Chatprogramm, das alle nutzen oder ein Frontend irgendeiner Behörde...), dass jemand mal eben so programmiert hat und einfach alle neuesten Sachen beim Building gesetzt hat. Und dann gibt es schon die 400MB Szenarien für poplige Frontends.