So, dann sind ja doch mal einige so früh am Morgen, haben es doch noch mal hier hingeschafft. So, ich habe leider keinen Presenter, deshalb kann ich keinen Laserpointer nutzen, ein bisschen blöd.

Ja, erstmal, ich meine, es geht jetzt hier um Snappy Ubuntu Core auch. Was das jetzt genau ist, werde ich jetzt natürlich erklären, hat damit schon mal irgendwer gearbeitet.

Gut, dann erstmal kurz zu mir. Mein Name steht da, ich heiße Sujiban. Damit extra noch mein Lautschrift, damit ihr es auch noch lesen könnt. Ansonsten bin ich auch eher dessen Name nie genannt wird.

Kurz zum Inhaltsverzeichnis, also was jetzt ihr genau alles hören werdet. Zunächst einmal die Einordnung, was denn genau Snappy Ubuntu ist. Wo jetzt der Unterschied ist zwischen dem klassischen zu den normalen Ubuntu, was ihr jetzt vom Desktop oder auch vom Server halt eben kennt.

Dann eben der genaue Blick auf, was ist genau Ubuntu Core. Dann noch eine kurze Demo und dem Anschluss ist dann auch schon zu Ende.

So, kurz zu mir. Ich komme aus der Stadt Castro-Brauchse bei Dortmund, falls das irgendwer kennt.

Bin im normalen Leben Software-Entwickler und bald wieder Student. Bin selbst jahrelang in der Ubuntu-Community unterwegs. Zum Beispiel auf Messen, an Ständen oder auch bei Ubuntu-Users im Team. Teilweise einfach nur als Artikelschreiber, teilweise eine Zeit lang auch als Projektleitung.

So was sich so alles immer ergibt. Mittlerweile mache ich das auch schon fünf Jahre lang. Also das ergibt schon mittlerweile eine ganz schön lange Zeit. Ja, was ich noch hervorheben muss. Ich bin kein Canonical-Mitarbeiter, auch wenn ich da ein paar Leute damit kenne. Und ich bin auch Organisator der diesjährigen Ubucon, die in Berlin stattfinden wird.

Dazu hier nochmal was, nur als kleine Werbung. Am 23. bis zum 25. Oktober findet die Ubucon in Berlin statt. Und da könnt ihr natürlich auch gerne erscheinen. Der Call for Papers läuft auch noch. Ein fertiges Programm haben wir bis jetzt noch nicht.

Und wer sich frühzeitig anmelde, kommt da für 15 Euro teilnehmen. Wo dann auch eine Essensflatrate und Getränkeflatrate mit enthalten ist. Kommen wir jetzt aber mal wirklich zum Thema. Nämlich zunächst erstmal zum traditionellen Ubuntu. Damit wir eben einordnen können, wo sich jetzt genau Snappy Ubuntu vom normalen Ubuntu unterscheidet.

Das traditionelle Ubuntu nutzt, wie ihr wahrscheinlich schon alle kennt, Abt bzw. DPGAG zur Paketverwaltung. Ihr könnt da alle eure Anwendungen und Programme oder Liveways installieren. Und folgt eben dem Zyklus, dass es alle sechs Monate eine neue Version rauskommt.

Die dann für neun Monate unterstützt wird. Und es gibt dann eben noch die LTS-Variante, die eben für fünf Jahre unterstützt wird. Und alle zwei Jahre erscheint. Was hierbei wichtig ist, um den Unterschied zu Snappy zu erkennen,

ist, dass die Paketversionen ja soweit fest sind. Zumal größtenteils, wenn man jetzt irgendwie einen Apache installiert, dann ist es halt eben Apache 2.4. Und das bleibt auch während der ganzen Release-Unterstützung so. Das wird in der Regel ja eben nicht geupdated. Von Firefox oder so was abgesehen, was da häufiger aktualisiert wird.

Sodass die Pakete alle nur Sicherheitsaktualisierung oder Fehlerkorrekturen bekommen. Aber keine großartigen neuen Features dazubekommen, während eines Releases.

Normaler Einsatz im Moment, eigentlich nur Desktop und Server. Und wie ihr vielleicht schon mitgekriegt habt, gibt es auch noch Ubuntu Phone. Dazu gibt es um 11 noch mal einen Vortrag, ebenfalls von mir und hier. Der Unterschied bei Ubuntu Phone ist, dass das ganze System ein System-Image ist. Das heißt, das ganze System wird an sich geupdatet, als Image basiert.

Das heißt, es wird halt immer ein Image geladen, was dann halt rüber gebügelt wird auf das System, um dann das ganze System zu aktualisieren. Auf die Details gehe ich jetzt hier nicht so genau ein. Dafür gibt es den Vortrag halt eben gleich. Was mir jetzt halt noch wichtig ist, man kann keine Dapp-Pakete,

beziehungsweise zumindest im Standard keine Dapp-Pakete installieren. Dafür gibt es bei Ubuntu Phone zum Beispiel Click-Packages. Das ist halt ein viel einfacheres Paket-Tool,

sodass es viel einfacher ist, ein Paket von Ubuntu Phone zu basteln. Dafür gibt es auch noch Frameworks und SDKs, um Anwendungen dafür zu entwickeln. In der Regel erscheint im Release-Zeitraum alle sechs Wochen eine neue Version.

