Welcome. Thanks for coming. So, snaps on SUSE. Just before we start, raise your hand if you know I should be here, right? Raise your hand if you know what snaps are, if you've heard of snaps.

Thank you. And keep your hand up if you've used them. Okay. Great. So, hi. I'm Zygmunt. I'm working for Canonical, not for SUSE, working with them since, like, 2010. And I've been working on Snappy for a year, give or take. And specifically on the interface system, which we're going to get into.

It's really interesting. But from what you may know me more is the cross distribution and advocacy towards snaps just everywhere. Snaps is a universal way to run and host applications. So, just briefly, I'm just going to go into snaps. Not that many people hold their hand up. I'm just going to describe snaps, how they function, how they look like.

And specifically snaps in SUSE, where are we, what kind of things we did and some plans for the future. And hopefully we'll have some time for questions. But we'll see. So, snaps are packages. I keep hearing containers, containers, Docker. Snaps are packages.

They're just like a package system. They're slightly different. They're not like a classic package system, but they really are packages. And you'll see quickly why. We have had many interesting, you know, evolutions of the packaging system, the phone products. You know, the traditional packages didn't work very well in that setting.

Like there's no DevConf, you can answer a prompt, look at the diff on your phone. Many things just didn't work. And you also had to look at how the modern app stores work. Everything is confined, known reviews, applications, line by line, you can't do that. So we had to come up with something new.

So we went through the click with a C packages for the phone. And the snaps from the previous generation, which looks slightly different. And now we come to snaps with snap D 2.0. So they're not like classic packages. First of all, the read only, you know, you unpack your software and something is in VAR, you can change it.

They're just read only images. And since they're read only images, we don't have to unpack them, you can just mount them and start working with them. We also don't have a single version of a snap. So maybe I have I'm updating from one to another, there's a new version coming out,

my system will update this application for me automatically, I will keep multiple versions around. We call them revisions, they're not quite versions, you'll see how soon. And we can use it, because we have them around on the disk, we can do delta updates. So we just download the little changes that happen between one and the other, we apply the delta and we mount the new thing.

And that's it, that's the update. You can also go back. And because snaps know exactly how to model data, where the application data is kept, where the user data is kept, when we do these operations, we can keep the data around, we can copy it somewhere safe. So we can get the update. And when something breaks, I don't know, for whatever reason, you had like an image collection

application, and the schema has been updated, but the application doesn't work. You can say, you know, this doesn't work for me, give me the stuff I had just a second ago, and we'll give you back not just the code, but the actual data you have in your system, because this is also managed by snaps.

And I think this is really the key thing. In today's world, with security, like we've been discussing security this week, and everyone seems to figure out it's important, but it's hard, it's complex, we don't really know how to do it. Snaps have been trying to solve that since like version one, and now with version two,

it's infinitely easier to get security right, because everything is confined by default. Not only just like you just get confined, you can't do something, everyone has the same confinement, it's predictable, it's understandable, both for developers, how to do stuff with snaps, and the users, you know, what kind of stuff you can expect

if you get a snap from somewhere and run it, it's, you know, I just was in a really interesting app image discussion, and I think I mentioned this is great, but in today's world, you can't afford to just get something from somewhere and run it and not confine it, it's just 90s, we just can't repeat that.

And also, snaps are not containers, they're not like, you know, you get this Docker image, it's full of ancient Ubuntu devs, and you run it and hope for the best. It's not, we don't have the whole system in a snap, it's not like you have to put, you know, gobs of gobs of bytes in it to actually get started. You'll see how a snap looks like in a second.

But this also means that because we don't like, you know, bundle an operating system with a snap, a snap actually integrates in an operating system, so a snap can provide a debug service, it can provide a service in a socket, it can just integrate with a service just as you would expect with a classic package. So, snaps are different, because they can work alongside the existing packages.

You can work with snaps on essentially all the major distributions now, whatever they're using, and it's completely different, right? But the same binary snap works and integrates with that distribution, it doesn't replace it, it just integrates with it. And really, I can't stress this enough. I've been packaging snapd for many distributions, and it's not easy.

