People can keep coming in.
All right, hi everyone, my name's Dan Phillips.
I am here to give a talk that's probably quite a bit different from most of the talks in this room today.
And we'll just kind of get into it.
And we can see what we think.
So as people come in, I'll just kind of get started.
But in true fashion, I'm just going to start with a quick demo.
So I work on a project called Boxer.
Boxer is similar in terms of the devics to Docker.
So I'll just give you a quick demo, and then we can talk about it.
All right, so excuse me.
Oh, it's too small.
How's that?
Better?
Okay, great.
All right, so Boxer has the Box Steel I command,
and I'm going to ask you our course.
Boxer allows you to take a Docker file,
just like you would in Docker, and compile it,
and then have a runnable thing.
Okay, so what I'm going to do here is Box Builds.
Docker file.
Okay, one thing I should show you about this.
This is just a small little C binary that we have here.
Actually, what that looks like.
Okay, very, very simple.
Pretty not a bunch of numbers, right?
Excellent for demos.
The most important thing is this line,
which I'll come back to in just a bit.
So I built the image.
Now, I can see what we have.
You'll see that.
This looks a little big for that, but I'll get back into that later.
Cool, so now I can run.
Excellent.
Let's do it.
Now, here's the kicker.
Same exact thing.
Same exact thing runs here.
And if you read the description of the stock,
you'll understand that the reason this is possible
is because everything that was running was in WebAssembly.
Right?
So, back to the talk.
So, just quickly about me, I work at a company called Lupole Labs.
We have a product that is unrelated to this.
I lead all the WebAssembly stuff there, which is one little small part of what we do.
With our products, we have our main thing is architect.
Run, which allows you to migrate live migrate workloads
without downtime.
It's pretty cool to check it out.
This is me on my handles.
I live in Chicago.
And I run the WebAssembly Chicago research group.
And if you're ever in town come through.
We have meetups every couple months.
Cool.
So, most of us have heard of WebAssembly.
Yeah?
I think, yes.
Okay, good.
So, we're just going to talk briefly about what wasm is.
And then we'll get into how this applies to what I just showed you.
So, WebAssembly is a safe portable, low-level execution code format.
Right?
It's safe sandbox execution environment,
where they deny by default security posture.
It makes no assumption about language or host.
Right?
The best analogy the best way to think about it without getting into the details
is that it is a virtual CPU.
It's a different compilation target.
So, just like you can compile things to native platforms,
you can compile things to wasm.
It's a virtualized ISA.
It uses a bytecode binary format.
It uses a stack machine on abstract stack machine model,
with secure stacks for every single execution environment.
So, what does that really mean?
Right?
In a broad sense, it's just another architecture.
This is the way to think about it.
Key difference is that it is virtualized.
It needs a runtime to translate to machine code.
That doesn't mean that it needs to be interpreted,
however, that means that there needs to be a runtime,
and you can compile it ahead of time.
You can even jit in certain cases.
It's universal.
As in, it's an open standard.
It's in probably all of your pockets,
on at least one web browser and on your computers.
Via the browser, which is where it started.
It literally just needs a runtime that fulfills
the two-page spec, which hasn't changed since 2017.
So, easy to client-side technology.
Usually when I talk to people about this,
and they say, oh, you're working with them.
I don't do a lot of front-end stuff,
and I say, that's interesting,
because actually, I only do server-side web assembly stuff.
And we'll talk about how this applies to what I showed you
in the next few slides.
So, it's a safe sandbox execution environment.
It makes no assumption about languages
or host.
Cold start times are in the nano-to-microseconds,
depending on the size.
It's a universal compilation target, like I mentioned.
And so, wasm the joke in the wasm communities
that wasm is neither web nor is it assembly, really.
So, server-side, well, server-side wasm.
I like to think of this,
when people saw these characteristics of this technology
when it first came out in 2017,
a lot of people that were working on it had done
a lot of work and cut their teeth on things
like the JVM in the 2000s.
And when people looked at these things,
and they kind of squinted,
they realized that, okay,
it's a small sandbox at the architecture level.
If you squint,
you could think about other use cases for this, right?
And I like to call this the penicillin moment, right?
It was invented so that it could run safely in browsers,
and now people have taken it and applied it
to many different other things.
Some people talk about this progression.
It may or may not be accurate.
We'll see.
And so, when I said smaller safer faster
and much more universal,
usually someone says, no, no, no, no, no, no.
Faster, it can't be faster, right?
Because it has a run time.
This is true.
And that's why faster has an asterisk.
Faster startup times by usually several orders
of magnitude for the same code.
And then as far as the absolute performance
difference between compiled code
on a native platform and wasm,
when it's AOT and optimized,
you can typically get it within about 1.2 to 2 times the speed.
So for certain things,
it could be much, much faster.
Everyone knows this quote.
This is kind of, well, maybe not everyone,
but everyone in my world knows this quote.
And this caused a lot of VCs to become very excited.
Back in 2019.
And, you know, there's an interesting thing about this
because whether or not this has come to fruition
in the last five years is debatable.
So, today, I'm going to talk about Boxer.
Boxer is what I just showed you.
Boxer is a tool that allows you to take
container definitions right now and compile them
to lasm.
But the problem with lasm is that it's just an architecture.
It doesn't have anything.
It doesn't have a kernel.
It doesn't have a LIDC.
It doesn't have any sort of system.
It doesn't know anything about what's going on
outside of the guest.
In WebAssembly, we have these concepts.
The host is the run time.
The guest is where the wasm actually runs.
So, what Boxer does is,
it kind of makes this dev X a little bit easier.
Has anyone actually used WebAssembly
for anything in here?
Okay, cool.
So, you all know how hard it is.
Or maybe what the pain points are.
It's not quite as easy as downloading the
Docker CLI and getting started.
So, I'm going to talk about Boxer a little bit
and how it works.
So, what is in a Box?
Much like a container or the idea of a container
you have a base layer.
The base layer has interfaces.
Those interfaces are very similar to
Pozac's interfaces.
Then, we add several other layers including
a virtualized file system and system code layers.
This is a broad term which I will get into.
It comes with the run time.
And then we have the huge source code.
The way that WebAssembly modules can communicate
with each other and with the outside world
are with the concept of simple imports and exports.
The only thing that a WebAssembly module
knows about is what is exported to it
and what it also imports.
This changes things on many spectrums
and what it comes to trying to rewrite
how system layers can work.
Compared with things like processes
and interprocess communication
and communicating over sockets.
It's that right.
Thanks.
So, how could this be possible?
Here, we start here with the from alpine latest.
And you'll say wait a second.
That isn't actually alpine latest.
That is in your right.
Literally just the interfaces that the alpine image
will give you.
If you want anything else, then you can compile that
and expose it as another WebAssembly module.
Similar thing to what maybe Docker will do.
You can create something inside the environments.
You can copy to it.
You can set the working directory.
And then you can execute it.
A big part of this is the WebAssemblyFS.
The WebAssemblyFS is a possex compliant virtualized file system
that mounts with every single box.
Every single WebAssembly box.
It's written in Rust.
So obviously it's incredible.
And it implements all file system related
Cisco's and then it exposes them.
So, specifically in this project,
what we do is we wrap this raw-space file system
in C and then in C we have what's basically
a lib C which is an amalgamation of
G lib C and muscle in a very
more closely done fashion.
Artfully, also, maybe meaning hacky.
And we expose all the same possex semantics with an
esterist also.
Some key differences with the WebAssemblyFS is that things
like flushing, locking, thinking work like they might
work in the Linux VFS, but not quite as sophisticated yet.
So, there's an interesting thing there.
The other thing about this project is when people
say when we talk about trying to deploy things with
this sort of set of tools, people say, well, it's a virtualized
file system.
So, I'm not sure if I can use that for my project.
And then usually what I say is that you are already
using a virtualized file system.
You just don't know it because it's in the kernel.
And so, the idea is that we just have these
perceptions of this.
A lot of people wonder if this is another fused file system.
It's also not.
It's just made for Wazom specifically with
the communication between modules, which is one of
the key points.
Yeah, I guess I'll do that quickly.
So, right.
So, the Wazom VFS repo, you can see all of the
supported, all of the supported functions.
Great.
Okay.
I love them.
Okay, I've got some big ones.
Okay.
This is a working progress.
And this is my side project.
So, I've been working on this for about three years.
And it's just me.
But with that, we still have a
POSIX sort of surface area that we have worked on.
It's not just me.
It's me and a couple other people.
If you want to get involved, please let me know.
It's all open source.
We have about 70% of POSIX implemented,
which, wow, that seems like a lot.
But the thing with POSIX is that the idea about
POSIX is not necessarily the implementation,
rather than the interface, right?
So, POSIX maybe is just interfaces.
So, we've exposed interfaces with much of the sort of
system functionality.
But how it works, it may look like something that you would see in
Unix or POSIX, but maybe it works slightly differently.
Networking.
This is a whole other talk, right?
So, networking does work.
You can expose networking to the host, right?
If you're running on a server, you can also have this thing
that we're working on now, which is in the browser.
Like I showed you with this.
We have a networking relay, which you can do all
BSD sockets from the browser, just like you would,
and you don't have to think about it.
Using a sort of edge network that we've come up with,
it's kind of experimental, but it can work, which is interesting.
So, the interesting thing about that is you could do the same work
in the browser.
It could even be your coding environments.
You could take that, and then you can move it to a server.
You could also move it to an embedded device,
as long as there was one times everywhere.
So, lower layers.
How does this actually work?
It actually works with a project called Markot.
Markot, we're in Belgium, so my French is not very good,
but in old French, this means like substrate, right?
Like a lower layer.
Right?
So, Markot basically is what I told you about the Frankenstein
lib C operation that I do, where we have G lib C and Muscle.
And we sort of expose all of those things.
And we have a matrix of every single positive function
and how well supported it is, right?
And some of the more challenging ones are at the end,
where it's coming to things like process and thread management,
signals, time and date, and it's not too hard.
Memory management also not very hard.
But we've about 30% left that we're trying to implement.
We're open to ideas, but the idea is that this sort of thesis for this
was that with many containers, the average container user
may not care about what the architecture is.
Maybe 5% do, right?
There's also parts of the puzzle, because the puzzle is a little bit
of a leafy abstraction in places, like if you've ever had the
bad fortune to use a set jump and long jump,
you will understand that it is tied to specific architecture.
There are no registers in WebAssembly, right?
So there's quite a few challenges there.
But for 95% of things, it's very possible that you could run a container
in a smaller, safer, faster, and more universal environments.
This is a picture that I had to chat to IPT make for me,
and I think it kind of fits kind of a fun thing.
And some metrics.
So there are in the AI revolution that we're in.
There's a lot of Python users, a lot of people want to run
Python in the browser.
There's already works with WebAssembly things like
Piedide and with Jupiter light, Jupiter notebooks.
So this is just a small matrix of the differences, right?
The same app with, and this doesn't also include the
kernel and the runtime for the container.
This is just the container, right?
So 80 to 900 megabytes, start of speed,
could be in the seconds.
The difference is that the same box with all of the functionality
in it, six megabytes.
And if you extract just the source code,
500 kilobytes, you can move that around to different environments
where those system functions are snapshot it.
I'm going to move a little quicker.
So paradigm shift.
Maybe this is possible, maybe it's crazy,
but this would allow for some really interesting things in the future.
Like a composable universal,
based operating environment in a more distributed fashion.
True isomorphism.
If you remember the Node.js craze from a few years ago,
this is actually isomorphic, right?
You're actually running the same exact code everywhere,
but in a polyglot fashion.
And then finally, if we have any fans with plan 9 in here,
the idea of a secure CPU is a secure stack for every single execution.
This is something that comes a little closer to that.
If you have more questions, I would love to talk with you after.
So thank you.
We actually have time for one question, I guess.
Is there one question?
Yeah, there's one.
Sure.
Just a general question.
I didn't hear you mention anything about the component model.
I just wondered how this ties in.
$1,000.
It's an excellent question.
The component model.
Yeah.
I don't know if anyone else has heard of the component model.
Yeah.
Okay, cool, cool.
So the component model is, that's with Wazzy.
I didn't talk about Wazzy at all.
The component model is a really cool idea.
And it's basically strongly typed function wrappers around Wazzy modules.
And it's composable at different levels.
But they are many people in that group.
And I'm actually part of the standard group with Wazzy.
That group is not as interested in providing
physics compatibility.
In fact, they kind of see that as a separate thing.
Yeah.
But the thing is, with these interfaces, at the lower levels, those could be components.
And you could have components all the way down.
And so certain interfaces could be componentized.
And that's just a different implementation detail.
So, yeah.
So, thank you.
Thank you.