Das Wort 'überkommen' ist völlig korrektes Deutsch und nichts was Anlass gibt, sich lustig zu machen. Siehe Duden: http://www.duden.de/suchen/dudenonline/%C3%BCberkommen
Nur weil ein Wort als veraltet gilt, heißt das für mich nicht, es nicht zu verwenden. Ich bin auch alt und darf das
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 15. Apr 2016 um 14:09.
Ich habe ja auch nichts gegen das Wort, sondern fand es im Zusammenhang mit Deb-Paketen lustig (allerdings nur bis ich anfangen musste zu erklären, dass ich kein deb-Hasser bin und dass ich deutsch verstehe). Ich dachte, mein erster Beitrag würde als unernst erkannt.
bitte nicht dieses Buch 'hin. oder her' werfen, sondern 'blättern': also diese dünnen 'Dinger' zwischen den dicken 'Dingern' mit den Fingern bearbeiten, aber nicht an den Fingern 'lecken', da sonst 'fremde' Substanzen in deinen Körper gelangen könnten, um allergisch zu reagieren.
hoffe dir mit diesem Text reichlich Freudsches' geliefert haben zu können
Libreoffice hab ich mir immer aktualisiert bis jetzt immer über PPA... führt aber auch zu Problemen wie ich aktuell habe aber keine Lust/Zeit da Stundenlang nach eine Lösung zu suchen. Ich hoffe das erledigt sich damit
... Warum? Scheinbar bricht man mit der alten Regel "Keine statischen Abhängigkeiten in die Binaries linken". Okay - das kann man - wenn man Gründe hat - machen.
Aber warum ein neues Paketformat? Hätte man nicht ein eigenes Repository für genau diesen Fall einrichten können, welches Paketnamen mit einem Präfix beinhaltet, und dort Abhängigkeiten mitliefert?
Danke genau das gleiche hab ich auch gedacht!!! Snap bringt hoechstens was fuer Cloud-Server und da nehm ich dann lieber gleich etwas wie CoreOS oder OSv wo auch gleich das ganze BS und Applikation als ein Paket Versioniert ist.
Ich vermute der Nachteil von Snaps wird sein, dass die Snap Programme mehr Platz brauchen und nicht so schnell laufen wie die DEB Programme. Dürfte mehr etwas für den Privat oder kleineren Betrieb sein, wo die Nachteile unwichtig sind, als für so etwas wie Cloud oder mit Servern.
Snaps sind im Schnitt deutlich größer, ja. Warum die Anwendungen dann aber langsamer laufen sollen erschließt sich mir nicht.
In der "Cloud" und im Server-Umfeld ist es heute übrigens normal, dass man seine Anwendungen "Snappy-artig" zusammenpackt und ganze Instanzen automatisiert bespielt. Snappy geht da genau den Weg, den andere schon lange gehen.
Mit Ausfuehrgeschwindikeit hatte ein Paketformat noch nie was zu tun (von der Installation/Update mal abgesehen), Snap wurde fuer die Cloudversion von Ubuntu entwickelt damit ein Server Versioniert und im Falle von Fehlern wieder zurueck-Versioniert werden kann ohne andere Dienste zu beeintraechtigen, Speicherplatz fuer das BS ist heute einfach nicht mehr wichtig es interessiert nicht ob du 3 oder 5GB fuer das BS brauchst, updates ohne Risiko und ohne/minimaler Downtime das ist wichtig, siehe Docker/RK/OSv halt die ganzen "Applikation und BS sind ein Packet welches von A-Z Versioniert werden kann"-Ansaetze.
1. mehr Desktop/Mobile-Benutzer zu haben. Die wollen wiederum aktuelle Programmversionen. Der Benuzter will sich nicht damit auseinandersetzen, warum er jetzt LibreOffice extra über dpkg -i oder über ein PPA installieren muss. Und er versteht auch nicht, warum die neueste Version eben von einer recht neuen Bibliothek abhängt und deshalb nicht einfach so zu kompilieren ist. Er will eine 1-Click-Lösung. Wobei ich nicht unbedingt glaube, dass Canonical's Snap die beste Lösung ist wenn nicht wirklich die meisten beliebten Distri das auffangen. xdg-app von Gnome finde ich da eleganter.
2. für Entwickler letztlich eine Plattform zu schaffen, bei der sie mal eben in eine Datei reinschreiben: "Brauche Abhängikeiten foo in Version bar", wobei das Snap Paket dann selber wissen muss, ob das jetzt 16.04 oder 18.04 oder, und das wäre wohl besser, ob es Ubuntu, Debian, Suse... ist.Snaps sind dann eine elegante Lösung, weil sie eher wie Container aufgebaut sind, als debs. Das bringt bei potentiellem Risiko zumindest mehr Sicherheit (denn ich kann ja nicht wirklich wissen, ob ich der Software trauen kann und der Entwickler hat auch keine Zeit für so Sachen wie "reproducible builds", die sich dann auch auf allen Distri anderst gestalten werden wenn sie denn mal Standard werden.
Repositories haben den Nachteil, dass sie extrem von den ganzen dynamischen Bibliotheken im System abhängen (andererseits wollen wir aber auch nicht auf diese als stabile Basis verzichten, weshalb wir es als Grundsystem beibehalten).
Ubuntu kümmert sich nicht mehr um den Desktop und auch nicht mehr um die Mobilgeräte. Snappy unterstützt erst mal nur Mir, X11-Legacy-Apps laufen mittels XMir in einem abgeschotteten Container und bereits jetzt gibt es kaum Anstrengungen, die X11-Apps "ordentlich" und mit allen Features zu unterstützen. Gleichzeitig kümmert sich einfach niemand darum, Software auf Mir und das mit Snappy einhergehende Confinement-Modell zu portieren oder neu dafür zu entwickeln. Der App-Store für die Mobilgeräte ist ausgestorben, kein einziger kommerzieller Partner hat auch nur eine einzige Anwendung für das neue Modell herausgebracht.
Snappy Ubuntu Core sieht übrigens auch wieder Dependencies zwischen Snaps vor, da sonst z.B. jede Qt-Anwendung eine komplette Qt-Installation mitbringen muss - im Moment ist das so und die ersten einfachen GUI-Anwendungen sind installiert jeweils ca. 450 MB groß. Deswegen gibt es dann am Ende "Library Snaps", z.B. könnte man Qt 5.4 und Qt 5.5 parallel als Snaps installiert haben und Anwendungen könnten dann jeweils die für sie richtige Dependency drauf haben.
Am Ende ist Snappy einfach nur der Weg, wie Canonical endlich profitabel werden will. Statt einer vollständig freien Distribution, welche von Canonical gepflegt werden muss und jederzeit von anderen vollständig geforkt und erweitert werden kann, minimiert Canonical seinen Aufwand auf die Pflege eines winzigen Ubuntu-Root-Dateisystems, betreibt einen proprietären Store und lässt andere Leute die ganzen Snaps packagen. Canonical nimmt Geld für Dienstleistungen, den Betrieb des Store und so weiter. Die Snaps mit den Kerneln und Treibern kommen von irgendwelchen Hardware-Firmen, die Library Snaps kommen von den Entwicklern der ganzen Libraries und Toolkits, die Anwendungs-Snaps direkt von den Open-Source-Projekten und kommerziellen Anbietern. Es gibt keine Source-Snaps, nicht mal für Snaps welche Open-Source-Software beinhalten, und die Lizenzbedingungen des Store erlauben nur Canonical, hochgeladene Snaps an ihre Kunden weiterzuverteilen. Es ist also mit Snappy Ubuntu Core überhaupt nicht mehr möglich, Ubuntu zu forken. Canonical interessiert sich auch nicht dafür, wie die bisher existierenden "Flavors" (XUbuntu, KUbuntu etc.) mit Snappy klarkommen sollen - die Entwickler werden weder informiert noch unterstützt.
Ich sagte weder dass sie es gut machen, noch dass sie es aus software-ethischen Beweggründen machen, daher würde ich mit dir mitgehen.
Sie meinten aber, sie würden Snaps für 16.04 unterstützen, auch auf den Desktop Umgebungen.
Klar kann und soll es Abhängigkeiten zwischen den Snaps geben (Warum 10x wie bei Windows Qt oder libmp3irgendwas installieren?).
"Canonical interessiert sich auch nicht dafür, wie die bisher existierenden "Flavors" (XUbuntu, KUbuntu etc.) mit Snappy klarkommen sollen - die Entwickler werden weder informiert noch unterstützt."
Die sind genauso wie wir mit solchen Artikeln drüber informiert und sie verfolgen auch die Entwicklung der "Core" Komponenten. Snaps sind doch über CLI Tools zu managen, daher verstehe ich nicht, was du mit Unterstützung meinst? Keine der anderen offiziellen Flavours setzt doch andere CLI Programme, Paketmanager und dergleichen ein. Und als GUI kann jedes der Flavours das Gnome Sosftware Ding nehmen. Muon für Kubuntu oder das Lubuntu Software Center werden das bestimmt auch einbinden.
Snappy ist nicht nur ein Paketformat. Snappy funktioniert nicht wie APT über öffentliche Repositories, welche am Ende nur Verzeichnisse mit den richtigen, öffentlich zugänglichen Dateien sind und beliebig gemirrort, kopiert, modifiziert und auf dem Client beliebig gemischt werden können. Snappy kennt nur den Canonical Store, dessen Serverseite komplett proprietär ist. Es gibt keine Mirror mehr, und PPAs sind nicht vorgesehen. Canonical hostet alles und kontrolliert alles, kann man sich exakt so vorstellen wie den Google Play Store, nur ein kleines bisschen umfassender und ausgereifter.
Gleichzeitig ist es bei Snappy durch das Confinement so, dass die Veröffentlichung eines Snap-Paketes, welches "priviliegierte" Dinge tun möchte, eine privilegierte Operation darstellt. Beispiel: Kubuntu will die ganzen KDE-Libraries und KDE-Systemdienste (z.B. zum mounten von Datenträgern) in Form eines Library-Snaps ausliefern, damit alle anderen KDE-Anwendungen darauf aufsetzen können. Canonical erlaubt das nur, wenn es eine "Vertragsbeziehung" mit Canonical gibt und diese privilegierten Snaps zusammen mit Canonical entwickelt werden. Das wurde den Flavors weder so mitgeteilt noch werden sie involviert.
Canonical wird Ubuntu bald auf "All Snap" umstellen, die ganze Distribution basiert dann also vom Kernel bis zu den Anwendungen nur noch auf Snaps. Ein entsprechendes Image für eine virtuelle Maschine gibt es bereits, und ich glaube absolut nicht, dass Canonical die parallele Pflege der DEB-Variante auch nur ansatzweise so lange durchziehen wird, wie man den Leuten derzeit erzählt. Das sieht man alleine schon daran, dass quasi alle Mitarbeiter nur noch auf die Snappy-Welt hinarbeiten. Deswegen schleift ja die Weiterentwicklung der Mobilgeräte so vor sich hin, die ganzen Leute wurden abgezogen und arbeiten an Snappy.
In dieser schönen neuen Snappy-Welt gibt es derzeit kein Kubuntu, kein Xubuntu, kein Ubuntu MATE. Und Canonical tut auch absolut nichts dafür, dass es in der schönen neuen Welt überhaupt noch offizielle Flavors gibt.
Von Shalok Shalom am Sa, 16. April 2016 um 20:52 #
" Snappy kennt nur den Canonical Store, dessen Serverseite komplett proprietär ist. Es gibt keine Mirror mehr, und PPAs sind nicht vorgesehen. Canonical hostet alles und kontrolliert alles, kann man sich exakt so vorstellen wie den Google Play Store"
So sehr ich auch gerne glauben möchte, das Canonical so was zuzutrauen ist, frage ich dich der Vollständigkeit halber nach deiner Quelle.
Jedenfalls was die Erstellung von snaps angeht, gibt es da auch andere Wege:
Man kann Snaps natürlich lokal mit irgendwelchen Tools erstellen, und man kann sie auch lokal mit irgendwelchen Tools manuell installieren. Das ist bei Android auch so. Aber das Client-Tool, welches "apt" oder "apt-get" entspricht und für den Endnutzer danach den ganzen Kern der Sache darstellt, sieht als Online-Quelle für Snaps nur den Canonical-Store vor, und der versteckt alle Daten hinter einer API. Das ist nicht mehr wie bei APT, es gibt keine sources.list-Datei welche einfach vom Nutzer geändert werden kann und aus welcher sich APT die Download-Pfade für seine Metadaten und die Pakete zusammenbaut. Alles ist hartcodiert (siehe https://github.com/ubuntu-core/snappy/blob/master/store/snap_remote_repo.go) und es ist nicht vorgesehen, dass jemand noch weitere Stores neben Canonical betreibt. Dafür müsste man derzeit wohl die ganze Serverseite reverse-engineeren und den Snappy-Client patchen.
Man könnte übrigens auch gar keine Kopie aller Inhalte des Canonical-Stores ziehen und die Snaps selbst anbieten, so wie man das ja macht wenn man Ubuntu bislang geforkt hat, denn wer in den Canonical Store hochlädt oder diesen nutzt, akzeptiert https://myapps.developer.ubuntu.com/dev/tos/ . Demnach erteilt derjenige, der ein Snap in den Store hochlädt, ausschließlich Canonical das Recht, dieses Snap mit Hilfe eines von Canonical zur Verfügung gestellten Clients an seine Kunden weiterzuverbreiten. Man müsste also jeden einzelnen Autor fragen, ob er erlaubt, dass sein Snap auch in alternativen Stores angeboten wird. Snaps selbst aus den Sourcen bauen geht auch nicht so einfach, im Gegensatz zur DEB-Variante kennt Snappy überhaupt keine Source-Pakete. Im Prinzip erlaubt es diese Lizenz nicht mal, ein von Canonical nicht offiziell abgesegnetes Derivat zu betreiben, denn dieses Derivat hat erst mal kein Recht, den Store als Paketquelle zu nutzen.
Das ist seit Monaten so bekannt, es will sich aber wohl niemand offiziell dazu äußern. Käme ja auch schlecht an, wenn man zugeben müsste, dass es solche Forks wie Linux Mint dank Snappy dann eigentlich nicht mehr geben kann. Natürlich wird sich Canonical erst mal davor hüten, diese Regeln strikt auszulegen, aber das ganze Design von Snappy und vor allem die neuen Lizenzen sprechen eine mehr als deutliche Sprache, insbesondere dann, wenn man mal bedenkt, an welche Rechte und Möglichkeiten Nutzer und Entwickler durch die Debian-Herkunft eigentlich gewöhnt sind.
Von .-,-.,-.,-.,-.,-. am So, 17. April 2016 um 17:01 #
Nicht nur Debiannutzer. Kein Fedora-, Mandriva- oder Fedoranutzer würde sich so einen kapitalen Stuss gefallen lassen oder sogar dafür programmieren.
Auch für kostenlos herunterladbare Snaps, die freie GPL-Software sind, müssen die Quellen zur Verfügung gestellt werden. Jetzt schreibst Du, dass Snappy gar keine Source-Pakete kennen würde. Wird dann im Canonical Snaps-Store grundsätzlich gar keine GPL-Software angeboten?
Canonical verhält sich in Lizenzfragen immer merkwürdiger. So kann sich Shuttleworth offensichtlich gar nicht vorstellen, dass Oracle sein Canonical wegen einer ZFS-Lizenzverletzung in Ubuntu 16.04 verklagen wird. Die Klage wird bestimmt dann kommen, wenn Ubuntu 16.04 bereits eine gewisse Verbreitung erreicht hat, damit sich das auch lohnt. Fragt man Oracle deswegen an, lautet die Antwort für Linuxnutzer immer: Benutzen Sie Btrfs bei Linux-Lizenzproblemen. Das eigene Oracle Unbreakable Linux darf deshalb kein ZFS anbieten und das, obwohl das von Oracle gekaufte Sun ZFS für Solaris 10 selbst entwickelt hatte (!).
Und nun glaubt Canonical, sich das herausnehmen zu können, was sich Oracle selbst nicht erlauben darf.
Der Canonical-Store enthält natürlich auch jetzt schon freie Software. Im Gegensatz zum bisherigen (Debian-)Modell wird der Sourcecode aber nicht jedes Mal parallel mit in den Store hochgeladen, sondern Canonical wälzt die rechtlichen Konsequenzen auf den Uploader ab, so wie es Google und Apple auch tun. Der Uploader muss die Sourcen irgendwo hinterlegen, im Optimalfall bietet das Projekt selbst die notwendigen Snappy-Metadaten an, man checkt die Sourcen aus und erhält mit "snapcraft snap" das Paket. Dass dabei kein Source-Snap abfällt, zeigt z.B. das Bild hier.
Das zieht auch noch alle möglichen anderen Probleme nach sich, z.B. kann man nebenbei auch nicht mehr nachvollziehen, ob und wie das Paket im Store aus den offiziellen Sourcen entstanden ist, da der Uploader das Snap-Paket lokal bei sich auf dem Rechner baut und weder den Stand des Sourcecodes, welchen er verwendet hat, noch den "Bauplan" für das Snap hochladen muss. Wer also Zweifel hat, kann nicht mehr einfach wie früher das Source-Paket herunterladen, kontrollieren und lokal selbst noch mal neu bauen.
" und lässt andere Leute die ganzen Snaps packagen. "
Angesichts dessen, was Du da gerade zur letztendlich proprietären Natur von Snaps geschrieben hast, wird genau das IMO nicht passieren. Es wird so gut wie niemand aus der Entwicklercommunity irgendwelche Snaps packagen. Wer entwickelt ohne explizites Eigeninteresse schon kostenlos für einen Millionär mit derartigen versteckten Sezessionsallüren?
Und die Nutzer, die wahrscheinlich dann gerne so ziemlich jede Software als Snap hätten, können meistens genau das nicht: Pakete bauen.
Mein Vorschlag: U.a. Kubuntu, Xubuntu, Lubuntu, Ubuntu Mate, Ubuntu Gnome, Ubuntustudio und Linux Mint sollten sich zusammensetzen und ein neues, wirklich selbständiges Ubuntu ins Leben rufen und ganz formell Canonicals Schoß verlassen.
Von Shalok Shalom am Sa, 16. April 2016 um 19:34 #
"Mein Vorschlag: U.a. Kubuntu, Xubuntu, Lubuntu, Ubuntu Mate, Ubuntu Gnome, Ubuntustudio und Linux Mint sollten sich zusammensetzen und ein neues, wirklich selbständiges Ubuntu ins Leben rufen und ganz formell Canonicals Schoß verlassen."
Klingt gut. Nur: Wenn sie so weit sind, können sie vielleicht auch gleich from Scratch bauen, um die ganzen Altlasten wie apt-get loszuwerden.
Das geht natürlich nur, wenn sie einsichtig sind.
Darüber hinaus halte ich es für sinnvoll, wenn sich alle einen "Server Stack" zusammenbauen, mit dem sie leben können:
Und dann, auf ihren jeweilige eigenen Repos alles von X11 und Wayland selbst wegbauen.
So sparen sie sich Arbeit und können immer noch für ihre DEs selbstständig entscheiden.
Auch jetzt profitieren die einzelnen Spins doch einfach vom Namen, ein Großteil der Pakete und Infrastruktor kommt sowieso schon längst von Debian beziehungsweise eigenen Quellen.
Gerade Mint hat den jedoch nicht nötig, wie wir sehen. Ich persönlich sehe auch die Basis einer bestehenden Distribution wie KaOS als hilfreich, weil gerade da vorgezeigt wird, wie es funktionieren kann, sich auf eine DE zu konzentrieren: Kubuntu könnte sogar gleich den gesamten Stack adaptieren, was ihnen die Entscheidung sinngemäß erleichtert.
Sie wollen alle nicht für sich genommen von Canonical weg, in Summe sind sie stark genug.
Ich begrüsse deine Idee also und wenn du dies auch willst, können wir ja gemeinsam ein derartiges Konzept entwerfen und den jeweiligen Distributionen dann vorlegen.
Das ist viel zu bürokratisch, zumal es sich um kleine und sehr kleine Teams handelt. Die Mailinglisten und üblichen Ubuntuforen bieten da viel bessere Möglichkeiten.
Die Hauptvoraussetzung fehlt zudem noch: Ubuntu muss das alte deb-apt-System tatsächlich zugunsten von Snap vernachlässigen und so die Ubuntu-Varianten z.B. ab Ubuntu 18.04 automatisch gegen die dann vielleicht nicht mehr supportete deb-apt-Wand fahren lassen. Zur Zeit fehlt dieser Druck zur Entscheidung zwischen dem klassischen deb-apt und dem neuen snapd völlig.
Von Shalok Shalom am Sa, 16. April 2016 um 22:00 #
"Das ist viel zu bürokratisch, zumal es sich um kleine und sehr kleine Teams handelt. Die Mailinglisten und üblichen Ubuntuforen bieten da viel bessere Möglichkeiten."
Auf welchen Satz beziehst du dich hier?
"Die Hauptvoraussetzung fehlt zudem noch: Ubuntu muss das alte deb-apt-System tatsächlich zugunsten von Snap vernachlässigen und so die Ubuntu-Varianten z.B. ab Ubuntu 18.04 automatisch gegen die dann vielleicht nicht mehr supportete deb-apt-Wand fahren lassen. Zur Zeit fehlt dieser Druck zur Entscheidung zwischen dem klassischen deb-apt und dem neuen snapd völlig."
Intelligente Entwickler erkennen, bevor ein System gegen die Wand fährt. Und willst du stumpfsinnige Entwickler in einem Projekt?
Die Situation gibts ja schon bei den Mobilgeräten. Quasi niemand hat irgendwelche Software auf Mir und Confinement portiert, 90% der Apps im Store sind Webapps, und die kann man halt auch mehr oder weniger automatisiert generieren lassen. Kommerzielle Drittanbieter haben keine einzige App für die Mobilgeräte herausgebracht, und das ist ja die "Zielgruppe", um die es bei Snappy vorrangig zu gehen scheint. Im Snappy Store stehen derzeit erst so ungefähr 40 Pakete, obwohl Canonical ja eigentlich schon vergleichsweise viele Partner aus dem Embedded-Bereich vorweisen kann. Keine Ahnung, ob die alle noch abwarten, oder ob es da bereits "geheime" Abteilungen im Store gibt und man die Packages deswegen einfach nicht sieht. "Sub-Stores" sind ja angeblich explizit vorgesehen, z.B. könnte Dell seinen Kunden dann Apps zum Download anbieten, welche die Nutzer anderer Geräte nicht sehen.
Die eigentliche Frage zu anfangs wird ja für Desktopnutzer wohl eher folgender Natur sein, nämlich, ob man die nächste KDE- oder Xfce-Version, die irgendwann einmal nach dem 16.04-Release herauskommen und in einem späteren Kubuntu oder Xubuntu enthalten sein wird, bei Kubuntu oder Xubuntu für eine dann ältere Version wie 16.04 als Snap-Paket zum Nachinstallieren herausbringt oder nicht.
Ich glaube im Moment ist die eigentliche Frage, wie sich Canonical das mit Mir, Wayland und X11 vorstellt. Damals wurde ja behauptet, die Flavors könnten weiterhin X.Org oder auch Wayland nehmen und müssten sich nicht für Mir entscheiden. Jetzt ist es aber so, dass Canonical Snappy einzig und allein um Mir herum aufbaut und nicht mal X11-Kompatibilität besteht, geschweige denn Wayland vorgesehen ist. Das Convergence-Tablet machts vor: Alle X11-Anwendungen laufen dort in einem "Legacy"-Container, in welchem ein DEB-basiertes Ubuntu installiert ist. XMir vermittelt dann zwischen Container und Hauptsystem. So wies aktuell aussieht, kann man also weder irgendwelche anderen Desktops noch X11-Anwendungen als Snap packagen, solange die Entwickler sich nicht nach Canonical richten und komplett auf den Zug aufspringen.
Eine gewagte Strategie, wenn man sich anschaut, wie stark andere Desktop-Distributionen mittlerweile aufgeholt haben. Selbst Debian hat nachgezogen, mittlerweile liegt der Vorteil von Ubuntu 16.04 gegenüber Debian 8 für mich hauptsächlich in ein paar vorinstallierten Firmware-Dateien, einer aktuelleren X.Org-Version und der Integration des proprietären NVIDIA-Treibers. Auf der anderen Seite hat Ubuntu so einiges schleifen lassen, ich laufe immer wieder in kleinere Details, welche unter Ubuntu 16.04 nicht richtig laufen, aber unter Debian 8 schon. Das fängt bei der Tastaturbelegung beim Booten an (Ubuntu steht während der Eingabe des Verschlüsselungspassworts für die Festplatte immer auf Englisch statt Deutsch...) und geht zu so Dingen wie "Die GNOME Wayland Sitzung tut unter Debian einfach problemlos, unter Ubuntu startet sie gar nicht". Ubuntu 16.04 wirkt auf mich deutlich weniger abgerundet als die vergangenen LTS-Versionen.
Jeweils 450 MB, kann ich mir kaum vorstellen... Wenn ich eine Android App mit Qt erstelle, ist die zwar auch größer (so um die 50 MB), aber keine 450+ MB.
Auch die DLLs von Windows Qt Anwendungen sind nicht so groß...
Habe jetzt im Programmverzeichnis mal nachgesehen. Die Qt dlls haben insgesamt eine Größe von 17,2 MB, also entpackt. Weit weg von mehreren hundert MB, wie es hier gesagt wurde.
Die Entwicklungsversionen benötigen einiges mehr an Speicherplatz, da braucht man ja auch Header Dateien und evtl. den Source Code und das braucht alles mehr Speicherplatz.
Snap ist für mich als Endanwender völlig aussen vor. Für mich ist DEB/Synaptic das Maß der Dinge. Was mich stutzig macht, ist das die Redmonter auch so ihre Eier im Kochtopf haben. Frage: Snap von Cannonical als langfristig geplante BS-übergreifendes Format ? Mal abwarten, was da noch kommt.
Also wenn es so ist, wie snappy beim Raspberry PI angeboten wird, dann können wir es vergessen. Nicht mal das simple Testprogramm auf deren Seite bekommt man ans lauifen, also habe ich alles sofort wieder gelöscht. Wie so häufig, alles nur Gerede. Dann ist diese Version veraltet und jene nicht geeignet. KW
Hello here its the Ubuntu 16.04 Wallpaper http://lightpics.net/album/6O
Ah bist wohl ein MSI-Fan oder glaubst das RPM "besser" ist?
Nein, ich habe mich nur über die Vokabel "überkommen" lustig gemacht.
Was ist an korrektem Deutsch lustig? Dass Du es nicht verstehst?
Vielleicht könntet ihr euch auf altübernommenen einigen...
Habe ich den Eindruck erweckt, dass ich das nicht verstehe?
Ja.
?
Ich bin ehrlich gesagt ratlos....
Das Wort 'überkommen' ist völlig korrektes Deutsch und nichts was Anlass gibt, sich lustig zu machen. Siehe Duden: http://www.duden.de/suchen/dudenonline/%C3%BCberkommen
Nur weil ein Wort als veraltet gilt, heißt das für mich nicht, es nicht zu verwenden. Ich bin auch alt und darf das
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 15. Apr 2016 um 14:09.Ich habe ja auch nichts gegen das Wort, sondern fand es im Zusammenhang mit Deb-Paketen lustig (allerdings nur bis ich anfangen musste zu erklären, dass ich kein deb-Hasser bin und dass ich deutsch verstehe). Ich dachte, mein erster Beitrag würde als unernst erkannt.
Du bist nicht alt, du bist stable
ganz klarer Fall von old-stable :^)
boah, alt is ja ok, aber stable und old-stable? Ihr hört von meinem Anwalt
boah, alt is ja ok, aber stable und old-stable? Ihr hört von meinem Anwalt
oha!
bitte aber nicht in überkommender Weise uns in einen Topf werfen
Duden hin oder her, gemeint ist hier wohl "übernommen", und da ist "überkommen" nun wirklich ein lustiger (Freud'scher) Vertipper...
Ist es wirklich so schwer? Ich meinte überkommen und nichts anderes. Lass Freud da mal besser raus.
Ho, Ho - David^^
bitte nicht dieses Buch 'hin. oder her' werfen, sondern 'blättern': also diese dünnen 'Dinger' zwischen den dicken 'Dingern' mit den Fingern bearbeiten, aber nicht an den Fingern 'lecken', da sonst 'fremde' Substanzen in deinen Körper gelangen könnten, um allergisch zu reagieren.
hoffe dir mit diesem Text reichlich Freudsches' geliefert haben zu können
/sarcasm
Das hört sich gut an... ...für einzelne Pakete, die nicht aus dem offiziellen Repository stammen.
Letztendlich im Ansatz auch nichts anderes, als Mac OS DMGs.
Mal von der ikrementellen Updaterei und dem Management abgesehen....
Find ich auch
Libreoffice hab ich mir immer aktualisiert
bis jetzt immer über PPA... führt aber auch zu Problemen wie ich aktuell habe 
aber keine Lust/Zeit da Stundenlang nach eine Lösung zu suchen. Ich hoffe das erledigt sich damit 
Ergänzung: Damit wollte ich zum Ausdruck bringen NUR für Einzelpakete. Ich kann keinen Grund erkennen, warum man DEB ersetzen sollte.
Ja snap hoert sich echt gut an!
... Warum? Scheinbar bricht man mit der alten Regel "Keine statischen Abhängigkeiten in die Binaries linken". Okay - das kann man - wenn man Gründe hat - machen.
Aber warum ein neues Paketformat? Hätte man nicht ein eigenes Repository für genau diesen Fall einrichten können, welches Paketnamen mit einem Präfix beinhaltet, und dort Abhängigkeiten mitliefert?
Danke genau das gleiche hab ich auch gedacht!!! Snap bringt hoechstens was fuer Cloud-Server und da nehm ich dann lieber gleich etwas wie CoreOS oder OSv wo auch gleich das ganze BS und Applikation als ein Paket Versioniert ist.
Ich vermute der Nachteil von Snaps wird sein, dass die Snap Programme mehr Platz brauchen und nicht so schnell laufen wie die DEB Programme. Dürfte mehr etwas für den Privat oder kleineren Betrieb sein, wo die Nachteile unwichtig sind, als für so etwas wie Cloud oder mit Servern.
Snaps sind im Schnitt deutlich größer, ja. Warum die Anwendungen dann aber langsamer laufen sollen erschließt sich mir nicht.
In der "Cloud" und im Server-Umfeld ist es heute übrigens normal, dass man seine Anwendungen "Snappy-artig" zusammenpackt und ganze Instanzen automatisiert bespielt. Snappy geht da genau den Weg, den andere schon lange gehen.
Eine Minute schneller!!! Gibts doch nicht
Mit Ausfuehrgeschwindikeit hatte ein Paketformat noch nie was zu tun (von der Installation/Update mal abgesehen), Snap wurde fuer die Cloudversion von Ubuntu entwickelt damit ein Server Versioniert und im Falle von Fehlern wieder zurueck-Versioniert werden kann ohne andere Dienste zu beeintraechtigen, Speicherplatz fuer das BS ist heute einfach nicht mehr wichtig es interessiert nicht ob du 3 oder 5GB fuer das BS brauchst, updates ohne Risiko und ohne/minimaler Downtime das ist wichtig, siehe Docker/RK/OSv halt die ganzen "Applikation und BS sind ein Packet welches von A-Z Versioniert werden kann"-Ansaetze.
Ubuntus Anliegen sind es doch,
1. mehr Desktop/Mobile-Benutzer zu haben. Die wollen wiederum aktuelle Programmversionen. Der Benuzter will sich nicht damit auseinandersetzen, warum er jetzt LibreOffice extra über dpkg -i oder über ein PPA installieren muss. Und er versteht auch nicht, warum die neueste Version eben von einer recht neuen Bibliothek abhängt und deshalb nicht einfach so zu kompilieren ist. Er will eine 1-Click-Lösung. Wobei ich nicht unbedingt glaube, dass Canonical's Snap die beste Lösung ist wenn nicht wirklich die meisten beliebten Distri das auffangen. xdg-app von Gnome finde ich da eleganter.
2. für Entwickler letztlich eine Plattform zu schaffen, bei der sie mal eben in eine Datei reinschreiben: "Brauche Abhängikeiten foo in Version bar", wobei das Snap Paket dann selber wissen muss, ob das jetzt 16.04 oder 18.04 oder, und das wäre wohl besser, ob es Ubuntu, Debian, Suse... ist.Snaps sind dann eine elegante Lösung, weil sie eher wie Container aufgebaut sind, als debs. Das bringt bei potentiellem Risiko zumindest mehr Sicherheit (denn ich kann ja nicht wirklich wissen, ob ich der Software trauen kann und der Entwickler hat auch keine Zeit für so Sachen wie "reproducible builds", die sich dann auch auf allen Distri anderst gestalten werden wenn sie denn mal Standard werden.
Repositories haben den Nachteil, dass sie extrem von den ganzen dynamischen Bibliotheken im System abhängen (andererseits wollen wir aber auch nicht auf diese als stabile Basis verzichten, weshalb wir es als Grundsystem beibehalten).
Ubuntu kümmert sich nicht mehr um den Desktop und auch nicht mehr um die Mobilgeräte. Snappy unterstützt erst mal nur Mir, X11-Legacy-Apps laufen mittels XMir in einem abgeschotteten Container und bereits jetzt gibt es kaum Anstrengungen, die X11-Apps "ordentlich" und mit allen Features zu unterstützen. Gleichzeitig kümmert sich einfach niemand darum, Software auf Mir und das mit Snappy einhergehende Confinement-Modell zu portieren oder neu dafür zu entwickeln. Der App-Store für die Mobilgeräte ist ausgestorben, kein einziger kommerzieller Partner hat auch nur eine einzige Anwendung für das neue Modell herausgebracht.
Snappy Ubuntu Core sieht übrigens auch wieder Dependencies zwischen Snaps vor, da sonst z.B. jede Qt-Anwendung eine komplette Qt-Installation mitbringen muss - im Moment ist das so und die ersten einfachen GUI-Anwendungen sind installiert jeweils ca. 450 MB groß. Deswegen gibt es dann am Ende "Library Snaps", z.B. könnte man Qt 5.4 und Qt 5.5 parallel als Snaps installiert haben und Anwendungen könnten dann jeweils die für sie richtige Dependency drauf haben.
Am Ende ist Snappy einfach nur der Weg, wie Canonical endlich profitabel werden will. Statt einer vollständig freien Distribution, welche von Canonical gepflegt werden muss und jederzeit von anderen vollständig geforkt und erweitert werden kann, minimiert Canonical seinen Aufwand auf die Pflege eines winzigen Ubuntu-Root-Dateisystems, betreibt einen proprietären Store und lässt andere Leute die ganzen Snaps packagen. Canonical nimmt Geld für Dienstleistungen, den Betrieb des Store und so weiter. Die Snaps mit den Kerneln und Treibern kommen von irgendwelchen Hardware-Firmen, die Library Snaps kommen von den Entwicklern der ganzen Libraries und Toolkits, die Anwendungs-Snaps direkt von den Open-Source-Projekten und kommerziellen Anbietern. Es gibt keine Source-Snaps, nicht mal für Snaps welche Open-Source-Software beinhalten, und die Lizenzbedingungen des Store erlauben nur Canonical, hochgeladene Snaps an ihre Kunden weiterzuverteilen. Es ist also mit Snappy Ubuntu Core überhaupt nicht mehr möglich, Ubuntu zu forken. Canonical interessiert sich auch nicht dafür, wie die bisher existierenden "Flavors" (XUbuntu, KUbuntu etc.) mit Snappy klarkommen sollen - die Entwickler werden weder informiert noch unterstützt.
Dann dürfte Canonical ja bald Apple ablösen.
Ich sagte weder dass sie es gut machen, noch dass sie es aus software-ethischen Beweggründen machen, daher würde ich mit dir mitgehen.
Sie meinten aber, sie würden Snaps für 16.04 unterstützen, auch auf den Desktop Umgebungen.
Klar kann und soll es Abhängigkeiten zwischen den Snaps geben (Warum 10x wie bei Windows Qt oder libmp3irgendwas installieren?).
"Canonical interessiert sich auch nicht dafür, wie die bisher existierenden "Flavors" (XUbuntu, KUbuntu etc.) mit Snappy klarkommen sollen - die Entwickler werden weder informiert noch unterstützt."
Die sind genauso wie wir mit solchen Artikeln drüber informiert und sie verfolgen auch die Entwicklung der "Core" Komponenten. Snaps sind doch über CLI Tools zu managen, daher verstehe ich nicht, was du mit Unterstützung meinst? Keine der anderen offiziellen Flavours setzt doch andere CLI Programme, Paketmanager und dergleichen ein. Und als GUI kann jedes der Flavours das Gnome Sosftware Ding nehmen. Muon für Kubuntu oder das Lubuntu Software Center werden das bestimmt auch einbinden.
Snappy ist nicht nur ein Paketformat. Snappy funktioniert nicht wie APT über öffentliche Repositories, welche am Ende nur Verzeichnisse mit den richtigen, öffentlich zugänglichen Dateien sind und beliebig gemirrort, kopiert, modifiziert und auf dem Client beliebig gemischt werden können. Snappy kennt nur den Canonical Store, dessen Serverseite komplett proprietär ist. Es gibt keine Mirror mehr, und PPAs sind nicht vorgesehen. Canonical hostet alles und kontrolliert alles, kann man sich exakt so vorstellen wie den Google Play Store, nur ein kleines bisschen umfassender und ausgereifter.
Gleichzeitig ist es bei Snappy durch das Confinement so, dass die Veröffentlichung eines Snap-Paketes, welches "priviliegierte" Dinge tun möchte, eine privilegierte Operation darstellt. Beispiel: Kubuntu will die ganzen KDE-Libraries und KDE-Systemdienste (z.B. zum mounten von Datenträgern) in Form eines Library-Snaps ausliefern, damit alle anderen KDE-Anwendungen darauf aufsetzen können. Canonical erlaubt das nur, wenn es eine "Vertragsbeziehung" mit Canonical gibt und diese privilegierten Snaps zusammen mit Canonical entwickelt werden. Das wurde den Flavors weder so mitgeteilt noch werden sie involviert.
Canonical wird Ubuntu bald auf "All Snap" umstellen, die ganze Distribution basiert dann also vom Kernel bis zu den Anwendungen nur noch auf Snaps. Ein entsprechendes Image für eine virtuelle Maschine gibt es bereits, und ich glaube absolut nicht, dass Canonical die parallele Pflege der DEB-Variante auch nur ansatzweise so lange durchziehen wird, wie man den Leuten derzeit erzählt. Das sieht man alleine schon daran, dass quasi alle Mitarbeiter nur noch auf die Snappy-Welt hinarbeiten. Deswegen schleift ja die Weiterentwicklung der Mobilgeräte so vor sich hin, die ganzen Leute wurden abgezogen und arbeiten an Snappy.
In dieser schönen neuen Snappy-Welt gibt es derzeit kein Kubuntu, kein Xubuntu, kein Ubuntu MATE. Und Canonical tut auch absolut nichts dafür, dass es in der schönen neuen Welt überhaupt noch offizielle Flavors gibt.
" Snappy kennt nur den Canonical Store, dessen Serverseite komplett proprietär ist. Es gibt keine Mirror mehr, und PPAs sind nicht vorgesehen. Canonical hostet alles und kontrolliert alles, kann man sich exakt so vorstellen wie den Google Play Store"
So sehr ich auch gerne glauben möchte, das Canonical so was zuzutrauen ist, frage ich dich der Vollständigkeit halber nach deiner Quelle.
Jedenfalls was die Erstellung von snaps angeht, gibt es da auch andere Wege:
https://github.com/mikix/deb2snap
http://askubuntu.com/a/661658
Man kann Snaps natürlich lokal mit irgendwelchen Tools erstellen, und man kann sie auch lokal mit irgendwelchen Tools manuell installieren. Das ist bei Android auch so. Aber das Client-Tool, welches "apt" oder "apt-get" entspricht und für den Endnutzer danach den ganzen Kern der Sache darstellt, sieht als Online-Quelle für Snaps nur den Canonical-Store vor, und der versteckt alle Daten hinter einer API. Das ist nicht mehr wie bei APT, es gibt keine sources.list-Datei welche einfach vom Nutzer geändert werden kann und aus welcher sich APT die Download-Pfade für seine Metadaten und die Pakete zusammenbaut. Alles ist hartcodiert (siehe https://github.com/ubuntu-core/snappy/blob/master/store/snap_remote_repo.go) und es ist nicht vorgesehen, dass jemand noch weitere Stores neben Canonical betreibt. Dafür müsste man derzeit wohl die ganze Serverseite reverse-engineeren und den Snappy-Client patchen.
Man könnte übrigens auch gar keine Kopie aller Inhalte des Canonical-Stores ziehen und die Snaps selbst anbieten, so wie man das ja macht wenn man Ubuntu bislang geforkt hat, denn wer in den Canonical Store hochlädt oder diesen nutzt, akzeptiert https://myapps.developer.ubuntu.com/dev/tos/ . Demnach erteilt derjenige, der ein Snap in den Store hochlädt, ausschließlich Canonical das Recht, dieses Snap mit Hilfe eines von Canonical zur Verfügung gestellten Clients an seine Kunden weiterzuverbreiten. Man müsste also jeden einzelnen Autor fragen, ob er erlaubt, dass sein Snap auch in alternativen Stores angeboten wird. Snaps selbst aus den Sourcen bauen geht auch nicht so einfach, im Gegensatz zur DEB-Variante kennt Snappy überhaupt keine Source-Pakete. Im Prinzip erlaubt es diese Lizenz nicht mal, ein von Canonical nicht offiziell abgesegnetes Derivat zu betreiben, denn dieses Derivat hat erst mal kein Recht, den Store als Paketquelle zu nutzen.
Das ist seit Monaten so bekannt, es will sich aber wohl niemand offiziell dazu äußern. Käme ja auch schlecht an, wenn man zugeben müsste, dass es solche Forks wie Linux Mint dank Snappy dann eigentlich nicht mehr geben kann. Natürlich wird sich Canonical erst mal davor hüten, diese Regeln strikt auszulegen, aber das ganze Design von Snappy und vor allem die neuen Lizenzen sprechen eine mehr als deutliche Sprache, insbesondere dann, wenn man mal bedenkt, an welche Rechte und Möglichkeiten Nutzer und Entwickler durch die Debian-Herkunft eigentlich gewöhnt sind.
Nicht nur Debiannutzer. Kein Fedora-, Mandriva- oder Fedoranutzer würde sich so einen kapitalen Stuss gefallen lassen oder sogar dafür programmieren.
Auch für kostenlos herunterladbare Snaps, die freie GPL-Software sind, müssen die Quellen zur Verfügung gestellt werden. Jetzt schreibst Du, dass Snappy gar keine Source-Pakete kennen würde. Wird dann im Canonical Snaps-Store grundsätzlich gar keine GPL-Software angeboten?
Canonical verhält sich in Lizenzfragen immer merkwürdiger. So kann sich Shuttleworth offensichtlich gar nicht vorstellen, dass Oracle sein Canonical wegen einer ZFS-Lizenzverletzung in Ubuntu 16.04 verklagen wird. Die Klage wird bestimmt dann kommen, wenn Ubuntu 16.04 bereits eine gewisse Verbreitung erreicht hat, damit sich das auch lohnt. Fragt man Oracle deswegen an, lautet die Antwort für Linuxnutzer immer: Benutzen Sie Btrfs bei Linux-Lizenzproblemen. Das eigene Oracle Unbreakable Linux darf deshalb kein ZFS anbieten und das, obwohl das von Oracle gekaufte Sun ZFS für Solaris 10 selbst entwickelt hatte (!).
Und nun glaubt Canonical, sich das herausnehmen zu können, was sich Oracle selbst nicht erlauben darf.
Der Canonical-Store enthält natürlich auch jetzt schon freie Software. Im Gegensatz zum bisherigen (Debian-)Modell wird der Sourcecode aber nicht jedes Mal parallel mit in den Store hochgeladen, sondern Canonical wälzt die rechtlichen Konsequenzen auf den Uploader ab, so wie es Google und Apple auch tun. Der Uploader muss die Sourcen irgendwo hinterlegen, im Optimalfall bietet das Projekt selbst die notwendigen Snappy-Metadaten an, man checkt die Sourcen aus und erhält mit "snapcraft snap" das Paket. Dass dabei kein Source-Snap abfällt, zeigt z.B. das Bild hier.
Das zieht auch noch alle möglichen anderen Probleme nach sich, z.B. kann man nebenbei auch nicht mehr nachvollziehen, ob und wie das Paket im Store aus den offiziellen Sourcen entstanden ist, da der Uploader das Snap-Paket lokal bei sich auf dem Rechner baut und weder den Stand des Sourcecodes, welchen er verwendet hat, noch den "Bauplan" für das Snap hochladen muss. Wer also Zweifel hat, kann nicht mehr einfach wie früher das Source-Paket herunterladen, kontrollieren und lokal selbst noch mal neu bauen.
" und lässt andere Leute die ganzen Snaps packagen. "
Angesichts dessen, was Du da gerade zur letztendlich proprietären Natur von Snaps geschrieben hast, wird genau das IMO nicht passieren. Es wird so gut wie niemand aus der Entwicklercommunity irgendwelche Snaps packagen. Wer entwickelt ohne explizites Eigeninteresse schon kostenlos für einen Millionär mit derartigen versteckten Sezessionsallüren?
Und die Nutzer, die wahrscheinlich dann gerne so ziemlich jede Software als Snap hätten, können meistens genau das nicht: Pakete bauen.
Mein Vorschlag: U.a. Kubuntu, Xubuntu, Lubuntu, Ubuntu Mate, Ubuntu Gnome, Ubuntustudio und Linux Mint sollten sich zusammensetzen und ein neues, wirklich selbständiges Ubuntu ins Leben rufen und ganz formell Canonicals Schoß verlassen.
"Mein Vorschlag: U.a. Kubuntu, Xubuntu, Lubuntu, Ubuntu Mate, Ubuntu Gnome, Ubuntustudio und Linux Mint sollten sich zusammensetzen und ein neues, wirklich selbständiges Ubuntu ins Leben rufen und ganz formell Canonicals Schoß verlassen."
Klingt gut. Nur: Wenn sie so weit sind, können sie vielleicht auch gleich from Scratch bauen, um die ganzen Altlasten wie apt-get loszuwerden.
Das geht natürlich nur, wenn sie einsichtig sind.
Darüber hinaus halte ich es für sinnvoll, wenn sich alle einen "Server Stack" zusammenbauen, mit dem sie leben können:
Und dann, auf ihren jeweilige eigenen Repos alles von X11 und Wayland selbst wegbauen.
So sparen sie sich Arbeit und können immer noch für ihre DEs selbstständig entscheiden.
Auch jetzt profitieren die einzelnen Spins doch einfach vom Namen, ein Großteil der Pakete und Infrastruktor kommt sowieso schon längst von Debian beziehungsweise eigenen Quellen.
Gerade Mint hat den jedoch nicht nötig, wie wir sehen. Ich persönlich sehe auch die Basis einer bestehenden Distribution wie KaOS als hilfreich, weil gerade da vorgezeigt wird, wie es funktionieren kann, sich auf eine DE zu konzentrieren: Kubuntu könnte sogar gleich den gesamten Stack adaptieren, was ihnen die Entscheidung sinngemäß erleichtert.
Sie wollen alle nicht für sich genommen von Canonical weg, in Summe sind sie stark genug.
Ich begrüsse deine Idee also und wenn du dies auch willst, können wir ja gemeinsam ein derartiges Konzept entwerfen und den jeweiligen Distributionen dann vorlegen.
Was hälst du davon?
Das ist viel zu bürokratisch, zumal es sich um kleine und sehr kleine Teams handelt. Die Mailinglisten und üblichen Ubuntuforen bieten da viel bessere Möglichkeiten.
Die Hauptvoraussetzung fehlt zudem noch: Ubuntu muss das alte deb-apt-System tatsächlich zugunsten von Snap vernachlässigen und so die Ubuntu-Varianten z.B. ab Ubuntu 18.04 automatisch gegen die dann vielleicht nicht mehr supportete deb-apt-Wand fahren lassen. Zur Zeit fehlt dieser Druck zur Entscheidung zwischen dem klassischen deb-apt und dem neuen snapd völlig.
"Das ist viel zu bürokratisch, zumal es sich um kleine und sehr kleine Teams handelt. Die Mailinglisten und üblichen Ubuntuforen bieten da viel bessere Möglichkeiten."
Auf welchen Satz beziehst du dich hier?
"Die Hauptvoraussetzung fehlt zudem noch: Ubuntu muss das alte deb-apt-System tatsächlich zugunsten von Snap vernachlässigen und so die Ubuntu-Varianten z.B. ab Ubuntu 18.04 automatisch gegen die dann vielleicht nicht mehr supportete deb-apt-Wand fahren lassen. Zur Zeit fehlt dieser Druck zur Entscheidung zwischen dem klassischen deb-apt und dem neuen snapd völlig."
Intelligente Entwickler erkennen, bevor ein System gegen die Wand fährt. Und willst du stumpfsinnige Entwickler in einem Projekt?
Die Situation gibts ja schon bei den Mobilgeräten. Quasi niemand hat irgendwelche Software auf Mir und Confinement portiert, 90% der Apps im Store sind Webapps, und die kann man halt auch mehr oder weniger automatisiert generieren lassen. Kommerzielle Drittanbieter haben keine einzige App für die Mobilgeräte herausgebracht, und das ist ja die "Zielgruppe", um die es bei Snappy vorrangig zu gehen scheint. Im Snappy Store stehen derzeit erst so ungefähr 40 Pakete, obwohl Canonical ja eigentlich schon vergleichsweise viele Partner aus dem Embedded-Bereich vorweisen kann. Keine Ahnung, ob die alle noch abwarten, oder ob es da bereits "geheime" Abteilungen im Store gibt und man die Packages deswegen einfach nicht sieht. "Sub-Stores" sind ja angeblich explizit vorgesehen, z.B. könnte Dell seinen Kunden dann Apps zum Download anbieten, welche die Nutzer anderer Geräte nicht sehen.
Die eigentliche Frage zu anfangs wird ja für Desktopnutzer wohl eher folgender Natur sein, nämlich, ob man die nächste KDE- oder Xfce-Version, die irgendwann einmal nach dem 16.04-Release herauskommen und in einem späteren Kubuntu oder Xubuntu enthalten sein wird, bei Kubuntu oder Xubuntu für eine dann ältere Version wie 16.04 als Snap-Paket zum Nachinstallieren herausbringt oder nicht.
Ich glaube im Moment ist die eigentliche Frage, wie sich Canonical das mit Mir, Wayland und X11 vorstellt. Damals wurde ja behauptet, die Flavors könnten weiterhin X.Org oder auch Wayland nehmen und müssten sich nicht für Mir entscheiden. Jetzt ist es aber so, dass Canonical Snappy einzig und allein um Mir herum aufbaut und nicht mal X11-Kompatibilität besteht, geschweige denn Wayland vorgesehen ist. Das Convergence-Tablet machts vor: Alle X11-Anwendungen laufen dort in einem "Legacy"-Container, in welchem ein DEB-basiertes Ubuntu installiert ist. XMir vermittelt dann zwischen Container und Hauptsystem. So wies aktuell aussieht, kann man also weder irgendwelche anderen Desktops noch X11-Anwendungen als Snap packagen, solange die Entwickler sich nicht nach Canonical richten und komplett auf den Zug aufspringen.
Eine gewagte Strategie, wenn man sich anschaut, wie stark andere Desktop-Distributionen mittlerweile aufgeholt haben. Selbst Debian hat nachgezogen, mittlerweile liegt der Vorteil von Ubuntu 16.04 gegenüber Debian 8 für mich hauptsächlich in ein paar vorinstallierten Firmware-Dateien, einer aktuelleren X.Org-Version und der Integration des proprietären NVIDIA-Treibers. Auf der anderen Seite hat Ubuntu so einiges schleifen lassen, ich laufe immer wieder in kleinere Details, welche unter Ubuntu 16.04 nicht richtig laufen, aber unter Debian 8 schon. Das fängt bei der Tastaturbelegung beim Booten an (Ubuntu steht während der Eingabe des Verschlüsselungspassworts für die Festplatte immer auf Englisch statt Deutsch...) und geht zu so Dingen wie "Die GNOME Wayland Sitzung tut unter Debian einfach problemlos, unter Ubuntu startet sie gar nicht". Ubuntu 16.04 wirkt auf mich deutlich weniger abgerundet als die vergangenen LTS-Versionen.
Jeweils 450 MB, kann ich mir kaum vorstellen... Wenn ich eine Android App mit Qt erstelle, ist die zwar auch größer (so um die 50 MB), aber keine 450+ MB.
Auch die DLLs von Windows Qt Anwendungen sind nicht so groß...
Also bitte nicht übertreiben.
Folgende drei Qt-Anwendungen sind derzeit im Snappy-Store zu finden:
ubuntu-calculator-app 2.1+snap2
Download size: 151.25 MB
ubuntu-clock-app 3.6+snap2
Download size: 151.41 MB
ubuntu-clock-app-mvo 3.6+snap3
Download size: 126.05 MB
Allein die Snaps sind schon über 100 MB groß, komprimiert. Installiert siehts dann z.B. so aus:
ubuntu@localhost:/snaps$ du -sh ubuntu-calculator-app.ubuntucoredev/
467M
Dem Inhalt des Paketes nach besteht da noch dramatischer Optimierungsbedarf, siehe die Dateiliste unter http://paste.ubuntu.com/15883169/ .
Habe mir gerade mal angeschaut, wie groß der Download des Tiled Map Editors ist: https://thorbjorn.itch.io/tiled
Windows 64bit etwa 22 MB
Mac OSX: 17 MB
Sowohl beim Windows als auch Mac Paket ist Qt enthalten.
Für Linux gibts halt nur den Sourcecode oder Pakete, die die jeweilige Qt Version des Systems verwendet.
Da läuft halt etwas verdammt schief, wenn die Pakete so groß sind, an Qt liegt das sicher nicht...
Habe jetzt im Programmverzeichnis mal nachgesehen. Die Qt dlls haben insgesamt eine Größe von 17,2 MB, also entpackt. Weit weg von mehreren hundert MB, wie es hier gesagt wurde.
Die Entwicklungsversionen benötigen einiges mehr an Speicherplatz, da braucht man ja auch Header Dateien und evtl. den Source Code und das braucht alles mehr Speicherplatz.
Snap ist für mich als Endanwender völlig aussen vor. Für mich ist DEB/Synaptic das Maß der Dinge.
Was mich stutzig macht, ist das die Redmonter auch so ihre Eier im Kochtopf haben.
Frage: Snap von Cannonical als langfristig geplante BS-übergreifendes Format ?
Mal abwarten, was da noch kommt.
http://www.computerbase.de/2016-04/windows-subsystem-for-linux-linux-desktop-apps-unter-windows-10-starten/
Also wenn es so ist, wie snappy beim Raspberry PI angeboten wird, dann können wir es vergessen.
Nicht mal das simple Testprogramm auf deren Seite bekommt man ans lauifen, also habe ich alles sofort wieder gelöscht.
Wie so häufig, alles nur Gerede. Dann ist diese Version veraltet und jene nicht geeignet.
KW