In diesen System-Image-Updates gibt es dann auch das Update vom Basissystem von z.B. 14.04 auf 15.04. Das ist in ein paar Minuten erledigt, dadurch, dass es einfach nur überschrieben wird. Was wichtig zu wissen ist, dass Ubuntu Phone letztendlich die Vorgängerversion von Snappy Ubuntu war.

Snappy Ubuntu ist eben auch ein System-Image. Das hat noch einen besonderen Feature, dass es transaktionale Updates gibt. Das heißt, man kann jetzt ein Update vom System machen oder auch von Anwendungen. Falls da irgendetwas nicht funktioniert, wenn es z.B. nicht bootet, oder wenn Anwendungen nicht so funktionieren, wie es eigentlich funktionieren sollte,

dann kann man die wieder rückgängig machen und auf eine alte Version springen. Wie das genau funktioniert, zeige ich auch noch später. Dadurch, dass es die Weiterentwicklung von den Click-Packages sind, sind das hier Snap-Packages. Wie das aufgebaut ist, kommt auch noch mal gleich. Und wo Snappy im Moment vor allem eingesetzt wird,

ist der Einsatzbereich von dem Internet of Things. Also für Dinge, die es an vielen Ecken geben wird, sollen Kühlschränke, Router, Switches und Drohnen usw. dazu gleich nochmal mehr. Und man kann sich auch eine Cloud-Instance z.B. bei Amazon,

oder bei Microsoft Azure starten, oder auch lokal als KVM Image, so wie ich das z.B. mache. Kommen wir jetzt mal wirklich zu Ubuntu Core. Ich hatte gerade schon mal kurz erwähnt, dass es verschiedene Devices gibt. Also welche Geräte gibt es denn jetzt, wo läuft das denn jetzt genau? Man kann sich schon ein paar Geräte kaufen, wo Snappy Ubuntu drauf ist.

Das ist z.B. ganz links. Und das dritte z.B. sind beides Drohnen, bzw. eine so eine Spider-Drohne von dem Hersteller Earl Robotics. Da ist ein Beagle-Bone-Black letztendlich drauf, was halt als hauptsächlich Entwicklungsplattform dient,

und wo man miteinander seine Anwendungen installieren kann. Das heißt, wenn man jetzt eine Drohne hat, dann kann man da ein Programm installieren, um die anders zu steuern oder so was. Wer sich jetzt denkt, oh, ich kaufe mal eben so eine tolle Drohne, das hatte ich mir auch mal kurz überlegt. Ja, die fangen so bei 500, 600 Euro an.

Ist also nicht ganz so billig. Ja, wie man auf dem zweiten Bild sieht, lauffähig ist das hauptsächlich auf dem Beagle-Bone-Black. Also als unterstützte Version, wofür es auch eben diese transaxonalen Updates gibt. Auf dem Westpower-EPI gibt es auch noch Builds, das wird aber noch nicht, zumindest im Moment nicht, offiziell unterstützt. Da weiß man jetzt noch nicht, wann das jetzt alles weiter geht.

Und was man mittlerweile auch kaufen kann, sind Switches, wo Ubuntu Core halt eben draufläuft. Da gibt es diverse Hersteller, die es schon angekündigt haben. Jetzt gibt es auch noch eben Kühlschränke, wie man da noch so leicht sieht,

was dann halt so ein Smart-Switch ist. Letztendlich kommt es immer darauf an, wer es braucht. Ist halt auch wieder relativ teuer im Vergleich zu einem normalen Kühlschrank. Wenn man da jetzt zum Beispiel sieht, da ist es ein bisschen schwer zu erkennen, dass da zum Beispiel so eine Milchwaage drin ist, mit einer Milchflasche drin. Und der Kühlschrank weiß dann, wenn es zu leicht ist, dann ist da nichts mehr drin.

Also kann man den Besitzer Bescheid sagen, als Push-Benachtigung aufs Handy, zum Beispiel, hey, du brauchst uns mal neue Milch kaufen, du willst das nicht mehr kaufen. Lustig wäre es natürlich, wenn es die Drohne liefern würde. Soweit sind wir aber glaube ich noch nicht.

Aber letztendlich ist es jetzt schon möglich, dass man sowas macht. Was wichtig ist zu verstehen, ist, dass Ubuntu Core letztendlich nur die Plattform ist, um solche Anwendungen zu implementieren und zu nutzen. Zum Beispiel bei dem Kühlschrank gibt es letztendlich nur eine iPhone-App, um der Benachtigung sowas zu kriegen, sodass man nicht direkt sieht,

also als normaler Endanwender für Internet-of-Things-Geräten soll man halt nicht sehen. Da wird man nicht so direkt sehen, ob da jetzt Ubuntu Core drauf läuft oder nicht, außer wenn man jetzt dafür entwickelt. Das ist zum Beispiel auch so der Fall, dass wenn ihr zum Beispiel zu Hause habt, ihr wahrscheinlich alle einen Router, und ihr wisst aber nicht,

was so ein System da direkt draufläuft, außer wenn da jetzt irgendwer ist, der sich da selbst was dran gebastelt hat. Wofür Ubuntu Core eben dafür da ist, ist eben, dass man das drauf installiert und der Hersteller muss sich jetzt nicht mehr so großartig darum kümmern, dass die Plattform noch aktualisiert wird. Weil wer weiß, wie oft sein Router aktualisiert wurde?