It's just a lot of complexity for good reasons exists in traditional classic packaging. And that's hard to get, you know? We're going to keep doing this for some more time until we're absolutely everywhere, where there's an irrelevant user base, but it's not easy. And you think of a patient, you know, being packaged by a small company,

they want to do something nice, something innovative. I don't want to waste their creativity on the dept and packaging policy, it's just crazy. So, Ubuntu also has PPAs that many people use to not only distribute software, but also to distribute new software, like a new version of, I don't know, the bleeding edge photo application.

Like, I use dark table, so new dark table. So, PPAs are fantastic, but they also share all the drawbacks of classic packages, you know? I can add a PPA to dark table, and someone can steal the developer's laptop, and in that PPA, suddenly a kernel can show up. You know, it could be like 99999, hell, boy, I'm going to update.

And I don't want to do that. I just don't want to give all the confidence and trust to every PPA, because every PPA or every extra archive I enable just multiplies the attack surface. All of them can be owned, and all of them can ship a kernel, a libc, libssl, and, you know, it could be covert, maybe no one will notice for a while.

That's terrible, we don't want to repeat that. So, with Snaps, we've invented something way better. It's like a mini PPA, a mini archive, just for this Snap, and you'll see how this works soon. And this is close to my heart, because this is what I do essentially all day. Snaps are heavily focused on security. There are many interesting security mechanisms that we're using,

and this is, like, goes all the way through the system. We are paranoid about security. And in today's world, that's really relevant. So why? That's why. Not only everywhere, but everywhere in way, way, way more refined and predictable

in a secure way than all the other systems can do today. And, you know, we have things to do, but there's nothing missing in the vision, and there's nothing missing in the technology. It's just more busy work to get there. So we're going to quickly look at a simple Snack package. And so Snack package is really, really simple.

Both in the way you built them, we don't have complex policies. You can just build them any way you like. We have some nice tools if you want to use them. Entirely optional. You can just hand craft it. But we're going to look at a package from Snappy's point of view, like, I want to install this thing. How does it look like? So it's going to be really small.

It's just the application, no OS. If you need something that the OS doesn't provide, well, you need to bundle it. But you don't have to bundle, you know, Lipsys and libssl and things like that. We provide that as a base you can work on. Right now, that base is just Ubuntu, but we're working heavily to not only give you one Ubuntu, but the next LTS Ubuntu, and also any other distributions LTS versions.

So you can start, you know, an application that works entirely on top of SLE, using SLE, Lipsys, built with SLE tool chain, all of that, you know, in a snap. So how does it look like? It's really actually, I mean, you don't have to read this.

That's the whole thing. So the only important part, I would say, is the name. Name is something you hold dear. It's like, this is how you identify yourself. This is how we see the world. But it needs to be something, you know, that's your copyright, your trademark, something you want to hold. So even, you know, I can go and try to claim the name Skype,

and maybe I'll be lucky and get it. And, you know, maybe Skype and Microsoft guys are going to call us and say, you know, we're not making Skype as a snap yet, so maybe you want to pull it out. But what we can do is without changing the existing snaps, we can rename them. So names are yours if you can claim that name. But they're also not a firmly attached property of a snap.

Snaps don't have names, they have IDs. And interestingly, they don't have a version. Like, oh, my God, how many times did I have to look up how the Debian version thing works? Man, I hate that. It's just for this, versions are nice for people. They don't mean anything at all. Nowhere in snaps. They're just a label.

So some silly metadata. Really simple. You can use upstream. So like a storefront can give you way richer experience in a standard way that people have agreed upon, but just like a very simple approach, you can just stick something here. And you can see this in listings and searches and so forth. And this is interesting. So you can have multiple things in a single snap.

You can have MySQL that has a daemon and also some tools like the dump, like CLI and whatnot. You could be a single one. You could be many. You can have services. You can have desktop apps. You can have CLI tools. You can have hooks, which are kind of special, but you can think of them like package installation hooks, like all the traditional packages have.

