News Canonical: Ubuntu 16.04 unterstützt neues Paketformat Snap

[fethomm]

Das für nächste Woche erwartete Ubuntu 16.04 LTS „Xenial Xerus“ bringt mit Snap neben Debians DEB-Format offiziell ein neues Paketformat mit. Snaps und DEBs können in einer Installation zusammen installiert werden und ermöglichen unkompliziert neuere Pakete auch während der Laufzeit von LTS-Ausgaben der Distribution.

Zur News: Canonical: Ubuntu 16.04 unterstützt neues Paketformat Snap

 

[CloakingDevice]

Speicherplatz ist heute aber nunmal billig und kaum begrenzt. Von daher begrüße ich die Entwicklung doch sehr.

Erst die Tage wollte ich eine aktuelle Version von Nautilus auf elementary OS installieren, da ich den mitgelieferten Dateimanager nicht so mag. Das war jedoch einfach nicht praktikabel. In den offiziellen Repos ist noch eine uralte Version ohne Headerbar etc. und über das Gnome Staging PPA wird man gezwungen etliche kritische Systembibliotheken mit zu aktualisieren. Da sind Kopfschmerzen vorprogrammiert.

Mit Snaps oder XDG-Apps und Co wird das in Zukunft endlich bedenkenlos möglich sein. Unter anderen Betriebssystemen ist das Modell nicht grundlos schon lange Standard.

 

[mercsen]

Hmmm.
Bringen unter windows die programme nicht auch ihre abhängigkeiten mit? Abgesehen von globalen Libs wie .NET, Java oder DX kommt doch vieles mit dem programm mit, oder täusche ich da?

Mir sowieso immer ein rätsel gewesen wieso das bei linux immer alles so kompliziert sein muss. Als Programmierer und computer nerd behaupte ich mal mich ein wenig mit der materie auszukennen, konnte mich aber abseits von servern nie mit linux anfreunden und selbst für diese beschäftige ich mittlerweile einen externen. Soll der abhänigkeiten doch einfach selber auflösen und runterladen

Ansonsten kann ich meinem vorredner nur zustimmen, Speicherplatz ist heute billig und selten der limitierende Faktor. Wenn das der einzige Nachteil von snap ist kann man das nur begrüßen!

 

[Tzunamik]

Du kannst kein Programmier und Computer-Nerd sein, zumindest auf diesem Gebiet, wenn du keinerlei Ahnung von Computern hast.

Ein Mechaniker ist noch lange kein Ingenieur nur weil er das Teil von außen mal gesehen hat.
Oder dein Fachgebiet liegt bei Windows, auch dann ist deine Aussage nicht korrekt, da man nur Dinge beurteilen sollte, wenn man es kennt.

PS.: Ob nun SNAP oder DEB, Snap macht es dem "DAU" einfacher damit umzugehen, DEB ist jedoch definitiv immer noch die Nummer 1 wenn es um Optimierung geht!

 

[flappes]

Pferdefuss 2: eine fehlerhafte Bibliothek muss in allen Programm gefixt werden und vom Maintainer publiziert werden... das wird witzig.
Oder gibts vom System aus eine Möglichkeit ein Bibliotheksupdate zu erzwingen?

Das Pprfekte System gibts halt nicht.

 

[uburoi]

So ganz kann man das Speicherplatz-Problem nicht von der Hand weisen, insofern vermutlich nicht wenige als Systemplatte eine SSD mit begrenzter Kapazität haben. Allerdings nahmen meine bisherigen Linux-Installationen immer nur einen Bruchteil dessen in Anspruch, was sich Windows schon im Rohzustand gönnt. Von daher müsste man erstmal schauen über wie viel Mehrbedarf an Speicher hier überhaupt gesprochen wird...

Gruß Jens

 

[Wattwanderer]

Klingt wie das Verzichten auf Shared Libs? HDD/SSDs sind zumindest für Code billig genug aber für RAM gilt das nur bedingt.

 

[CloakingDevice]

@flappes
Was meinst du mit fehlerhafter Bibliothek? Bezogen auf daraus resultierende Programmfehler sollte das dem Entwickler bereits vor der Veröffentlichung auffallen, da er mit der gleichen Version entwickelt. Bei shared libraries ist die Wahrscheinlichkeit für solche Fehler viel größer. Ich entwickele mit Version 3.8 und setze diese als Minimum voraus. Jemand anders hat aber nun bereits 3.9 installiert und irgendetwas hat sich verändert. Schon haben Anwender und Entwickler eine Menge Spaß.