Einer, immerhin. Gut, mit Ubuntu Core sieht man das auch eher auch nicht, weil das Ganze im Hintergrund läuft. Der Punkt ist aber halt mehr so, dass vorher jeder sein eigenes Süppchen gebacken hat und eben hierdurch viel Arbeit auch für den Hersteller abgenommen wird.

Wenn man jetzt zum Beispiel ein Ubuntu 15.04 auf dem Router hat, dann pollt er halt jedes Mal, hey, habe ich Updates, habe ich Updates? Und wenn ein Update da ist, dann wird es installiert. Wenn da was schief geht, dann twitcht er wieder um. Und dann bootet die alte Version wieder, sodass man es in der Regel nicht merken sollte. Genau, Cloud Insistence habe ich auch schon erwähnt.

Ansonsten, hierzu erst mal noch Fragen. Kommen wir zur Architektur von Ubuntu Core letztendlich. Wie Core schon im Namen sagt, es ist wirklich der Kern. Also da ist wirklich nicht so viel drin. Letztendlich gibt es vier verschiedene Schichten,

wobei die dritte eigentlich relativ, also Frameworks sind zum Beispiel optional. Kommen wir also erst mal zur Unterstützenschicht. Das ist das Enablement. Das ist eigentlich nichts anderes, als die kernel-Unterstützung von einem Gerät, das man unterstützen wird. Zum Beispiel auf dem Beaglebone Black oder auf dem Raspberry Pi oder ein Odroid-Gerät, z.B. Armgeräte oder X86, 64 oder irgendwie sowas.

Letztendlich ist da der Linux-Kernel drin, die ganzen Treiber, die dafür benutzt werden, um das zum Laufen zu kriegen. Und was wichtig ist, sweet only. Heißt, man kann da jetzt nicht so viel drauf schreiben im Standard.

Die zweite Ebene ist Ubuntu Core. Da sind dann letztendlich alle bekannten Sachen, die von Ubuntu dabei sind, außer jetzt UpGit oder dpga-g drauf, die dann eben den Kern bilden. Da sind jetzt nicht viele Anwendungen installiert.

Es geht wirklich nur darum, das Basissystem zu liefern. Das heißt, zum Beispiel so Sachen wie Python ist zwar im Moment noch drin, fliegt aber auch noch raus. Das Ganze soll dann halt so modular wie möglich gehalten werden, sodass eben auf den ganz kleinen Geräten installiert werden kann, um eben nicht so viel Ballast zu haben.

Bzw. den Ballast kann man dann über die Frameworks bzw. die Apps erzeugen. Was hier auch wichtig ist, sweet only. Man kann jetzt nicht im Standard, klar, wenn man jetzt als Entwickler ist, kann man da was rumschreiben, aber als ausgeliefertes Gerät

schreibt man da eher nicht so rum auf irgendwelchen Dateien. Das Ganze wird auf der übrigen Ebene gemacht. Und wie auch beim Ubuntu vorhin oder gerade schon erwähnt, ist das Ganze imagebasiert und transaktionaler Updates. Ich glaube, dazu kommt gleich noch ein bisschen mehr.

Kommen wir jetzt zu Frameworks und zu den Vor- und Nachteilen von Snappy im Vergleich zu einem normalen Ubuntu. Wenn man jetzt ein Framework hat, dann ist das so Sachen, die geben dann Informationen da, die häufiger genutzt werden,

als Art Bibliotheken, es muss aber nicht. Was jetzt z.B. in Ubuntu Core bald kein Python mehr drinne, sodass man als Framework Python anbieten kann. Das Ganze wird aber nur durch, also um Frameworks anbieten zu können über den Store, muss man letztendlich ein Vertragsverhältnis mit Canonical haben. Man kann also nicht so mal einfach ein Framework erstellen.

Das Ganze hat natürlich Vorteile, wenn man ein Framework hat. Das heißt, theoretisch wäre es möglich, wenn das jemand programmiert, z.B. eine Android-Laufzeitumgebung als Framework zu implementieren, sodass dann verschiedene Apps diese Laufzeitumgebung nutzen können. Es können mehrere Frameworks gleichzeitig installiert sein. Das Ganze dient einfach nur dazu, mehreren Apps eine Plattform zu bieten,

worin sie dann halt undocken können oder was nutzen können. Und genau wie es da auch noch steht, Sachen wie Sensoren oder Kameras dafür, um da eine bessere API zu liefern oder sowas, dafür kann man Frameworks verwenden.

Kommen wir jetzt zur vierten, also Frameworks waren letztendlich noch optional. Apps sind natürlich auch optional. Es bringt dann halt nicht mehr viel, wenn man keine Apps drauf hat. Apps werden als Snap-Packages ausgeliefert, nicht als Dapp-Pakete. Und die beinhalten letztendlich alles, was man braucht,

mit allen Abhängigkeiten, die man braucht. Das heißt, wenn man jetzt z.B. ein, also ihr kennt das wahrscheinlich alle, wenn ihr ein Programm installiert, dann installiert er sich ja noch ganz viele ganz abhängige Abhängigkeiten mit runter. Und so, dass man wirklich eine Bibliothek nur wirklich nur einmal auf der Platte liegen hat.