So you have to list all of them here. And so what's interesting, which we're coming on to, is that all of them are confined. There's no way to break out the sandbox. It's not, you know, you can install like a benign package, but the configure script is just going to add an extra repository to your system. Nope. Not doable.

So that's how a simple snap looks like. It's just like, you know, it fits on the screen with a really big font. There's nothing there. There's no OS. Just what you care about. And the layout really is arbitrary. It could be, you know, whatever you want. It could be like a miniature root. It could be whatever you want. We don't care. We only care about the meta directory, and inside that we have the precious snap yaml

file that tells you lots of information about your snap, as well as some support files, like you can have like icons and a couple of other things that are not worth mentioning now. So you installed it, but how do you run it? You don't want to go back and like figure out where it's going to be and run something and bin and echo, and that's not what you want to do. Snap D, when you install a snap, gives you those launchers, put them in your path.

And if you look at how they look like, they're just symlinks. So we do the magic. We follow the symlinks, figure out what you want to do, and you run them. And actually, it's not just going to run this echo command here. It's actually going to look at your snap yaml and figure out the command you had there.

And these files are just available. You can have one binary and multiple ways to run it. So let's talk really briefly about building. I saw fantastic things about OBS this week. So we made our own. Sorry. We have something called build snapcraft io and snapcraft.

So snapcraft is just an opinionated way to build snaps, but not the only one. You can really handcraft them anywhere you like. But it's a nice service we provide. And snapcraft also is a nice twist in packaging. Like if you looked at traditional packages, you also see that they're nice. If you have another tools-based system, it's super nice.

Almost empty. The packaging is automatic. If you use, I don't know, Python, it's also automatic. If you use Ruby, it's also automatic. But boy, try to combine them together and now you have to unwind all the stack and figure out how to glue this stuff together. So we wanted to fix that. Snapcraft divides a package into parts. So I can say, no, I want to take this git repository and build it.

And it's some Java code. So let's use that. I know nothing about Java, so maybe I'm going to talk rubbish. But all of these things integrate well with what they're made for. Everything that is popular either has a plug-in snapcraft. It's easy to build. Or it's really easy to build such a plug-in and contribute.

Many of these are community-made. And the building part is super easy. It's just that you memorize the... Recall the snap.yaml file. And just add this to the bottom. There's going to be a part. And you can have as many as you like. And the int part just says, you know, I'm a CMake-like part, so build me CMake-ways.

And the code can be in many places. You'll have a git tree somewhere or a tarball on your disk or a tag on a tarball. All the complexity is possible. But it's simple if you just take the faults. So you have this nice snapcraft.yaml. You can build it locally with snapcraft.

Just snapcraft, you get a package out. Now I want to think about just building it automatically when something interesting happens. So obviously we did that. So we have snapcraft.io has that build.snapcraft.io website. And this is easy to get. You have your code on GitHub, as many people do. You click to log in with GitHub. It shows you the repositories you have.

The ones that have snapcraft.yaml are easy to pick. And that's it. There's no step C. So there's a workflow you can integrate this through. I'm going to talk about the last part. You can see auto publish to store. Store is not just a repository. We're going to get into that. But really interesting mechanisms are possible in this way.

And people like snaps. I mean, we've been talking to many people making applications. Unless they've been like hard code Linux users for ages. Packaging is a real problem for them. They really want to deliver desktop applications and server applications. And it's just hard. This is why Docker has such a nice ride.

Because they take that out. But you get this huge blob that's kind of impossible to audit. And hard to operate. And I think this is a nice middle ground. And people really like that. And now I'm going to jump to something that's super close to my heart. Confinement. But it's also a fantastic property of snaps that nothing else has.

So confinement is not just a sandbox. It's just one sandbox. There are many sandboxes. And everything gets a sandbox. So everything that's runnable. Application, daemon, service, hook, whatever. It's all confined. And as I said earlier, it's the same confinement. You do one snap. You learn how it looks like.

