Wenn denn jetzt alle meine >4000 installierten Pakete in Zukunft ihre eigenen Bibliotheken mitbringen ... wie findet der Update denn statt, wenn nun eine Basisbibliothek (libc, libstdc++, ...) einen Bugfix/Sicherheitsfix erhält ? Alle Pakete einzeln neu herunterladen ? Das kann ja nicht die Lösung sein...
Nun ja- das macht dann doch immernoch die Paketverwaltung für dich - aber im Prinzip ja. Eine Bibliothek in einem Container wird am einfachsten mit einem neuen Container mit der aktualisierten Bibliothek ersetzt.
Dieses vorgehen hat durchaus auch vorteile, da der Anbieter eines Containers genau weis, welche version welcher Bibliothek du hast. Im Supportumfeld ist das natürlich eine Erleichterung. Ausserdem braucht nicht JEDE Applikation SÄMTLICHE Befehle die eine Bibliothek zur Verfügung stellt. Wenn also ein Bugfix eine Funktion betrifft, die deine App eh nicht verwenden, kannst du die Version überspringen. Wenn es richtig gemacht ist, geht das natürlich auch bei Sicherheitsproblemen. Deine Biblothek hat ein Sicherheitsproblem in einer Funktion die du nicht verwendest: kann dir egal sien, denn ausser der App im Container kann keine andere app diese Biblothek verwenden.
Ich will nicht die Nachteile verleugnen - die gibt es auf jeden Fall, und im Zweifelsfall sitzt der Endanwender mit einer veralteten Bibliothek da.......
Irgendwann zu Anfang als das Gerede über Snappy los ging war da auch mal die Rede von Live Patching wenn ich mich nicht Irre das war genau aus diesem Grunde angedacht damit nicht immer ganze Pakete geladen werden müssen. So das in einem Falle von einem Update nur die DLL und das Update Skript geladen werden muss genau wie es beim 4rer Kernel auch kommen soll mit dem Live Patching.
>> Dieses vorgehen hat durchaus auch vorteile, da der Anbieter eines Containers genau weis, welche version welcher Bibliothek du hast
Das glaubst du doch selber nicht. Du musst dir doch nur mal das Beispiel Docker ansehen. Da sagt der Provider eines Containers : Ich brauch nginx, also apt-get install nginx Welche Bibliotheken damit auf in dem Container landen, darüber hat der Provider doch weder wissen noch Kontrolle, es sei denn er baut seinen Container mit LFS. Das sich diese Provider auf die notwendigen CVE Kanäle subscriben möchte mal ganz stark bezweifeln.
De facto sind Container im Moment brandgefährlich, weil sich offenbar niemand dafür verantwortlich fühlt, die Frage nach Security Upgrades befriedigend zu lösen. Was passiert denn, wenn jemand einen Container mit einem veralteten Sudo oder ein Shellshock Bash auf den "Host" kippt? Ob man will oder nicht, alle Container Inhalte sind schließlich auch für den Host verfügbar...
"und im Zweifelsfall sitzt der Endanwender mit einer veralteten Bibliothek da......."
Genau - und merkt es vermutlich nicht einmal, so wie unter Windows, wo Nutzer jahrelang Ihre uralten Programmversionen einsetzen und dabei kein Stück über die Systemsicherheit nachdenken. Microsoft ist das egal, da es sich ja nicht um Fremdsoftware kümmern muss.
IMO wird Ubuntu ähnlich vorgehen und viele Pakete einfach gar nicht mehr updaten, vor allem die in Universe und Multiverse nicht, so wie das ja fast flächendeckend schon heute der Fall ist. Das dürfte dann die meisten Probleme "lösen".
Auf sicherheitskritischen Rechnersystemen wird IMO Ubuntu dann gar nicht mehr eingesetzt werden, da ein umsichtiger Systemadmin unter Umständen schon weiß, was Ihm blühen kann, nämlich eine Art reversive Dependency Hell beim Update, da er nach einiger Zeit den Überblick darüber verlieren kann, welches Snappy-Paket zu welchem Zeitpunkt mit welchen alten Paketen installiert oder upgedatet wurde. Das ist IMO vergleichbar einem System, in das man unter Umgehung der Paketverwaltung Tarball um Tarball hineininstalliert hat und irgendwann auch nicht mehr weiß, was an Bibliotheken so installiert ist. IMO ist Snappy geradezu prädestiniert für rasche Installationen Dritter, also von Nicht-Distributionssoftware, die man auch malwaremäßig wird ausnutzen können. Einfacher Doppelklick und fertig.
Hätte Ubuntu eine effektive Paketverwaltung wie openSUSE, die in der Lage ist, reversibel unterschiedliche Versionen einer Software jeweils einzeln zu installieren, dann bräuchte Ubuntu kein Snappy. Snappy soll IMO nur den Kardinalfehler von Apt mitbeheben helfen, nicht gleichzeitig mit zig Repositorien auf einfache Weise umgehen zu können. IMO will niemand z.B. Inkscape in zig verschiedenen Versionen nebeneinander installiert haben, sondern jeweils nur die gewünschte alte, aktuelle oder Bleeding-Edge-Version. Und genau die nachträgliche Installation der beiden zuletzt genannten bekommt ein Debian oder Ubuntu "Stable" kaum auf einfache Weise hin. Apt-Pinning ist nichts für Otto Normalnutzer, Priorities über eine funktionierende GUI hingegen schon. Apt und Synaptic bieten hierzu nichts und auch die Red Hat-Paketverwaltung, so wie diese u.a. in RHEL6 als GUI in Erscheinung tritt, ist im Hinblick auf den obigen Sachverhalt an Rückständigkeit nicht zu überbieten.
Bietet Ubuntu hingegen eine Art mehrfach differenzierte Snappy-Serversoftwarecollection an, die für ganz bestimmte Zweck eingesetzt wird und dessen zehn- bis dreizehnjährigen Support Ubuntu dann übernimmt, dann könnte das durchaus erfolgreich sein, als eine Art Speziallösung für besondere Anforderungen.
Was hingegen auf dem Nutzerdesktop ablaufen wird, ist IMO nicht relevant, da hiermit kein Geld verdienen wird. Die Leute bekommen Ihre wahllosen Snappy-Apps über die dafür "verantwortliche" Ubuntu-Community und können sich dann ja dort beschweren, wenn etwas nicht klappt.
Und für die gleichzeitige Installation von unterschiedlich alten Versionen des gleichen Programms gibt es schon lange Konzepte, die Debian und Ubuntu nur niemals einsetzen. Schon zu Suse-Zeiten war das möglich und wurde - falls benötigt - auch massiv praktiziert (Ich verstehe auch nicht, warum der Autor hierauf nicht explizit eingeht, schließlich ist gerade Suse für seine Distributionen, die Altbewährtes nahtlos mit Bleeding Edge-Software verbanden, bekannt gewesen.). IMO ist Snappy nicht eine Lösung für ein vorhandenes Linux-Problem, sondern nur eine Art Versuchslösung für Debian- und Ubuntudefizite in der Paketverwaltung und "Stable"-Distributionszusammenstellung. Sich das riesige Debianarchiv als Sammelsurium an Snappypaketen vorzustellen, ist IMO ein absoluter Alptraum für Maintainer, die Unübersichtlichkeit wäre quasi vorprogrammiert. Wenn ich da nur an die manchmal notwendigen Non-Maintainer-Uploads denke, dann weiß ich, dass Snappy in Debian offiziell keine Chance haben wird.
Zudem gibt es wirkliche Probleme. Ein Beispiel: Noch in Debian Squeeze konnte Synaptic gleichzeitig ohne Fehler Pakete installieren und deinstallieren, das funktioniert in moderneren Versionen gar nicht mehr (so erhalte ich hier plötzlivh sog. Nicht-authentifiziert-Meldungen, obgleich nur Debian Main am Werkeln ist). Die RHEL6-Paketverwaltung verhindert das gleich von vornherein. Aber Ubuntu setzt hier niemals an, das wäre auch zu unspektakulär, zu bodenständig und zu einfach. Ubuntu will wie dereinst Shuttleworth immer nur eines: Zu den Sternen!
Ich teile deine Befürchtungen, wenn es um die Updates solcher Snappy-Pakete geht. Aber der Kritikpunkt den Snappy an zu gehen versucht ist nicht mit einem Welchsel auf rpm + zypper zu beheben. Software wird auch bei OpenSUSE i.d.R. von den Distributoren geliefert und für die meisten Programmierer ist es zu aufwendig diese ganze Matrix aus Distributionen, Distro-Versionen und Bibliotheksversionen zu füllen. Wie bereits zu Beginn des Artikels angesprochen wurde hat ja auch Linus Torvalds mehrfach kritik daran geübt. Unter Windows und MacOS sei es einfach ne Software bereit zu stellen unter Linux überlässt man das lieber den Distributoren.
Die Distributoren leisten in diesem Bereich eine grandiose Arbeit in meinen Augen. Ich habe die Software-Hersteller denen ich das Vertrauen entgegenbringe gewissenhaft zu arbeiten und ich vertraue den Distributoren, dass sie für die Sicherheitsupdates sorgen. Bei Snappy muss ich dem Software-Hersteller sogar vertrauen, dass er die Entwicklungen seiner Abhängigkeiten im Blick hat und entsprechend neue statisch gelinkte Updates erzeugt. Da auch ich schnell mal was schreibe was von vielen Bibliotheken abhängt (direkt oder indirekt) und keinen guten Mechanismus dafür kenne habe ich da auch ne gewisse Angst vor der Zukunft.
Dennoch denke ich nicht, dass Snappy der Untergang von Ubuntu oder dem Linux-Ökosystem ist. Ich habe jetzt in den ganzen Threads zu dem Thema mal wieder viel Ubuntu-Bashing und Shuttleworth-Astronauting gelesen aber nichts darüber, dass Canonical nicht die einzigen sind die sowas entwickeln… Stichwort XDG-Apps.
Es erlaubt Softwareentwicklern, Programme direkt auf ihren eigenen Webseiten zu veröffentlichen und bietet dabei Funktionen, die man von zentralen Repositorien gewöhnt ist, wie z.B. gemeinsam genutzte Bibliotheken, automatische Updates und digitale Signaturen. Es ist als Ergänzung und nicht als Ersatz zur Paketverwaltung des Betriebssystems gedacht. Zero Install-Pakete verursachen nie Konflikte mit Paketen, die von der Distribution zur Verfügung gestellt werden.
Ja und es kommt noch schlimmer, wenn du Pech hast ist mindestens einer der Maintainer deiner Pakete der Meinung das dieser Bugfix nicht wichtig genug ist um eine neue Version seiner Software (wo dieser Bugfix auch mit drin ist) zu verteilen. Dann hast du unter Umständen sogar einen anfälligen Hintergrunddiest im Betrieb und merkst es erst wenn es schon zu spät ist.
Da kommt doch so richtig Freude auf oder?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 04. Jan 2016 um 08:33.
dann wechsel ich doch lieber zu Windows über. Android ist schon ein Krampf was soll das denn bei einem richtigen betriebssystem im arbeitsumfeld werden?
Von mir aus, sollen sie machen, vielleicht wirds, oder es wird mit Snappy so wie mit dem TV, Handy, Mir usw von Canonical. Ich hab nen Strich unter Ubuntu gezogen, nutz Arch da gehts mir blendend
Oh man... Snappy... Der Name wird schon woanders genutzt. Zitat zum Paket "snappy" von rpmfind.net "Snappy is a compression/decompression library" Weiter geht es mit dem Konzept von Snappy selbst, so wie es jetzt angedacht ist, wird es keiner nutzen. Allein die Vorstellung die ganzen Updates über Leitungen wie UMTS etc. zu pressen... nö... Unübersichtlich und kaum auf lange Sicht ersthaft zu pflegen. Auch diese unsinnige Aussage, dass paketieren so aufwendig ist - absoluter Unsinn. Wer das selbst nicht kann, sollte sich an einen Dienstleiter wenden und gut ist. Warum wird nicht z.B. eine Art IDE entwickelt die .rpm und .deb zeitgleich bauen kann. Hierzu noch ein Mechanismus implementiert, der in die jeweiligen Repos der Distributionen schaut ob die passende lib etc. vorhanden ist, um diese dann zur Auflösung der Abhängigkeiten hinzuzufügen. So könnte man noch Stunden weiter machen.
Als IDE Plugin lässt sich sowas schlecht implementieren, es müsste ja für das Bauen der Pakete die jeweilige Distribution in jeder Version heruntergeladen werden dann installiert man die Abhänigkeiten und schließlich baut man das Paket. Den ganzen Prozess führt man dann für x86_64, x86, ARMv6 und ARMv7 durch. OpenSUSE bietet aber in der Tat sowas ähnliches mit dem OpenSUSE Build Service an. Das bietet dem Entwickler aber noch nicht die Möglichkeit z.B. python 3.5 als Dependency für sein Projekt einzuführen, weil in den meisten Distributionen kein Python 3.5 verfügbar ist. Python ist hier natürlich nur ein Beispiel, stellvertretend für alle Abhängigkeiten.
Ja das geht schon in die Richtung aber das dann offline und entsprechend optimiert. Sicherlich könnte man dann auf Basis von Containern oder VMs die Systeme vorhalten. Sicherlich ein nicht unerheblicher Aufwand was die Entwicklung so einer Anwendung angeht, aber ganz sicher würden viele Entwickler das nutzen. Wäre der Bedarf nicht da, wäre ja der OpenSUSE Build Service ein Trauerspiel, die Praxis zeigt aber das Gegenteil.
Das OpenSUSE Build System ist OSS wie Suse selbst, also einem Betrieb auf dem eigenen Rechner steht nichts entgegen. Aber ich persönlich hätte aber keine Lust ne ganze Build-Farm auf meinem Rechner zu betreiben, zum einen wegen des Platzes den es unnötig nimmt und zum anderen weils langsam ist. Letztendlich baut man damit dann auch nur die Pakete, das Repository muss man dann noch gesondert betreiben… das kann ich entspannter bei OpenSUSE Build direkt haben.
Snappy löst übrigens aber auch noch ein paar andere Probleme für 3th Party Entwickler wie z.b. die Integration von Apparmor, Cgroups, Kernel Namespaces und damit einen Shift des Vertrauens bis zu einem gewissen Grad vom Entwickler zum Betriebssystemhersteller.
Wenn ein Programm eine spezifische lib benötigt, dann soll es die statisch einbinden. Punkt. Gerade so wie es jetzt ist, ist ja einer der großen Vorteile des Linux-Systems finde ich. Einfache Updates, keine doppelten Dateien, sinnvolle Ordnerstruktur u.s.w.
Dann höchstens einen User-Mode, wo bestimmte Programme (ähnlich Windows) in das HOME-Verzeichnis installiert werden können.
Wenn denn jetzt alle meine >4000 installierten Pakete in Zukunft ihre eigenen Bibliotheken mitbringen ... wie findet der Update denn statt, wenn nun eine Basisbibliothek (libc, libstdc++, ...) einen Bugfix/Sicherheitsfix erhält ? Alle Pakete einzeln neu herunterladen ? Das kann ja nicht die Lösung sein...
Nun ja- das macht dann doch immernoch die Paketverwaltung für dich - aber im Prinzip ja.
Eine Bibliothek in einem Container wird am einfachsten mit einem neuen Container mit der aktualisierten Bibliothek ersetzt.
Dieses vorgehen hat durchaus auch vorteile, da der Anbieter eines Containers genau weis, welche version welcher Bibliothek du hast. Im Supportumfeld ist das natürlich eine Erleichterung. Ausserdem braucht nicht JEDE Applikation SÄMTLICHE Befehle die eine Bibliothek zur Verfügung stellt. Wenn also ein Bugfix eine Funktion betrifft, die deine App eh nicht verwenden, kannst du die Version überspringen. Wenn es richtig gemacht ist, geht das natürlich auch bei Sicherheitsproblemen. Deine Biblothek hat ein Sicherheitsproblem in einer Funktion die du nicht verwendest: kann dir egal sien, denn ausser der App im Container kann keine andere app diese Biblothek verwenden.
Ich will nicht die Nachteile verleugnen - die gibt es auf jeden Fall, und im Zweifelsfall sitzt der Endanwender mit einer veralteten Bibliothek da.......
Irgendwann zu Anfang als das Gerede über Snappy los ging war da auch mal die Rede von Live Patching wenn ich mich nicht Irre das war genau aus diesem Grunde angedacht damit nicht immer ganze Pakete geladen werden müssen.
So das in einem Falle von einem Update nur die DLL und das Update Skript geladen werden muss genau wie es beim 4rer Kernel auch kommen soll mit dem Live Patching.
>> Dieses vorgehen hat durchaus auch vorteile, da der Anbieter eines Containers genau weis, welche version welcher Bibliothek du hast
Das glaubst du doch selber nicht.
Du musst dir doch nur mal das Beispiel Docker ansehen. Da sagt der Provider eines Containers : Ich brauch nginx, also apt-get install nginx
Welche Bibliotheken damit auf in dem Container landen, darüber hat der Provider doch weder wissen noch Kontrolle, es sei denn er baut seinen Container mit LFS. Das sich diese Provider auf die notwendigen CVE Kanäle subscriben möchte mal ganz stark bezweifeln.
De facto sind Container im Moment brandgefährlich, weil sich offenbar niemand dafür verantwortlich fühlt, die Frage nach Security Upgrades befriedigend zu lösen. Was passiert denn, wenn jemand einen Container mit einem veralteten Sudo oder ein Shellshock Bash auf den "Host" kippt? Ob man will oder nicht, alle Container Inhalte sind schließlich auch für den Host verfügbar...
"und im Zweifelsfall sitzt der Endanwender mit einer veralteten Bibliothek da......."
Genau - und merkt es vermutlich nicht einmal, so wie unter Windows, wo Nutzer jahrelang Ihre uralten Programmversionen einsetzen und dabei kein Stück über die Systemsicherheit nachdenken. Microsoft ist das egal, da es sich ja nicht um Fremdsoftware kümmern muss.
IMO wird Ubuntu ähnlich vorgehen und viele Pakete einfach gar nicht mehr updaten, vor allem die in Universe und Multiverse nicht, so wie das ja fast flächendeckend schon heute der Fall ist. Das dürfte dann die meisten Probleme "lösen".
Auf sicherheitskritischen Rechnersystemen wird IMO Ubuntu dann gar nicht mehr eingesetzt werden, da ein umsichtiger Systemadmin unter Umständen schon weiß, was Ihm blühen kann, nämlich eine Art reversive Dependency Hell beim Update, da er nach einiger Zeit den Überblick darüber verlieren kann, welches Snappy-Paket zu welchem Zeitpunkt mit welchen alten Paketen installiert oder upgedatet wurde. Das ist IMO vergleichbar einem System, in das man unter Umgehung der Paketverwaltung Tarball um Tarball hineininstalliert hat und irgendwann auch nicht mehr weiß, was an Bibliotheken so installiert ist. IMO ist Snappy geradezu prädestiniert für rasche Installationen Dritter, also von Nicht-Distributionssoftware, die man auch malwaremäßig wird ausnutzen können. Einfacher Doppelklick und fertig.
Hätte Ubuntu eine effektive Paketverwaltung wie openSUSE, die in der Lage ist, reversibel unterschiedliche Versionen einer Software jeweils einzeln zu installieren, dann bräuchte Ubuntu kein Snappy. Snappy soll IMO nur den Kardinalfehler von Apt mitbeheben helfen, nicht gleichzeitig mit zig Repositorien auf einfache Weise umgehen zu können. IMO will niemand z.B. Inkscape in zig verschiedenen Versionen nebeneinander installiert haben, sondern jeweils nur die gewünschte alte, aktuelle oder Bleeding-Edge-Version. Und genau die nachträgliche Installation der beiden zuletzt genannten bekommt ein Debian oder Ubuntu "Stable" kaum auf einfache Weise hin. Apt-Pinning ist nichts für Otto Normalnutzer, Priorities über eine funktionierende GUI hingegen schon. Apt und Synaptic bieten hierzu nichts und auch die Red Hat-Paketverwaltung, so wie diese u.a. in RHEL6 als GUI in Erscheinung tritt, ist im Hinblick auf den obigen Sachverhalt an Rückständigkeit nicht zu überbieten.
Bietet Ubuntu hingegen eine Art mehrfach differenzierte Snappy-Serversoftwarecollection an, die für ganz bestimmte Zweck eingesetzt wird und dessen zehn- bis dreizehnjährigen Support Ubuntu dann übernimmt, dann könnte das durchaus erfolgreich sein, als eine Art Speziallösung für besondere Anforderungen.
Was hingegen auf dem Nutzerdesktop ablaufen wird, ist IMO nicht relevant, da hiermit kein Geld verdienen wird. Die Leute bekommen Ihre wahllosen Snappy-Apps über die dafür "verantwortliche" Ubuntu-Community und können sich dann ja dort beschweren, wenn etwas nicht klappt.
Und für die gleichzeitige Installation von unterschiedlich alten Versionen des gleichen Programms gibt es schon lange Konzepte, die Debian und Ubuntu nur niemals einsetzen. Schon zu Suse-Zeiten war das möglich und wurde - falls benötigt - auch massiv praktiziert (Ich verstehe auch nicht, warum der Autor hierauf nicht explizit eingeht, schließlich ist gerade Suse für seine Distributionen, die Altbewährtes nahtlos mit Bleeding Edge-Software verbanden, bekannt gewesen.). IMO ist Snappy nicht eine Lösung für ein vorhandenes Linux-Problem, sondern nur eine Art Versuchslösung für Debian- und Ubuntudefizite in der Paketverwaltung und "Stable"-Distributionszusammenstellung. Sich das riesige Debianarchiv als Sammelsurium an Snappypaketen vorzustellen, ist IMO ein absoluter Alptraum für Maintainer, die Unübersichtlichkeit wäre quasi vorprogrammiert. Wenn ich da nur an die manchmal notwendigen Non-Maintainer-Uploads denke, dann weiß ich, dass Snappy in Debian offiziell keine Chance haben wird.
Zudem gibt es wirkliche Probleme. Ein Beispiel: Noch in Debian Squeeze konnte Synaptic gleichzeitig ohne Fehler Pakete installieren und deinstallieren, das funktioniert in moderneren Versionen gar nicht mehr (so erhalte ich hier plötzlivh sog. Nicht-authentifiziert-Meldungen, obgleich nur Debian Main am Werkeln ist). Die RHEL6-Paketverwaltung verhindert das gleich von vornherein. Aber Ubuntu setzt hier niemals an, das wäre auch zu unspektakulär, zu bodenständig und zu einfach. Ubuntu will wie dereinst Shuttleworth immer nur eines: Zu den Sternen!
Ich teile deine Befürchtungen, wenn es um die Updates solcher Snappy-Pakete geht. Aber der Kritikpunkt den Snappy an zu gehen versucht ist nicht mit einem Welchsel auf rpm + zypper zu beheben. Software wird auch bei OpenSUSE i.d.R. von den Distributoren geliefert und für die meisten Programmierer ist es zu aufwendig diese ganze Matrix aus Distributionen, Distro-Versionen und Bibliotheksversionen zu füllen. Wie bereits zu Beginn des Artikels angesprochen wurde hat ja auch Linus Torvalds mehrfach kritik daran geübt. Unter Windows und MacOS sei es einfach ne Software bereit zu stellen unter Linux überlässt man das lieber den Distributoren.
Die Distributoren leisten in diesem Bereich eine grandiose Arbeit in meinen Augen. Ich habe die Software-Hersteller denen ich das Vertrauen entgegenbringe gewissenhaft zu arbeiten und ich vertraue den Distributoren, dass sie für die Sicherheitsupdates sorgen. Bei Snappy muss ich dem Software-Hersteller sogar vertrauen, dass er die Entwicklungen seiner Abhängigkeiten im Blick hat und entsprechend neue statisch gelinkte Updates erzeugt. Da auch ich schnell mal was schreibe was von vielen Bibliotheken abhängt (direkt oder indirekt) und keinen guten Mechanismus dafür kenne habe ich da auch ne gewisse Angst vor der Zukunft.
Dennoch denke ich nicht, dass Snappy der Untergang von Ubuntu oder dem Linux-Ökosystem ist. Ich habe jetzt in den ganzen Threads zu dem Thema mal wieder viel Ubuntu-Bashing und Shuttleworth-Astronauting gelesen aber nichts darüber, dass Canonical nicht die einzigen sind die sowas entwickeln… Stichwort XDG-Apps.
Die richtige Lösung wäre m.E. Rolling Release oder ein Peketmanager wie GNU Guix.
Eher wohl eine Lösung wie diese hier:
Pro-Linux: Zeroinstall
Ja und es kommt noch schlimmer, wenn du Pech hast ist mindestens einer der Maintainer deiner Pakete der Meinung das dieser Bugfix nicht wichtig genug ist um eine neue Version seiner Software (wo dieser Bugfix auch mit drin ist) zu verteilen. Dann hast du unter Umständen sogar einen anfälligen Hintergrunddiest im Betrieb und merkst es erst wenn es schon zu spät ist.
Da kommt doch so richtig Freude auf oder?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 04. Jan 2016 um 08:33.dann wechsel ich doch lieber zu Windows über.
Android ist schon ein Krampf was soll das denn bei einem
richtigen betriebssystem im arbeitsumfeld werden?
der paul
Der war gut, das ist ja genau was Windows macht, nur halt ohne spezielle Vorgaben von MS und ohne Paketmanager -> das Chaos ist perfekt.
Von mir aus, sollen sie machen, vielleicht wirds, oder es wird mit Snappy so wie mit dem TV, Handy, Mir usw von Canonical.
Ich hab nen Strich unter Ubuntu gezogen, nutz Arch da gehts mir blendend
Der Egon
Oh man... Snappy... Der Name wird schon woanders genutzt. Zitat zum Paket "snappy" von rpmfind.net "Snappy is a compression/decompression library" Weiter geht es mit dem Konzept von Snappy selbst, so wie es jetzt angedacht ist, wird es keiner nutzen. Allein die Vorstellung die ganzen Updates über Leitungen wie UMTS etc. zu pressen... nö... Unübersichtlich und kaum auf lange Sicht ersthaft zu pflegen. Auch diese unsinnige Aussage, dass paketieren so aufwendig ist - absoluter Unsinn. Wer das selbst nicht kann, sollte sich an einen Dienstleiter wenden und gut ist. Warum wird nicht z.B. eine Art IDE entwickelt die .rpm und .deb zeitgleich bauen kann. Hierzu noch ein Mechanismus implementiert, der in die jeweiligen Repos der Distributionen schaut ob die passende lib etc. vorhanden ist, um diese dann zur Auflösung der Abhängigkeiten hinzuzufügen. So könnte man noch Stunden weiter machen.
Als IDE Plugin lässt sich sowas schlecht implementieren, es müsste ja für das Bauen der Pakete die jeweilige Distribution in jeder Version heruntergeladen werden dann installiert man die Abhänigkeiten und schließlich baut man das Paket. Den ganzen Prozess führt man dann für x86_64, x86, ARMv6 und ARMv7 durch. OpenSUSE bietet aber in der Tat sowas ähnliches mit dem OpenSUSE Build Service an. Das bietet dem Entwickler aber noch nicht die Möglichkeit z.B. python 3.5 als Dependency für sein Projekt einzuführen, weil in den meisten Distributionen kein Python 3.5 verfügbar ist. Python ist hier natürlich nur ein Beispiel, stellvertretend für alle Abhängigkeiten.
Ja das geht schon in die Richtung aber das dann offline und entsprechend optimiert. Sicherlich könnte man dann auf Basis von Containern oder VMs die Systeme vorhalten. Sicherlich ein nicht unerheblicher Aufwand was die Entwicklung so einer Anwendung angeht, aber ganz sicher würden viele Entwickler das nutzen. Wäre der Bedarf nicht da, wäre ja der OpenSUSE Build Service ein Trauerspiel, die Praxis zeigt aber das Gegenteil.
Das OpenSUSE Build System ist OSS wie Suse selbst, also einem Betrieb auf dem eigenen Rechner steht nichts entgegen. Aber ich persönlich hätte aber keine Lust ne ganze Build-Farm auf meinem Rechner zu betreiben, zum einen wegen des Platzes den es unnötig nimmt und zum anderen weils langsam ist. Letztendlich baut man damit dann auch nur die Pakete, das Repository muss man dann noch gesondert betreiben… das kann ich entspannter bei OpenSUSE Build direkt haben.
Snappy löst übrigens aber auch noch ein paar andere Probleme für 3th Party Entwickler wie z.b. die Integration von Apparmor, Cgroups, Kernel Namespaces und damit einen Shift des Vertrauens bis zu einem gewissen Grad vom Entwickler zum Betriebssystemhersteller.
Ian Murdock ist leider verstorben, am letzten Montag. R.I.P., Debiangründer. Mein tiefstes Beileid an seine Familie.
Siehe
https://bits.debian.org/2015/12/mourning-ian-murdock.html
Wenn ein Programm eine spezifische lib benötigt, dann soll es die statisch einbinden. Punkt.
Gerade so wie es jetzt ist, ist ja einer der großen Vorteile des Linux-Systems finde ich. Einfache Updates, keine doppelten Dateien, sinnvolle Ordnerstruktur u.s.w.
Dann höchstens einen User-Mode, wo bestimmte Programme (ähnlich Windows) in das HOME-Verzeichnis installiert werden können.
Sind eben nicht gerade die Apps(-Container) Schuld an der Inkontinez eigener Daten und an der Inkonsistenz der gesamten Update-Politik?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 04. Jan 2016 um 09:52.