Das ist bei Snap-Packages nicht mehr so. Das geht, viele sagen, es erinnert einen stark an das Windows-System, wo auch jede Anwendung ihre eigene Bibliothek mitliefert. Wenn man jetzt als Beispiel sagt, ja, ich habe jetzt hier eine C++-Anwendung, ich brauche die Boost-Libis, die ein paar Gigabyte groß sein könnten, wenn man da jetzt mehr nutzt.

Dann linkt man ja jetzt eben als Anwendungsentwickler immer gegen die Versionen, die in den Paketquellen vorhanden sind. Wenn man mehrere Distributionen unterstützt mit, die alle verschiedene Bibliotheksversionen haben, dann ist es als Anwender immer relativ schwierig, je nachdem, ob da API, ob die API da irgendwie inkompatibel ist.

Das kann ich jetzt nur aus meiner Entwicklersicht quasi sagen. Es ist manchmal schon nervig, wenn man jetzt für Ubuntu 14.04 oder Features nutzen will, die dann irgendwie nur neueren Distributionen vorhanden sind, aber in so einem Red Hat 6 zum Beispiel gar nicht mehr enthalten sind. Das ist dann natürlich blöd, weil dann muss man halt immer gucken,

ja gut, kann ich noch nicht nutzen, kann ich erst in drei Jahren nutzen. Und dieser Punkt ist jetzt halt eben bei Snap-Packages nicht mehr der Fall. Mit dem Vorteil für die Entwickler, dass man eben alles mit drin hat. Die Snap-Pakete selbst sind doch deutlich einfacher aufgebaut als normale Adapt-Pakete.

Und das erleichtert zumindest aus der Entwicklersicht die Sache. Aus dem Nachteil ist dann natürlich, dass sich vieles doppelt. Dann hat man halt von einem Library theoretisch drei, vier, wenn man irgendwie zehn Anwendungen installiert hat, und jeder bringt ihre eigenen Libraries mit, dann wird das natürlich relativ schnell, relativ fett.

Wobei man auch wiederum bedenken muss auf der Schiene von den Internet of Things-Dingen, wo man halt, hat man eh nicht viel installiert. Da schadet das jetzt nicht großartig, ob man jetzt da, da man eben nur eine oder zwei Anwendungen installiert hat, ob man da jetzt eine Bibliothek mehr oder weniger hat. Das Ganze versucht man noch damit auszugleichen, also dass man nicht so viel Platz verbraucht durch D-Duplication.

Und das sieht dann halt eben so aus, dass wenn das System beim Installieren eines Paketes merkt, hey, ich habe die Bibliothek XY in einer bestimmten Version schon da, dann muss ich die nicht nochmal extra runterladen. Das Ganze geht natürlich nur dann, wenn es auch wirklich dieselbe Bibliothek ist

und jetzt nicht irgendwie eine, und nicht eine andere Version ist, weil dann klappt das Ganze schon nicht mehr. So, hierzu irgendwelche Fragen bis jetzt?

Nochmal. Genau.

Genau, ja. Ach so, ja. Also die Frage war jetzt, ob man jetzt System, ja genau, System-Utilities, ob man die schreiben kann. Man kann das, glaube ich, dann als Framework dann eben implementieren,

wenn man die Geräte dann, aber man muss halt so ein Vertragsverhältnis zu Canonical haben, um die eben storen zu bieten. Man kann sie natürlich auch selbst auf seinen Geräten installieren. Ansonsten, ja, ich glaube, das beantwortet eine Frage, ne?

Ja? Also die erste Frage war eben, wo sich das gegenüber CoreOS oder anderen Container-Basierten absetzt.

Das kann ich gar nicht so genau beantworten, weil ich CoreOS wahrscheinlich gar nicht so gut kenne. Aber es geht halt in dieselbe Richtung. Wobei bei CoreOS ist, glaube ich, fast nur der einzige Einsatz, dass man dann Docker oder Rocket dann eben installiert, glaube ich. Hier hat man halt eben, hier kann man auch Docker installieren

und dann Container eben bauen und nicht nur, und halt normale Anwendungen in Snap-Packages. Was halt auch noch wichtig ist zu verstehen, ist bei Frameworks und bei Apps, die sind halt so Geschichte, dass sie noch, dass sie gesandboxed sind, sodass sie nicht im Standard alle Dienste nutzen können, wie es jetzt zum Beispiel der Fall ist. Also, dass man halt eben Netzwerkzugriff muss,

sondern mit Appamor zum Beispiel angeben, ob man jetzt, ob er jetzt Internetzugriff haben darf oder nicht. So, die zweite Frage war? Ja, also für den Stream nochmal die Wiederholung, ob das, ob die De-Duplication-Block oder Datei passiert ist.

Soweit ich weiß, ist die De-Duplication noch gar nicht implementiert. Die ist also geplant und da kann ich auch nichts zu sagen. Also ich erwickele da selbst nicht mit. Bis jetzt habe ich auch noch nichts mit Snapibuntu selbst programmiert oder sowas. So, noch welche Fragen?

Ja, also um jetzt die Frage zu wiederholen,

du hast eine Depp-Pakete und möchtest das als Snap-Paket anbieten, richtig? Ja, also du kannst ja eben hier keine Depp-Pakete installieren, aber das bleibt auch im Store. Das ist ja ein getrenntes Archiv.