You can now make the next snap. It's all the same. Well, obviously, if this was equally simple as classic application to have no confinement, well, it wouldn't be any secure. So actually, sandbox prevents you from doing many things. But for that, we have something we call interfaces. Which feels like a permission system.

But it's more than that. Traditional permission slides, you know, you can do this. Period. We thought this is nice. Well, we can do better. So we have two parts of every interface. There's a plug part. And there's a slot. The slot provides something. And the plug can consume it. And it can only consume it when you plug them together.

When you connect them. And the connection establishes the actual permissions. Both for the consuming party and the producing party. So maybe there's a snap that's no, no, bluesy provides Bluetooth services. And only when there's a connection between bluesy and some snap can bluesy actually talk to that snap. Bluesy is not like a privileged snap.

No. Everything is confined equally. So snaps can provide services to the system, to other snaps. You can create useful run times for other people. You can create services for other people. And it's all confined and managed by snapd.

And just to look quickly as a simple comparison to Android style ACLs. Like, can you do this? Can you do that? That's terrible. Because every time you look at a take your phone, if it's Android, install an application. It asks for an endless list of things. What it just told you is technobabble. That you can be a technical user unless you're a hardcore Android developer.

You don't know what that means, really. But you just have a yes or no question. Do you want it or not? Do you want it or not? And that's a terrible question to ask. People want it. Why do you ask? You just ask to install it. You always want this. But if you say yes, you can get really nasty things can happen. And that's not possible in snaps.

So interfaces that are not privileged. Like, hey, it's a reasonable thing for an application to want to talk to the network. Just like, I'm an RSS feed, I want to download some feeds. Network is just an interface. That's not privileged. Everyone can get it. Maybe there's a super powerful interface that lets you almost break out of the confinement

to run, like, a Docker is a nice example. It runs all kinds of stuff. Docker interface is only given to the snap that we allow to have this interface. So Docker guys make Dockers. They get the interface. But no one else can say, I want to be Docker. Unless we have a conversation with them.

Unless they make a valid claim that they can be Docker. On a local system, on a developer system, they can still kind of shoehorn it in. But they won't be able to socially engineer anyone into claiming they are Docker or they are something else that has superpowers and break out of the sandbox. This is a really important property. Because we live in a world where we make a barrier and the nasty guy is going to figure

out how to not break the barrier but walk around it. So one thing that I really like is that snaps can offer service to the system. So it's not like you have the system which is special because it's unconfined. And there are the snaps which are like little things. But they can't be super powerful.

We built a system, entire distribution out of just snaps. Everything is a snap in that world. Including regular system services. And they're equally confined and they can have slots. So you can have a snap that provides services. Come up with a great idea and you can make a snap out of that. And that snap can interact with the rest of the system.

It's just a graph of connections between snaps. And we have quite a few interfaces today. We have 91. That's a lot. There's lots of things there. I can't even fit the whole I tried to fit the whole list here but it was just unreadable. But all kinds of applications from desktop applications to embedded to cloud.

It's all really there. And it's super trivial to add a new interface. And because of how we develop snapd. If you provide an interface, we merge it. It's available to you today. Today. In the same day. You can on your system say I want to track the core snap in which snapd lives. From the edge channel which I'm going to talk in a second.

And you're just going to get the nightly build right now. And you can start using the application with that new interface right now. But before there's an interface available to you, there's something we call the dev mode. It's just for developers. It's really really scary to install things in dev mode. And it essentially switches the confinement into non-enforcing mode. So you're going to say, you know, you can't do this.

But in dev mode, I'm allowing it. We also built some tools that look at these logs and say, you know, you're doing these things. It looks like you want this interface or that interface or these two. And it really helps developers. And also, when it just says, you know, but I have no idea what this thing you're trying to do is, let's just really figure out what you want to do quickly. And craft an interface for you so you can just keep on going.

So let's talk about the store. So store is special. It's a service offering from Canonical. It's not free software, but it's a hosted service that is free to use for everyone. You can just put snaps there. You can get started right now. We can also give you a commercial store on demand. If you're like a device maker, you have a drone and you want to make some apps that

