Wie man den GNOME Blog entnehmen konnte, wurde der neueste Nautilus jetzt als Flatpak verfügbar gemacht.
„Flatpak is the big step we needed.“
Sowas ähnliches haben sie auch geschrieben, bevor der Krieg ausbrach … 🙁
Um es nochmal klar zu sagen, daß ist großer Mist, auch wenn es „praktische“ Aspekte löst. Wie wir gestern in unserer lokalen LUG diskutiert hatten, befürworten natürlich einige FlatPak und Snappy, weil man so dicke fette Anwendungen installieren können, ohne daß diese zusätzliche Abhängigkeiten auflösen müssen, da sie diese schon mitbringen. Und genau da liegt das Problem: Sie bringen mehr mit, als man haben will. Mit jeder App kann die gleiche Schwachstelle auf das System kommen oder noch schlimmer, noch mehr andere Schwachstellen.
Bei aktiven Projekten wie Nautilus ( obiges Beispiel ) könnte man davon ausgehen, daß deren Beiwerk auch aktuell ist, aber garantieren tut einem das keiner. Statt also einer Anlaufstelle ( der Distro ) für Schwachstellenbehebung, gibt es dann hunderte, weil jeder sein eigenes Süppchen kocht. Mit hunderten von Apps braucht man einen Verantwortlichen und nicht hunderte, weil wenn von denen EINER Failed reicht das aus um den Rechner zu knacken. Failed bspw. RedHat wären soviele betroffen, daß RedHat sich den Fail einfach nicht leisten kann, ergo auch nicht tut.
Und deswegen sollten Flatpak und Snappy schnellstmöglich wieder begraben werden!
Die Realität ist, dass viele eher Linux-fremde Entwickler dem Veröffentlichungsmodell über Distributionen wenig abgewinnen können und es als Hürde sehen. Flatpak und Snappy sind, gepaart mit Isolierung, eine direkte Antwort darauf. Das gefällt nicht jedem, aber es ist niemand gezwungen, diese „Container-Apps“ zu nutzen. Am besten wäre es, wenn Kritiker dann konkret melden, wenn es z.B. Sicherheitslücken in derartigen Apps gibt. Ob es funktioniert sehen wir dann wenn es ausgerollt ist.
Ich persönlich finde es gefährlich so zu handeln. Wo ist das gute Denken vor dem Handeln geblieben? (Ich frag mich das immer mehr).
So ein bischen „first-world-problems“ ist das schon. Ja dinge sind manchmal unbequem und dadurch erst gut und einzigartig.
Außerdem hat man nur begrenzt resourcen, stell dir mal vor das wird der totale boom und tausende Container entstehen. Wer soll da noch den Überblick bewahren …
Das wird exponentiell schwieriger.
Wenn wir warten bis es nicht funktioniert, ist es zu spät.
Krita hat schon vor Wochen angefangen Binaryblobs zu verteilen. Zum Glück gibt es das auch noch „normal“ aus einem eigenen Repo.
Da ich davon die Abhängigkeitsliste gesehen habe, ist mir jetzt schon klar, daß die nicht alle Bugs mitbekommen werden, die in Ihren Komponenten enthalten sind. Das Team hat auch gar keine Kapazitäten um sich darum zu kümmern. Wenn ich jetzt davon ausgehe, daß nicht nur „größere“ Teams Flatpack&CO einsetzen, sondern auch 1-2 Mann Teams, muß man kein Hellseher sein, um den vorprogrammierten Ausgang der Sache zu kennen:
Bei einigen Entwicklern wird es mit den Updates klappen, bei den meisten nicht.
Dazu kommt noch, daß der Anwender sich ja auch noch die Updates ziehen muß. Die müßten automatisch kommen,
ergo ein RPM (o.ä.) sein, womit man dann statt einem Repo, Dutzende hat.
Was ich an Linux gut finde ist, daß es viel Software fertig im Repo gibt und man sich trotzdem noch selbst Software installieren kann, egal ob per RPM oder Selbstkompilierung. Wenn jetzt aber statt der zentralen Repos der Distros, hunderte Repos der Entwicklerteams rumstehen, braucht es schon wieder eine Zentrale Instanz die diese Repos verwaltet, weil sonst nur Google noch weiß, wo es welches Programm gibt. Das Spielchen könnte man noch nen bisschen weiter treiben 😉
Die Essenz ist: Es wird etwas gehypt, was prinzipbedingt Sicherheitslücken generiert, nur um am Ende wieder mit einer Zentralen Instanz zu Enden, um den Kram zu installieren. (: Facepalm 🙂
Dazu möchte ich noch was sagen :
„Die Realität ist, dass viele eher Linux-fremde Entwickler dem Veröffentlichungsmodell über Distributionen wenig abgewinnen können…“
Ich baue seit 5 Jahren selbst RPMs zusammen. Wer dazu länger als 1 Stunde braucht um ein funktionsfähiges RPM zu bauen, daß die Zielplattform installieren kann, sollte das mit dem Verteilen den Distros überlassen.
Beispiel:
File: /usr/src/fedora23/SPECS/example-samba.spec
Name: example-samba
Version: 6
Release: 3
License: GPL
Group: Network
Summary: Sambadriver for Linux
requires: samba samba-common samba-winbind-clients
%description
%post
systemctl restart mydaemon
systemctl start nmb.service
systemctl start smb.service
systemctl enable smb.service
systemctl enable nmb.service
%files
/usr/java/webapps/plattform/WEB-INF/classes/ordb/Sambashares.class
/usr/java/webapps/plattform/WEB-INF/classes/server/drivers/Fedorarelease23/Samba.class
Und wenn man nicht weiß, welche Abhängigkeiten ein Tool hat, kann RPMBUILD das für einen automatisch ermitteln.
NOCH LEICHTER gehts nicht.
Da fällt am Ende ein RPM raus, daß man einfach so per „dnf install ./filename.rpm“ installieren kann. Das wird bei DEB genauso leicht gehen und mehr Majorpacketmanager fallen mir grade nicht ein. Vorteil, keine mitgelieferten Schwachstellen UND so klein wie es geht 🙂
Klar, es könnte zu Überschneidungen kommen, wenn zwei Tools eine Lib mitliefern, die nicht in der Distro ist, aber das echt selten geworden.
Leider scheint die Regel der Menschheit zu sein, sich bei Entscheidungen grundsätzlich für die schlechtere Wahl zu entscheiden 😀 Das liegt uns wohl in den Genen.
Dann können wir ja gemeinsam abwarten und gucken was passiert, umgesetzt werden Snappy und Flatpak ja auf jeden Fall.
Die Position von z.B. owncloud zum Distributionsthema kann man ja nebenbei schonmal nachschlagen.
> Dazu kommt noch, daß der Anwender sich ja auch noch die Updates ziehen muß. Die müßten automatisch kommen,
ergo ein RPM (o.ä.) sein, womit man dann statt einem Repo, Dutzende hat.
Am besten mal mit der Funktionalität von Flatpak und Snappy näher beschäftigen.
> Was ich an Linux gut finde ist, daß es viel Software fertig im Repo gibt und man sich trotzdem noch selbst Software installieren kann, egal ob per RPM oder Selbstkompilierung.
Selbstkompilierung kommt für „Anwender“ nicht in Frage, RPMs kriegen keine Updates.
> Wenn jetzt aber statt der zentralen Repos der Distros, hunderte Repos der Entwicklerteams rumstehen, braucht es schon wieder eine Zentrale Instanz die diese Repos verwaltet, weil sonst nur Google noch weiß, wo es welches Programm gibt. Das Spielchen könnte man noch nen bisschen weiter treiben 😉
1. Gibt es das arch user repo, was sehr voll und es dessen Steuerungsmechanismen super funktionieren.
2. Kann das Programm einfach dort angeboten werden wo es entwickelt wird – bei Entwickler.
Genau, gucken wir doch mal wie es genau kommt.
Danke, das das mal jemand gesagt hat!
Flatpack versucht aber ein bisschen entgegen zu wirken.
Sie haben „enviorment“ packete die als basis für andere dienen (so overlay fs maäßig). Diese sind leichter aktuell zu halten und mit security fixes zu versorgen.
Doch bei darauf basierenden Packete exsistiert das gleiche problem.
Geile Sache. Dann würde so eine Distro – ähnlich wie Windows – erstmal eine halbe Stunde brauchen um den Desktop zu starten, weil sämtliche Programme erstmal ewig Updates suchen, und das alle auf einmal…
Es ist doch gerade das Schöne an den zentralen Softwarerepos, daß man mit einer Instanz sämtliche Updates bekommt. Und nicht alles tausendmal für dieselbe lib, in 1000 verschiedenen Installationen.
Schnöde neue Welt!