Zum Store komme ich gleich nochmal dazu. Du kannst aber deine Anwendung als Depp-Paket mit einem Depp-to-Snap-Paket theoretisch auch automatisch umbauen lassen, sodass er dann halt, wenn man halt jetzt einen Temux oder sowas braucht, kann man dann halt Depp-to-Snap aufrufen, wenn man es installiert hat, um dann ein Paket, was man jetzt gerade hat, direkt als Snap-Paket auszuliefern.

Das geht also auch. Genau, ich habe ja gerade erwähnt, das ist ein transaktionales System. Und es ist ein transaktionales System, was dann eben auch zwischen vor dem Update und nach dem Update was ändern kann.

Wichtig ist jetzt das Partitionsschema zu kennen, um zu wissen, wie es funktioniert. Das ist jetzt zum Beispiel ein Beispiel, wie das auf ARM-Geräten sein kann, bei BIOS- oder UEFI-basierten Geräten ist das wieder unterschiedlich. Letztendlich hat man dann eine Systemboot-Datei,

die ist relativ klein, wo dann halt nur die Sachen drauf sind, wo der Bootloader quasi drauf ist, um die Sachen zu booten. Und man hat dann System A und System B Partition, die beide nur 1 GB groß sind. Das heißt auch Ubuntu Core, weil es halt eben ziemlich klein ist, der Kern halt eben. Wenn man das halt im Standard, sein Snap-Ubuntu bootet,

dann hat man ein Routfallsystem in System A. Wenn man dann ein Upgrade macht, dann schreibt er die neuen Dateien in System B um. Und dann schaltet er den Bootloader halt um und sagt dem Bootloader,

ja, boot den nächsten Mal von System B. Und so, dass man dann wieder zurückwechseln kann, wenn man will. System C oder System D gibt es nicht, also System D gibt es schon, aber nicht als Partition. Und dann gibt es halt eben noch die voidable Partition, da werden dann alle App-Daten hinterlegt.

Und das ist dann letztendlich der Teil, den man sich einteilt, damit der restliche Platz ja halt verfügbar ist. Und die Fallsystemtypen stehen dran, sowohl die Systempartition als auch die beschreibbaren Partitionen sind alles X4, während die Bootpartition halt eben so ein VFAT-Partitionsschema ist.

So, genau. Ich weiß nicht, ob man das so gut erkennt. Ich mache das mal im Terminal. Ich zeige euch jetzt erstmal mal, wie es denn genau aussieht, wenn man eine...

Moment, ich gehe gerade nur auf eine VM drauf.

So, ihr seht was, oder? So, nur ich sehe nichts.

Genau, Snappy Examples ist ein Paket, was verfügbar ist, wo halt eben Beispielprogramme enthalten sind. Das ist zum Beispiel, können wir jetzt Hello World angucken. Hier sieht man halt eben, welche Ordner, wie die Paketstruktur aufgebaut ist.

Letztendlich hat man zwei Ordner in diesem Fall, ein BIN-Ordner und ein Meta-Ordner. Und da ist letztendlich dann alles drin, was man für das Netpaket braucht. Jetzt könnten wir zum Beispiel in Meta reingucken. Meta, genau. Meta Hello PNG ist eigentlich nur das Bildchen,

was man nutzt, damit es im Store hochgeladen wird und mit einem Bild angezeigt wird. In der package.yml-Datei ist letztendlich die ganze Definition des Paketes mit drin. Und enthält jetzt alle Informationen, die man gebraucht wird, um halt so ein Snappaket zu bauen. Wie man jetzt sieht, wer yaml kennt, der kennt wahrscheinlich die Struktur.

Wer es nicht kennt, es ist ja einfach aufgebaut. Letztendlich hat man erstmal einen Punkt, der zwingend notwendig ist, der Name, der Name des Pakets, womit es im Store verfügbar ist. Eine Versionsnummer ist eigentlich auch selbsterklärend, genauso wie der vendor, der halt eben das herausgebracht hat. Und ein Icon. Was jetzt halt wichtig ist, sind jetzt halt die Binos.

Letztendlich gibt man den Pfad zu Binos an und kann dann halt eben sagen, wo die Binos liegen, damit die ausgeführt werden können. Ich weiß gar nicht. Genau, zum Beispiel hier bin-echo oder env-evil oder sowas halt. Das Ganze können wir jetzt halt in bin gucken.

Und ich könnte jetzt bin-echo. Genau. Das sieht man so gerade eben noch. Echo Hello World. Das ist das einzige, was man jetzt, was jetzt dieses Programm macht, wenn man eben Hello World eben ausführt.

Und letztendlich ist das eigentlich nur nichts anderes als ein Shellscript. Damit kann man schon mit vier Dateien ganz einfach ein Snappaket bauen. Man muss nur noch snappy-build aufrufen, glaube ich. Snappy-build. Und dann hat er schon das Snappaket gebaut.

Man muss also nur alles in der Jaml-Datei konfigurieren und die Binär-Dateien halt eben alle mitliefern. Wenn man halt eben diesen ganzen Live-Uis zum Beispiel mit hat. Hello World ist ein ziemlich einfaches Paket, ziemlich einfaches Programm. Und dann hat man das eigentlich alles schon mit drin.