Wenn du auf später bekanntwerdende Sicherheitslücken abzielst, ja, dann könnte das ein Problem sein. Allerdings sollen die Anwendungen ja in einer Sandbox laufen, wenn mich nicht alles täuscht. Solange diese Barriere nicht ausgehebelt wird, dürfte das Risiko zumindest gemindert sein.

 

[0xffffffff]

Dem Speicherplatzargument/Problem kann man mMn. schon entgegenwirken, indem man auf Dateisystemebene Datendeduplikation betreibt. Btrfs und auch ZFS können das meines Wissens nach. Sprich man prüft bei der Installation ob es nicht schon eine identische "QTFramework.v3.2.1.so" gibt und verlinkt auf Dateisystemebene einfach auf diese. Sollte sich etwas ändern wird ein copy-on-write durchgeführt.

20 Anwendungen bringen das komplette Qt-Framework mit aber letztenendes existiert es nur einmal auf der Platte mit 19 Verweisen auf dieses. Updated Anwendung #2 sein Qt-Framework existiert es 2x auf der Platte. etc...

 

[Wattwanderer]

Denke dateibasierte Deduplikation funktioniert nur bei viel Disziplin. Oft genug kommen ja beim selben Quellcode unterschiedliche Dateien raus wenn sie zu einem anderen Zeitpunkt auf einem anderen Rechner von einem anderen Benutzer compiliert wird.

Selbst wenn diese Disziplin aufgebracht wurde driften sie doch zwangsläufig auseinander und es bleibt das Problem, Bugfixes auf niedriger Ebene wie z.B. libc in den Paketen zu aktualisieren was darauf hinausläuft, alle snap Pakete zu aktualisieren.

 

[fethomm]

Das Problem wird dadurch entschärft, das inkrementell aktualsiert werden kann, in dem Fall nur die entsprechende Bibliothek.

 

[0xffffffff]

Denke dateibasierte Deduplikation funktioniert nur bei viel Disziplin. Oft genug kommen ja beim selben Quellcode unterschiedliche Dateien raus wenn sie zu einem anderen Zeitpunkt auf einem anderen Rechner von einem anderen Benutzer compiliert wird.

Das ist schon korrekt, ohne mir das genauer angeschaut zu haben denke ich wird das aber folgendermaßen ablaufen:

* Der Entwickler hat auch Ubuntu
* Entwickler A und B erstellen eine Anwendung mit Qt
* Entwickler A und B machen dazu zuvor "apt-get install libqt5-dev"
* Beim Packaging werden nun alle Abhängigkeiten in ein .snap Paket geschaufelt
* 2 Anwendungen mit zum großteil redundanten & identischen Bibliotheken

Klar wird es da mal Ausnahmen geben, aber selber Qt kompilieren etc... wird erfahrungsgemäß eher die Ausnahme bleiben. Von daher denke ich dass das durchaus helfen würde

 

[konkretor]

Mal sehen wie lange sich das Format hält und ob es auch wirklich alle Anwendungen dafür gibt

 

[Wattwanderer]

Das liefe dann wohl auf ein Schichtenmodell hinaus? Oberhalb der Basisschicht im deb Format schichtet man eine weitere aus deren Bibliotheken sie die neueren Pakete bedienen? Vielleicht besser als einen Haufen von Inseln die auf der untersten Schicht komplett voneinander getrennt schwimmen und jede für sich aktualisiert werden muss?

Zumindest auf dem PC sieht das wie Windows 8 aus wo man zwei Dinge die nicht zusammen gehören aus ideologischen Gründen unbedingt vereinigen wollte und dabei doppelt versagte.

LTS wer stabile Basis will. Werden bei einzelnen Paketen doch aktuellere Versionen gewüscht, dem bleibt ja immer noch /usr/local wo er die aktuelle Versionen selbst bauen und installieren kann?

Wenn man alles aktuell will und selbst sechs Monate bis zum nächsten Release schon zu lang ist dem bleibt ja noch die dailys?

 

[mercsen]

Du kannst kein Programmier und Computer-Nerd sein, zumindest auf diesem Gebiet, wenn du keinerlei Ahnung von Computern hast.

Ein Mechaniker ist noch lange kein Ingenieur nur weil er das Teil von außen mal gesehen hat.
Oder dein Fachgebiet liegt bei Windows, auch dann ist deine Aussage nicht korrekt, da man nur Dinge beurteilen sollte, wenn man es kennt.

PS.: Ob nun SNAP oder DEB, Snap macht es dem "DAU" einfacher damit umzugehen, DEB ist jedoch definitiv immer noch die Nummer 1 wenn es um Optimierung geht!