run on the drone, but you want to control who can actually put snaps in your store, you can just have a special store from us. Actually, this store is, apart from being complex and large to scale, it's just a simple HTTP endpoint. There are a couple of things like find a snap, get a snap. There's not much there. And it's not a repository.

So many people think about, you know, I want to have a second store. I don't mind you guys have your store. I would like to have my store. It's not a repository. It's slightly different. There are choices we did, the choices we've made so that some of the complexity and logic goes away from the client side and goes to the server side. For instance, let's say there are two stores and the same snap is in both stores.

What do you do? We don't want to solve that problem. The store can figure out what to do. Maybe it's going to mask one and show the other. Maybe it's not going to show either. But it's the store side decision. And the client side doesn't have to care about this. It's way easier to figure and reason about the correctness of the store. And store handles a lot of things that typical repositories don't handle.

It handles like uploads, delta uploads. So when you are developing a game, there was a nice example from the app image developer. It's a big game. And it's great that you can have delta downloads. But geez, uploading those gigs every moment you want to build, that hurts. So we have deltas both ways.

That's really fantastic. We have all the developer workflow, like name registration payments and whatnot, reviews, everything. Also, if you have a snap that wants to use a privileged interface, there's a whole process that just lets you use it and lets your snap have that interface so it's not going to be blocked next time.

But one thing I really like about this story, and I think this really changes how people are going to think about developing software, is tracks and channels. So it's a really simple concept. I mean, it's as basic as it gets. If there's a MySQL snap, but it's just one MySQL name, there are many major versions of MySQL people may want to use. So instead of figuring out to encode the thing in the name so people can kind of

guess what they want, we just want the developers to choose. So maybe I can show you a demo later, but there are many, many versions of MySQL available, and you can just choose the one you want. And not only that, for every one of these versions, there are four channels.

And every one of these channels says what kind of things you can expect. And those are hard-coded, so it's across the whole snap. Ecosystem is going to look the same way. This is stable. It means the snap is confined, and you should expect stable performance and correctness and stability. It's candidate, almost stable, but not quite. There's a beta, which speaks for itself, and there's edge, which is something

for CI CD solutions, like just stick it straight from master. And you can choose on a per snap basis what do you want to do. You don't have to be tumbleweed all the way. You can be on a stable LTS version of your enterprise distro and then pick the thing you care about to be more leading edge or just more recent.

This is a per snap decision. And also, all the other things are per snap. So like rolling back because updates failed, per snap. You don't have to do it like it's all one big bag. So I think this is not that interesting, actually.

I should have got rid of the slide. But still, store gives you revisions. Revisions are something we talk about a lot in snapd, but it's not a number that is a version. It's just an identifier of a given upload. Whenever you upload something to store, maybe it's like GitHub builds or something you just get a number. But it's not a version that means something. It's your task and responsibility to put that number in a channel.

Say in a stable channel, I want number 9. And in detail, I want 10. So you can get tracks, whatever you like, but there are predefined risk levels that people can understand what they mean. Especially the stable channel, which is confined.

So let's quickly talk about the snapd service. Snapd is quite large, I think. There are 83 contributors. Almost 20,000 commits. There's quite a lot of history there. So it's mostly written in Go. Because Go is such a good language to write this type of application.

It's a complex user space application. Also has some C parts just to make the magic happen at the part that is closer to the OS. And snapd, I can't stress this enough. There's no enough time to actually go into explaining all of this. I'm not even going to try. But there's so much fantastic resiliency to errors and so much smarts in snapd. It's not like D package.

No, it's far, far more advanced. And what you can do to make your system stable, operational, and up to date. So snapd is a service, but there are command line tools and other clients that talk to it, like the GNOME Software Center talks to snapd. So when you can install a snap from the GNOME Software Center, it goes this way.

It just essentially handles the installation, removal, and keeping things, everything keeping up to date. And also manages security. So all of the interfaces that I've mentioned, it's not like someone can come up with a new security interface that says they can do anything, because it's easy. No, interfaces are trusted. So the part of snapd itself, snapd handles the security part.