So, was jetzt halt noch praktisch ist zu wissen. Es gibt, die Dateien liegen alle unter. Ah nee, Moment. Dazu komme ich gleich. Genau. Ich habe ja vorhin schon den Store angesprochen. Der Store ist ein anderer als die normalen Paketquellen,

wie man es aus einem normalen Ubuntu kennt. Und zwar ist das, heißt das da WebDM, womit man sich sowohl die installierten Snappakete anschauen kann, als auch selbst installieren kann. Also so Konfigurationssachen angucken kann. Das Ganze wird noch weiterentwickelt. Im Moment ist es noch nicht so featurereich.

Das zeige ich gleich in der Demo noch ein bisschen genauer. Und letztendlich ist es quasi der neue Software Center. Kann man so sagen. Es läuft alles im Browser. Es ist alles webbasiert. Genau, ein weiterer Punkt ist Ubuntu Personal. Also was ich ja gerade alles erzählt habe,

war Snapy Ubuntu halt für die ganzen normalen Geräte, die jetzt keine grafische Oberfläche oder so haben. Ubuntu Personal ist jetzt der Ansatz von Ubuntu, sowohl das auch für den Desktop theoretisch nutzbar zu machen. Das Ganze nennt sich Ubuntu Personal, was dann halt für Geräte ist, die persönliche Geräte halt eben,

die halt auch ein Display zum Beispiel haben. So könnte man zum Beispiel irgendwelche Terminals von Bankautomaten mit Snapy Ubuntu ausliefern. Da läuft dann ganze GUI drauf. Und man kann dann mit dem SDK normale Anwendungen installieren. Und letztendlich muss man dann nur die Updates anstoßen und dann laufen sie durch. Und ist dann natürlich einfacher,

weil man nur einmal die Anwendung schreiben muss, dann bleibt das soweit so wie ich stabil. Das kommt halt eben mit einer GUI, was in der Regel Unity ist. In dem Fall Unity 8. Also das neue Unity, was auch auf den Smartphones schon installiert ist, aber noch nicht auf dem normalen Desktop quasi vorhanden ist.

Und Snapy wird auch die Basis für Ubuntu Phone bald sein. Sodass Ubuntu Phone halt zwar die Vorentwicklung und wird dann durch Snapy ersetzt durch ein Update. Das wird wahrscheinlich irgendwann dieses Jahr oder Ende des Jahres oder nächstes Jahr dann passieren.

Mit Snapy wird es dann natürlich auch noch einfacher. So Sachen wie Ubuntu TV, was sie ja früher schon mal angekündigt haben, zu unterstützen, sodass man halt eben Snapy nutzt statt ein normales Ubuntu. Macht das ganze Paketierungssache noch deutlich einfacher und die Auslieferung von jedem.

Genau, jetzt kommen wir zur Demo. Ich fange mal erst mal mit WebDM an. Und zwar habe ich hier jetzt die vorhandenen Pakete,

die ich schon installiert habe. Da war ich gestern, habe ich schon ein paar Sachen gemacht. Und im Snapy Store sind dann letztendlich alle Pakete drin gelistet, die man installieren kann oder auch nicht installieren kann. Den Start, den sieht man dann oben rechts. Ich mach das mal ein bisschen größer.

So, wie man hier sieht, der Store ist relativ übersichtlich. Da ist jetzt noch nicht so viel drin, weil Snapy ist ja noch relativ jung. Und jeder kann natürlich dann Anwendungen hochladen. Der Vorteil auch bei Snapy ist, wenn man jetzt als Entwickler ein Snap-Paket gebaut hat, dann könnte ich die jetzt sofort hochladen und die ist auch sofort im Snap-Store verfügbar.

Hat natürlich eben die Vorteile, dass man da jetzt nicht anstrengend ins Debian-Paket-Archiv mit reinkriegen muss, was ja jetzt das Problem ist, wenn man ein Debian-Paket baut. Man kriegt es nicht so einfach in die Debian-Archive rein, damit es dann in Ubuntu verfügbar ist.

Dementsprechend ist das hier viel einfacher, weil es automatisch geprüft wird, ob jetzt das Snap-Paket so weit funktionsfähig ist. Genau, also ich könnte jetzt hier noch Webcam-Demo installieren. Man sieht jetzt da, dass es installiert.

Ich guck mal, ob es schon gelistet wird. Webcam-Demo, dann ist es hier zum Beispiel gelistet. Und hier sieht man jetzt nicht so viel, weil da keine Reviews, kaum Details sind oder Settings.

Was man jetzt aber theoretisch nutzen kann, ist zum Beispiel ein Snake dabei als Paket, das man sich installieren kann. Theoretisch könnte ich jetzt anfangen, Snake zu spielen, das Ganze als Snap-Paket.

Genau, jetzt ist es, weil ich eine Development-Image habe,

alles offen. In der Regel ist auch SSH zum Beispiel zu. Kommt jetzt per SSH drauf, das geht im Standard halt nicht. Sonst wäre es ein bisschen blöd, wenn man sich da ein paar Apps installieren kann. Genau, im Store kann jeder was hochladen.

Die werden automatisch geprüft. Wenn da ein Fehler war, dann wird es händisch geprüft. Also du willst jetzt halt eine Firmenumgebung haben,

wo du halt irgendwie welche Geräte hast. Du willst aber nicht den Store von Snap-P nutzen, weil es halt eben auch nicht öffentlich sein soll.