kein plan was du gelesen hast. Ich sage ja nicht das ich mich damit nicht befasse, nur das ich es nicht mag. Ich muss mich damit leider täglich rumschlagen da mein Zielsystem fast immer Linux ist (und das nicht nur server mäßig), aber ab einer gewissen Zahl X an Servern die man betreuen muss hat man einfach keine Zeit mehr neben seinem eigentlichen betätigungsfeld und lagert das eben aus ~_~
Und gerade weil ich mich soviel damit rumschlage erlaube ich mir zu behaupten das es alles kompliziert ist.
Ja es ist eine ganz andere Welt als die von Windows, eben nicht für den mainstream gemacht.
Problem? Nach endlosen googlen dann eine tripple pre alpha software gefunden die helfen könnte aber dann noch selber kompiliert und ggf. angepasst werden will und solche scherze.
Installationen brechen plötzlich ab weil Paket XYZ nicht da ist, steht aber in den repos drinne, trotzdem muss man es dann manuell runterladen.....

 

[Daichi]

Das Problem wird dadurch entschärft, das inkrementell aktualsiert werden kann, in dem Fall nur die entsprechende Bibliothek.

Wirkt sich ein Update der Bibliothek den automatisch auf alle betroffenen Programme aus, also einmal aktuallisieren und alles fertig?
Ich verstehe das fast so, das jeder Entwickler für sein Programm selbst verantwortlich ist und man darauf hoffen darf, das das Programm ein Update erhält, es also komplett unabhängig von allen anderen Bibliothek ist.
Also wenn z.B. openssl in 20 verschiedenen Programmen verwendet wird, müssen 20 Programme gepflegt werden und nicht nur einmal das openssl-Paket, entstehen dadurch nicht ganz schöne Sicherheitslücken?

 

[fethomm]

Das ist vermutlich so, ich meinte auch eher die Menge, die zu aktualisieren ist.

 

[mensch183]

Pferdefuss 2: eine fehlerhafte Bibliothek muss in allen Programm gefixt werden und vom Maintainer publiziert werden... das wird witzig.

Der "Maintainer" wird i.d.R. der Hersteller der Software sein, niemand von der Distri.

Und nicht vergessen, dass es Bibliotheken mit Konfiguration gibt, die sich je nach Lib-Version unterscheidet. Da bringt dann vermutlich jedes Programm in seinem Snap-Ding eine eigene Konfiguration mit (SSL, PAM, ...). Sowas will man natürlich eigentlich nicht.

Ubuntu will es Drittanbietern von Paketen ohne Quellcode einfacher machen. Diese Pakete soll der Endnutzer einfach aus dem Web vom Hersteller runterladen und installieren können, wie in der Windowswelt üblich. Dafür nimmt man halt einige Nachteile in Kauf. Denkt also bei dem Snap-Kram nicht an Opensource-Programme sondern an sowas wie Chrome und Teamspeak. Solche Programme sind auch heute schon räudig in die jeweilige Distri integriert und bringen Gott und die Welt nochmal selbst mit. Viel schlimmer wirds also nicht.

Ursache des Schlamassels ist das Chaos auf Linux oberhalb des Kernels. Ordentlich versionierte, stabile ABIs sind dort Ausnahme, nicht Regel. Juckt kaum, wenn man von allem den Quellcode hat. Stört aber sehr, wenn man BLOBs verkaufen will.

 

[Wattwanderer]

Was ist an tar so kaputt?

Installieren:

cd ~/bin
tar zxvf binary-only-software-der-ich-vertraue-0.1.tar.gz

Deinstallieren:

cd ~/bin
rm -rf programmpaket-1

Wenn die Programme Schwierigkeit haben sich selbst im Filesystemhierachie zu finden setzt man von mir aus ein APP_X_HOME=/home/users/w/willy/bin/APPX

 

[R4Z3R]

Ich kann die Beschreibung von mercsen teils nachvollziehen.
Falsch verstandenes elitäres Denken, dass im Endeffekt nur dazu führt dass Funktionalität nicht genutzt werden kann, ist im Linux-Umfeld halt durchaus verbreitet.
Zudem sind Konzepte, nur weil sie in der Theorie sauber sind (Paketmanager) nicht automatisch bewährt in der Praxis.

Insofern begrüße ich den Schritt hin zu einer Auslieferung inklusive mehr der Abhängigkeiten. Wenn eine Applikation Bibliothek X in Version 3.5 braucht dann sind die halt dabei, fertig. Deduplizierung ist auch ein Tradeoff, hat also nicht inherent nur gute Seiten.