And it's easy to audit, easy to review whatever snapd can request from the system. It's all the code. It's all versioned. So openSUSE and snapd. We had a long bumpy ride. I think we started this last year. I can't remember exactly. I think it was May.

And Golang packaging. Golang is such a nice language of packaging. Golang across distribution is completely different everywhere you look and very annoying to work with. And at that time, we just couldn't get it right. So it laid dormant in a broken state for some time. But we fixed that since. We're not all the way there yet, but we have a working package. We just want to go all the way to get it into factory and beyond.

And this repository name, I should have mentioned this, is system colon snappy. So you can get it there. So we have a working package. It works for Leap and for Tumbleweed. We update it every time there's a release. We vendor our Golang stack. And this is like a cry for help.

Can we vendor that? Do we need to put every separate Golang library into a separate package and hope for the best it still works? I don't know. I would love to talk to someone that is an expert in Golang and SUSE. One thing that I really like about the vendoring for Golang itself, because packages are just source packages, even binary ones. So it's kind of meaningless work.

But because exact same vendorized versions are used across all the distributions, the QA effort multiplies. We just get more confident than what we tested extensively actually works. And it really does save us a lot of time. But if we have to do it, we'll do it. And one thing we really do very well, I think, lately is we have a very heavy CI

system that tests everything we do. So daily development, if I make a patch today and I want to merge it, it's going to be tested on SUSE. Not only on SUSE, but on everything almost. It's like we test many different architectures and distributions and releases of these distributions. I think we have more than 100. I think we have 200. I think slightly less than 200 VMs, 24-7, building up in a different system, just

testing, compiling, running all the integration tests. We have lots of integration tests. And essentially, if it passes, it means it works. Very little gaps left. Every time you discover one, we just try to understand why it happened and fix it. We have very high confidence. That means we can move at a very high speed.

That's why we release Snapd almost every two weeks. Sometimes it's more, sometimes it's less, depending on holidays and stuff. But we are very aggressive. Snapd moves at a very fast pace while being stable. So we also do interesting things with channels. So I can't publish Snapd to the stable channel. I can only publish it to Edge that's actually done automatically.

Our release manager can take Snapd and put it into beta. And from there on, the QA teams and the project manager can go all the way. So there's some lag. When something lands in master today, it's going to release to the public in maybe two or four weeks. But anyone can start consuming these things as soon as they want by tracking a different

channel. So we have still a couple of things we want to do. We want to test Tumbleweed. We just test Leap now. I think that's going to be very easy. We want to get into factory. So from there on, we just want to be a proper SUSE package. But there's one more thing I'm running out of time. We really would like to have a conversation about AppArmor.

You guys pioneered AppArmor. We took a little bit the next step in some areas. We've extended the kernel features so AppArmor can control and mediate more things that user space does. And this makes our security just tighter. AppArmor today in SUSE does not have all the capabilities that we have in Ubuntu.

There are a few more patches left. We're upstreaming them as we go. But if you guys would consider staking some of those patches, and some of them aren't just bug fixes, hello? We would really love to have this conversation about. And finding some help, one that is as simple as it gets, just try to use snapd on your system. Try to snap something you make yourself, like tiny packages.

It's a new thing. Give it a try. You can snap something you love because you use it, and maybe the upstream guys have already snapped it. Just look for that. Tell us about it. Tell us how it feels. Maybe there's something missing. Maybe there's some integration that just doesn't feel right for SUSE. We really want to know these things. And lastly, you can stay in touch.

We have a couple of places you can go to meet us. We are on IRC, on Freenode, on Snappy. We're also on Rocket, which is a more modern version of IRC where you have to be connected all the time. And we have a fantastic, I can't stress this enough, fantastic forum, which is full of everything. And all of these things are actually snaps, which is funny. And the last thing is that you can come and visit.

We have a sprint next month, so there's details in that link. I'm going to link the presentation. I think we ran out of time, but if you guys want to talk to me about anything snappy, just grab me with a t-shirt and talk to me. Thank you.