Also ich weiß jetzt nicht, ob man Web-DM selbst direkt nutzen kann. Es gibt aber Snap-P Remote, womit was per SSH läuft, um dann halt, dann wird es ein Shell-Script. Genau, aber letztendlich hast du dann selbst die Kontrolle und kannst es halt an alle Maschinen schieben,

die du jetzt haben möchtest. Was tatsächlich dann vereinfacht. Genau, jetzt kommt nochmal,

jetzt bin ich auf meiner VM drauf, die ich jetzt gestartet habe, wo Snap-P installiert ist.

Letztendlich habe ich ein KVM-Image eigentlich nur gebootet, um es mal zu zeigen. Wenn jetzt mal versucht, UpGit auszuführen, dann sagt er hier, UpGit gibt es nicht, probiere es mit Snap-P. Also kann ich jetzt Snap-P ausführen, und er sagt mir dann direkt auch die Kommandos,

die verfügbar sind. Und jetzt könnte ich zum Beispiel Snap-P-Listen machen, dann zeigt er mir die Programme an, die installiert sind. Hierüber kann man natürlich dann auch noch die ganzen Anwendungen installieren, die man jetzt haben möchte. Snap-P-Search. Und jetzt könnte ich zum Beispiel Chatroom suchen.

Und hier zeigt er jetzt auch direkt dann an, dass ein Paket verfügbar ist. Und ich kann das dann mit Snap-P installen. Chatroom. Genau, ich habe es zum Beispiel schon installiert, also kann ich es nicht nochmal installieren.

Und es ist ähnlich wie UpGit von der Nutzung her. Was man jetzt gucken kann, ist, die Daten liegen alle unter Slash Apps. Wenn man jetzt eben guckt, dann hat man zum Beispiel Snake.

Dann sieht man jetzt hier die ganzen Ordner, die in dem Ordner letztendlich drin sind. Das sieht man halt auch später, wenn ich jetzt ein Update machen würde, was mit Snap-P-Update geht. Es gibt keine Updates, weil ich es gestern erst eingestellt habe.

Dann sieht man in der Snap-P-List auch mehr als nur eine Version. Hier sieht man jetzt Version 4 von Ubuntu Core. Heißt also, seit dem Release von Ubuntu 15.04 hat es vier Updates gekriegt. Und das Ganze geht halt auch bei den normalen Anwendungen,

die dann eben wieder zurückgesetzt werden können. Das Ganze sieht man dann eben auch hier, dass man zum Beispiel bei Snake nicht nur die Versionsnummer als eigene Unterorten hat, sondern auch die aktuelle Version, was im Moment nur ein Link ist,

sodass man immer noch auf die alten Daten zugreifen kann, wenn man möchte. So, ich glaube, das war es soweit. Hab ich da was vergessen? Genau, wenn man jetzt ein Rollback machen möchte, kann man Snap-P-Rollback ausführen.

Nur weil ich jetzt leider kein Programm habe, was ich jetzt zurückrollen würde, geht das natürlich leider nicht. So, ansonsten bin ich jetzt... Wo ist denn jetzt die Folie? Genau, ansonsten bin ich jetzt eigentlich soweit

zu dem Punkt gekommen, dass ich für Fragen offen bin. Ja?

Genau, also man hat diesen Rollback nicht nur auf Systemebene.

Die Frage war, ob man jetzt den Rollback nicht nur auf das System machen kann, sondern auch auf den Apps. Das geht auf beiden, das ist genau gleich. Es wird also kein großer Unterschied gemacht.

Wie die genaue technische Implementierung ist, kann ich jetzt nicht sagen. Die laufen soweit in einer Sandbox drin und laufen separat. Die können sich also nicht in die Gehege kommen, außer jetzt bei geteilten Ports zum Beispiel.

Ja, also es gibt eine Separierung zwischen den Apps. Ich weiß leider nicht die Implementierung, wie das genau läuft.

Ja, wenn du viele Layboos hast, dann musst du die... Also die Frage war eben, ob man jetzt die Layboos alle mitliefern muss. Ja, die muss man alle mitliefern.

Man kann keine... genau. Man kann keine Snappy-Pakete auf anderen... Also Snappy-Pakete können nur auf Formworks abhängig sein. Ja.

Die Roadmap. Erstmal für das Telefon wird es eben einmal gebaut. Dafür, dass es eben auf dem Smartphone läuft. Ich wollte eigentlich Ubuntu Personal, was ich ja vorhin erwähnt habe, auch noch zeigen. Das Blöde ist nur, die aktuelle Version bootet bzw. booted. Man kann sich dann nur nicht einloggen, um zu zeigen, was da jetzt geht.

Ist halt aktuell Entwicklungsstand. So, letztendlich wird noch viel... Bei WebDM wird noch viel gemacht, damit er als zentrale Konfigurationszentrale dient. Was jetzt halt eben noch relativ spärlich besetzt ist. Und... Was wird denn noch gemacht? Ja, Ubuntu Personal ist halt auch noch

der Fall, wo viel Manpower reingesteckt wird. Was auch sein kann, ist, dass früher oder später, dass der normale Ubuntu Desktop auf Snappy wechselt. Dann hat man halt eben den Nachteil, dass halt die ganzen normalen Desktop-Pakete, also das Ubuntu Personal zum normalen Desktop Ubuntu wird. Wo das auf Snap basiert ist

und nicht auf Dapp basiert. Was man aber noch wissen muss, ist, das normale Ubuntu wird wahrscheinlich nie verschwinden. Also was auf Debian basiert. Weil letztendlich werden immer die Paketquellen aus Debian oder aus den Ubuntu Paketquellen eben genommen. Daraus wird dann das Image gebaut, was dann auf den Snappy-Geräten ausgeliefert wird. Da ist das immer noch der Zwischenschnitt drin,

wo dann halt eben Snappy, wo dann halt das normale Archiv drin ist. Auf dem Desktop werden PPAs bleiben erstmal. Aber man wird jetzt sehen, wie sehr sich jetzt auf dem Desktop

letztendlich wirklich durchsetzt. Also ob das wann oder wie es kommt. Was man ja noch beachten muss, 16.04 kommt noch als normales LTS-Release. Das wird auch noch mindestens 5 Jahre unterstützt, mit Unity 7 auch noch. Und so ganz schnell wird Ubuntu auf dem Desktop

nicht snappy-basiert sein. Aber zusätzlich wird es wahrscheinlich länger geben. Es gibt keine Roadmap, soweit ich das wüsste. Ja. Ja, das gehört

mit zur Roadmap. Also die Frage war eben, ob man wie jetzt genau das Paket bauen ist. Letztendlich müsste das selbst jetzt noch händisch zusammenbauen.

Es gibt also SnapCraft, was jetzt noch Beta, glaube ich, ist. Womit du so Sachen sagen kannst, hey, ich möchte jetzt irgendeine Java-Anwendung haben, sodass du dann alle Abhängigkeiten mit drin im Paket hast. Letztendlich gibt es da noch nicht so viele Tools, damit die Anwender das wirklich einfacher nutzen können, sodass du es jetzt händisch noch selbst irgendwie zusammenbasteln müsstest.

Cross-Compiling. Cross-Compiling Toolchains Du kannst das normale Ubuntu nehmen, um es zu kompilieren und die Binaries kannst du ja so noch verwenden.

Ich weiß nicht, ob das auf dem Mac geht. Wenn du es für ein normales Ubuntu kompilieren kannst, kannst du auch für Snap-E kompilieren. Du musst halt nur beachten, du musst halt sowohl

x8664 Kompilate mitliefern, als auch A für die verschiedenen Architekturen.

Also ob jetzt genau, bei Android muss man ja nur

bei der Installation kann man sagen, ich möchte jetzt alle die Anwendung installieren mit allen Berechtigungen. Ich weiß jetzt nicht genau, wie es bei Snap-E dann der Fall ist. Letztendlich muss man es definieren. Netzwerkzugriff ist dann halt in der Regel normal gegeben, weil viele Anwendungen brauchen ja Netzwerkzugriff. Bei Ubuntu Phone in dem Fall ist es halt so, dass du es immer abnicken musst. Wie das genau bei Snap-E ist,

kann ich gar nicht sagen.

Also deine Frage ist jetzt, ob du jetzt definieren kannst, ob es jetzt auf dem Router oder auf dem Search läuft. Eigentlich gibt es da keine direkte Unterscheidung. Genau, deine Anwendung ist für alle dann verfügbar, wenn du es in die Store stellst.

Ja genau, Beagle-Bauen-Pakete konnte ich zum Beispiel nicht in meinem KVM installieren, eben weil die Architektur unterschiedlich ist. Ja gut, der Unterschied ist dann nicht im nicht auf welchen Gerät

das jetzt genau läuft, sondern auf welche Hardware-Architektur das genau läuft. Also ob das ARM ist oder Intel-Hardware zum Beispiel. Und klar, man kann jetzt keinen Kernel von Beagle-Bauen auf einen KVM AMD 64 Image installieren.

Deine Frage ist jetzt, ob man jetzt lieber Beagle-Bauen oder Raspberry Pi nutzen sollte.

Also empfehlenswert ist, Beagle-Bauen zu verwenden und nicht Raspberry Pi zum jetzigen Zeitpunkt. Das hatte ich meine ich gerade auch schon kurz erwähnt,

weil Beagle-Bauen ist im Moment die einzige also auf den Hardware-Geräten die einzige unterstützte Plattform offiziell unterstützt. Da kann man halt eben diese System-Updates machen, die man auch rollbacken kann. Das geht eben bei den Raspberry Pi halt eben noch nicht, was halt noch ein bisschen blöd ist. Soweit ich weiß, ich habe das so teilweise mitverfolgt.

Warum das jetzt für Raspberry Pi zum Beispiel noch nicht verfügbar ist, da muss wohl noch ordentlich viel Code nach Upstream wandern. Details weiß ich nicht, aber Beagle-Bauen und Black sollte man halt verwenden. Also ich habe beide zu Hause und mit Beagle-Bauen habe ich da überhaupt keine Probleme mit. So, noch Fragen?

Gut, dann wäre ich jetzt fertig. Wer die Folien nochmal angucken will, die sind auf mein GitHub-Account. Ah, noch eine Frage. Der ist nicht da. Genau.

Ja, dann bedanke ich mich und in 10 Minuten geht da mein Ubuntu Forum Vortrag los.