Episode 1

HockeyStick #1 - Unix, Containers & Unikernels

Published on: 16th March, 2024

Today, we’re taking a deep dive into kernels and operating systems: where they come from, the history, and the evolution. We’re covering classic OSes, as well as virtualisation, containers and unikernels.

I’m joined by two experts. Ian Eyberg, the CEO at nanoVM, a firm specialising in unikernels, and a multiple patent holder, and Sachin Kamboj, PhD University of Delaware, expert in Kubernetes and linux containers.

Transcript
Speaker:

I'm Miko Pawlikowski, and this is HockeyStick.

Speaker:

Today we're taking a deep dive into kernels and operating systems.

Speaker:

Where they come from, their history and their evolution.

Speaker:

We're covering classic OSes as well as virtualization, containers and unikernels.

Speaker:

I'm joined by two experts.

Speaker:

Ian Eyberg, the CEO at NanoVM, a firm specializing in unikernels and a

Speaker:

multiple patent holder and Sachin Kamboj.

Speaker:

PhD, University of Delaware, expert in Kubernetes and Linux containers.

Speaker:

Welcome to this episode, and please enjoy.

Speaker:

Hello guys.

Speaker:

Yeah, thanks for having us.

Speaker:

I'll just do one correction.

Speaker:

I'm an expert at breaking things, but nothing else beyond that.

Speaker:

I prepared three questions for you, and for each of them you've

Speaker:

got a different objective.

Speaker:

You can cooperate, and whoever wins gets the most points...

Speaker:

which don't count for anything.

Speaker:

So, let's start.

Speaker:

Which sentence of the three is true:

Sentence A:

about 4.3 billion years ago, as the Earth cooled and turned from a

Sentence A:

burning bowl of gas into a rock, The first simple live forms started emerging.

Sentence A:

Somewhere in that primordial soup, unaware of its future success, was the

Sentence A:

great ancestor of Unix, which millions of years later, in various forms, would

Sentence A:

roam the Earth and whose descendants would dominate their ecosystem completely.

Sentence B:

in Greek mythology, Prometheus is one of the titans and the God of Fire.

Sentence B:

Prometheus is best known for defying the Olympian gods by stealing Unix

Sentence B:

from them to give it to the mortals.

Sentence B:

His eternal punishment includes getting his liver eaten by

Sentence B:

an eagle every single day

Sentence C:

unix is a family of multitasking, multi-user, computer

Sentence C:

operating systems that derive from the original AT&T Unix, whose

Sentence C:

development started in 1962 at the Bell Labs Research Center by Ken

Sentence C:

Thompson, Dennis Richie, and others.

Sentence C:

Oh, man, definitely either A or B.

Sentence C:

C is too boring to be true.

Sentence C:

Okay, so you have to agree on the answer.

Sentence C:

Which one is it A, B, or C?

Sentence C:

I might have to agree with Sachin here.

Sentence C:

as they say in JavaScript land.

Sentence C:

It's more truthy.

Sentence C:

Alright, so you eliminated option C, option A or B, this then

Sentence C:

I think I like the Prometheus story and the liver more than scientific facts

Sentence C:

about Earth cooling and primorial soups.

Sentence C:

So I think I'll go with the Greek mythology one, even though

Sentence C:

we all know what the answer is.

Sentence C:

But yeah, my an my answer is B, lock it in.

Sentence C:

Yes, I indeed did make up some mistakes in the Unix one, so I

Sentence C:

would accept either option A or B.

Sentence C:

Alright, question number two, which quote from Dennis Richie is made up:

Quote A:

Unix is basically a simple operating system, but you have to be

Quote A:

a genius to understand the simplicity.

Option B:

for infrastructure technology, C will be hard to displace.

Option C:

the number one benefit of information technology,

Option C:

is that it empowers people to do what they want to do.

Option C:

Which one of these is made up?

Option C:

Hmm.

Option C:

I'll go with number one.

Option C:

Okay.

Option C:

Sachin?

Option C:

I would say number C or number three,

Option C:

yes, that was a quote from Steve Ballmer, not Dennis Richie.

Option C:

Well done.

Option C:

All right.

Option C:

And the last question then for you, which Linux distribution did I just make up?

Option A:

Rocky Linux,

Option B:

Chrome OS,

Option C:

Ubuntu cinnamon

Option D:

Debian TV.

Option D:

Well, there's no Debian tv, so

Option D:

There we go.

Option D:

perhaps we should do a reality show on Debian TV and call

Option D:

it, "this is our calling".

Option D:

Reality on Debian TV.

Option D:

Very well done.

Option D:

You got 3000 points and you both win.

Option D:

Congratulations.

Option D:

You've earned it.

Option D:

Alright, so where should we start?

Option D:

At the beginning of the primordial soup where at the beginning ,of

Option D:

time there was Unix, what's the best place to start talking about

Option D:

kernels and operating systems?

Option D:

Should we start by even before then, and what are operating

Option D:

systems and what's a kernel and why are we even talking about them?

Option D:

Or do we just assume that everyone knows that and everyone is an expert on that?

Option D:

What is kernel, Sachin?

Option D:

I guess I first need to get into what is an operating system before I do that?

Option D:

The way I think about an operating system is that it serves two functions.

Option D:

The first one is to manage all the hardware and software

Option D:

resources of a computer.

Option D:

... And the second one is to provide an interface to the

Option D:

higher layers of software.

Option D:

I think of an operating system as those two functions.

Option D:

I don't know what's a good analogy for that.

Option D:

A kernel is basically the core of the operating system

Option D:

that does these two functions.

Option D:

The way I think of a kernel, is something that runs in kernel space as opposed

Option D:

to user space, but I don't know if that's an accurate description or not.

Option D:

I think that's pretty accurate.

Option D:

You need something to broker access to the various pieces

Option D:

of hardware that you're using.

Option D:

Even if it's a virtual machine, you still have handful of drivers, like

Option D:

you want talk the network something.

Option D:

Not everybody can whip out a TCP/IP stack on demand.

Option D:

That's, how we subdivide it.

Option D:

My first question when I looked at that was like, okay, so this seems

Option D:

to be starting in the early 1970s.

Option D:

So what would happen before that?

Option D:

Would everybody have to whip out their own TCP/IP stack was TCP/IP

Option D:

invented in 1970,

Option D:

So

Option D:

all custom before that.

Option D:

You have to figure out what happened before Unix and before that computers

Option D:

were so expensive and we're talking about mainframe CR and supercomputers,

Option D:

and they were really tossed with, doing one job and doing it relatively well.

Option D:

So the operating systems of, the previous years were really

Option D:

designed for batch processing jobs.

Option D:

I need to compute a whole bunch of census data, or I need to compute

Option D:

this data on this many tapes.

Option D:

And all I'm doing is I'm basically loading a bunch of tapes, running

Option D:

this algorithm, completing it, and then going on to the next task.

Option D:

And again, this is way before any of us were born.

Option D:

I'm all talking about hearsay here, but that used to be the

Option D:

operating systems of the past.

Option D:

Were mostly dealing with, tape storage and data crunching,

Option D:

and really expensive machines.

Option D:

Most of the operating systems at that time were written as

Option D:

either machine code or assembly.

Option D:

Actually fun fact, the first version of Unix was also written in assembly.

Option D:

It was rewritten in C think I'm thinking 1973 if my data is correct.

Option D:

That was no C to write it then, so they had to

Option D:

yeah,

Option D:

same for the C compiler,

Option D:

oh yeah, even before then, pre-Unix and so forth, there wasn't really a lot of

Option D:

market demand for having kind of a general purpose system like that begin with.

Option D:

Cause people were so conditioned to buying these machines do whatever task they had,

Option D:

and they weren't really thinking, "oh, I want to do lots of different things

Option D:

on it" different vendors especially.

Option D:

That was one thing kind shaped how machines the

Option D:

systems that ran before worked

Option D:

Oh, that's actually a very good point.

Option D:

One of the things that you talk about, typically when you bought a computer,

Option D:

you bought an integrated stack.

Option D:

If you think that Apple, of today's a walled garden and you're buying, a fully

Option D:

integrated system like, you're on MacOS and the operating system and the computer

Option D:

is all controlled by Apple, think of it as if you bought an ID IBM or a DEC computer.

Option D:

The hardware, the software, and everything that ran on, at all the

Option D:

peripherals that were made by one company.

Option D:

And that was the company that you bought the machine on.

Option D:

So they basically wrote the operating system for that.

Option D:

I think the story of Unix itself goes back to the PDP7, and it was

Option D:

just like, from what I've heard, it was lying in a corner somewhere,

Option D:

where it wasn't really being used and they wanted to play a game for it.

Option D:

That's how they started programming it.

Option D:

And it was mostly an accident that it happened.

Option D:

They worked on it and then at that point in time it was like " we're

Option D:

selling these big expensive computers, who cares about software?"

Option D:

And software as a distinct entity did not exist.

Option D:

So I think one of the key things is like the first versions of Unix actually

Option D:

came with the source code to it.

Option D:

If my notes are right, they didn't actually release them into the world

Option D:

until I I think the fourth edition was written in C, which was around 1973, and

Option D:

that it actually went outside into the world around 1978 or 1979 or so, and

Option D:

it came with the full source code to it.

Option D:

so who are these people?

Option D:

Because, to me they're like half myth, half legend, who are they?

Option D:

The researchers?

Option D:

Are they delivering commercial solutions as well?

Option D:

They're just chilling there and inventing stuff?

Option D:

What's happening there?

Option D:

I think you have to go back during that time, so this is like late sixties, early

Option D:

seventies when, Ken Thompson, Dennis Richie people like that were working

Option D:

on Back then, it was common for bigger companies to have larger R&D labs.

Option D:

That is not the case today.

Option D:

Like even at Google's Project X Labs, they're just nuking

Option D:

that entire organization.

Option D:

But uh, back then, like it was pretty common that if you were a Boeing or

Option D:

a Bell or somebody like that, you would have this massive R&D apparatus.

Option D:

And that was partly because it was still coming out of the Cold War R&D era.

Option D:

That's that environment that it comes from.

Option D:

And a lot of these guys they did wind up at Google, starting in 2000 and so forth,

Option D:

so that's like where you languages, go and stuff Russ Cox and all those guys.

Option D:

I think the other thing we have to remember, at that time,

Option D:

AT&T was still a monopoly.

Option D:

And being a monopoly, they were eighties, really profitable, making a shit ton

Option D:

of money and one place to spend.

Option D:

It was like, look at all the fancy research that we do.

Option D:

So does it exist today or is it the Nokia labs the moment?

Option D:

What they do today?

Option D:

Are they still inventing stuff?

Option D:

When existed back then has gone so many different, different, transitions.

Option D:

the breakup in the early eighties split it up into six or seven

Option D:

different regional mini bells.

Option D:

And then, different BUs have been bought and sold and rebranded

Option D:

a ton of different times.

Option D:

I think it was the late 90s and the early 2000s when a lot of

Option D:

those people did start migrating to other companies, such as Google.

Option D:

So all the guys who were working on Plan 9 wound up there.

Option D:

So why is everything basically tracking back to Unix?

Option D:

Is it because they got it right the first time?

Option D:

Is it because it was the only real thing that was out there in the open?

Option D:

Why Unix?

Option D:

Why not something else?

Option D:

I think people vastly underestimate the amount of work that goes

Option D:

into an operating system.

Option D:

If you look at today's world server environment, forget mobile or

Option D:

anything, but just look at server.

Option D:

There's really only two, real dominant players, that's obviously Linux.

Option D:

And then you have, windows that's leaching off of like active

Option D:

directory and stuff like that.

Option D:

All that is still heavily prevalent in most Fortune 500s.

Option D:

But yeah, both of those, you can trace their lineage, not Unix, but like

Option D:

their lineage back into the early 90s.

Option D:

And so it's just a immense amount of work to provide something

Option D:

So what does Unix actually bring us?

Option D:

If we were to compare like a modern Linux to Unix which bits would be similar?

Option D:

Which were the ones that they got right the first time

Option D:

I am not sure they got anything right the first time.

Option D:

And I'm not sure anybody ever gets everything right in software.

Option D:

There's a Unix hater's handbook and it's a fascinating read.

Option D:

And it's hilarious because it tells you where people made a

Option D:

lot of mistakes and did that.

Option D:

But I think the end story is the people who worked on this, just

Option D:

to be clear, I would say they're geniuses and they're some of the

Option D:

smartest people you'd ever meet.

Option D:

So it's not that, I'm deriding them or saying that they didn't get anything,

Option D:

I think they got a lot of things right.

Option D:

There are a lot of important ideas that came out of Unix and that

Option D:

were copied and, used for a while.

Option D:

But I think it's just that the systems that we're building now are

Option D:

so much more complex and there's so many cases and, that were

Option D:

unimaginable when they started out.

Option D:

So it's actually incredible that, these systems have survived something like,

Option D:

what, 50 years now which is mind blowing.

Option D:

It's actually a, really fascinating history.

Option D:

What are the key concepts that, you think Unix was really good at?

Option D:

I think one of the ones that comes to mind is that the whole

Option D:

idea behind everything is a file.

Option D:

And just giving everything a file interface had some.

Option D:

Nice things about the way you can program things that I thought was key.

Option D:

I think, if you're not talking about kernels, if you're talking about

Option D:

operating systems in general, I think the whole idea behind, having individual

Option D:

programs that do one thing, do it well, but combining it together and, piping

Option D:

the data from one to the other was a very interesting choice of things that

Option D:

wasn't possible at one point in time.

Option D:

I think there are a few key concepts that they got really well.

Option D:

But I think one of the key things that happened around that time was this idea

Option D:

of multi-processing or multi-programming becoming a thing and eventually we've

Option D:

gone to, where we used to have one processor to having multiprocessors and

Option D:

multiple cores, and now we're dealing with something like, even a standard

Option D:

computer that you buy off the shelf now has 64 cores, which is you're

Option D:

talking about supercomputer territory in the 1970s or something like that.

Option D:

So I think a lot has changed.

Option D:

I'm recording this on the MacBook.

Option D:

That runs MacOS which has some BSD lineage.

Option D:

I have OBSD from 2001, 2002, somewhere around that point.

Option D:

There was a few years where FreeBSD didn't really have great

Option D:

SNP support in the early 2000s.

Option D:

And so a lot of users dropped off during that time period.

Option D:

Obviously MacOS is more or less stolen from the BSDs and then they layered

Option D:

on all the other stuff from Cupertino.

Option D:

What's the relationship between the original BSD, the Berkeley

Option D:

Software Distribution and Unix itself why was it started?

Option D:

Berkeley wanted something that they could use for free.

Option D:

The reason it's called BSD Berkeley Software Distribution, is that the

Option D:

first version that was released with Bill Joy, was using the

Option D:

exact same Unix source codes.

Option D:

It was literally Unix from Bell Labs.

Option D:

They added programs like, ed and roth and a few other things, and that's

Option D:

what they called the distribution.

Option D:

The distribution was actually software on it, but the kernel

Option D:

was still, the Unix kernel.

Option D:

Eventually it came to the point where, AT&T was like: "wait, software is a

Option D:

thing, we can make money off this, and we need to protect our intellectual

Option D:

property and, be fancy about it".

Option D:

So at that point in time, I think, they started with "okay, we'll

Option D:

have to rewrite some of this".

Option D:

And that's where they actually started rewriting quite a bunch of

Option D:

the code and made sure that they did it in a way that they, would not

Option D:

actually copy any of the original code and be completely independent.

Option D:

And, Bell Labs did end up, selling the intellectual property that was Unix.

Option D:

The funny thing was they actually , sold the trademark and sold the source

Option D:

code separately to two different companies or something like that.

Option D:

And I believe Novell actually ended up suing the University of Berkeley and

Option D:

saying that, "you own our, , copyrights" and the case was actually settled in

Option D:

Berkeley, in BSDs favor except for, I think, three actual files that they

Option D:

said was, " infringing their copyright".

Option D:

And those three files ended up being rewritten.

Option D:

And then the agreement was that novel or whatever, who owned those copyrights would

Option D:

agreed that, they don't own any other code and the BSDs and then you can use BSDs

Option D:

without infringing on anybody's copyrights and anybody's intellectual property.

Option D:

So yeah, that's a little history as I understand it.

Option D:

BSD originally started out with the actual Unix code.

Option D:

It was rewritten for that.

Option D:

I think the biggest reason why BSD became so popular was not

Option D:

just that it had the code and the utilities on top of it, I think.

Option D:

The biggest reason BSD became so popular was because it had an implementation of

Option D:

the TCP/IP stack that was spectacular and more performant than the official

Option D:

version that people were working with.

Option D:

So that's where a lot of people, started using it, especially with

Option D:

I think BSD 4.4, which was huge.

Option D:

I think the internet and Unix goes hand in hand.

Option D:

And the story behind that, mainly because of TCP/IP,

Option D:

Do you know the story Free BSD and Net then OpenBSD?

Option D:

Why they split?

Option D:

FreeBSD and NetBSD were made concurrently, , they took the BSD

Option D:

code and started working on it.

Option D:

think of them as almost like distributions of Linux.

Option D:

Just that instead of using the same kernel, they fork off

Option D:

the same base and then started developing them independently.

Option D:

OpenBSD is really interesting.

Option D:

So the NetBSD, the idea behind that was mainly portability.

Option D:

They wanted to support the largest number of architectures and one of the things

Option D:

they did was they had a clear demarcation between this is machine dependent

Option D:

code and this is machine independent.

Option D:

And being able to define, " these are the parts that need to speak to specific

Option D:

CPU architectures, and these are like the completely independent ones".

Option D:

I think the key idea behind OpenBSD , I think it's called WRX or it's

Option D:

either writeable or executable.

Option D:

And the idea behind memory or management was that certain pages

Option D:

would only be writeable or certain pages would only be executable.

Option D:

So they did a huge ton of hardening in order to create OpenBSD.

Option D:

OBSD's always been years ahead, especially in terms of Linux

Option D:

when it comes to security.

Option D:

They were the first to do redirects, they were first to do ASLR.

Option D:

They were first to do lots of things, rock gauge mitigation, everything.

Option D:

To a degree that they're willing to completely destroy user space and

Option D:

break it, which Linus is famous for.

Option D:

Like we don't, kill user space.

Option D:

They've always had that stance and they've had the, stance of "screw

Option D:

you, security is more important".

Option D:

It's one of those things where it makes it hard to bring it into a normal corporate

Option D:

prod environment, because of that reason.

Option D:

But at the same time, they are the trailblazers when comes to like that.

Option D:

People would argue that they have some really good implementations of

Option D:

certain things that Linux is lacking.

Option D:

I'll just name it right now, "pledge and unveil", for instance.

Option D:

Linux still is complete crap when it comes to locking things down.

Option D:

SELinux is just not usable.

Option D:

It's really poorly designed.

Option D:

It's not finely scoped.

Option D:

I don't think pledging and unveil is like the right answer, but it's

Option D:

a lot better than SELinux or some of the other LSMs that exist today.

Option D:

I think for the benefit of other people who might have a vague idea and as they

Option D:

read about and use Linux or whatever they're using, they see a bunch of

Option D:

standards or like acronyms that might not necessarily make a lot of sense.

Option D:

I know that for myself, I'm still a little bit fuzzy of what's

Option D:

part of POSIX and what's not.

Option D:

Do you know where this actually come from and what POSIX actually

Option D:

means in practice, for example?

Option D:

It comes from the open group.

Option D:

So it's, it's a set of standards.

Option D:

And really this goes back to the Unix wars of the early 90s.

Option D:

We, like briefly mentioned it, in the early 90s, you had all these

Option D:

corporate vendors with their own proprietary versions of Unix.

Option D:

And so this is, actually the birth of Linux, by the way.

Option D:

And so they're all suing each other.

Option D:

They're all saying, Hey, you're infringing on my stuff and that's mine, not yours.

Option D:

And so that was actually one driving reason behind Linus in 92, 93 when he

Option D:

releases Linux, is because there really wasn't "a free, unencumbered Linux".

Option D:

You had GNU going on forever with a lot of the user land, but not an actual kernel.

Option D:

And so that was a major reason.

Option D:

Obviously with Tanenbaum, he had Minix, which was a teaching operating system

Option D:

which Linus basically, took that and as like a rough draft and went to town on it.

Option D:

What other acronyms are there?

Option D:

There's ELF, the Executable and Linkable Format.

Option D:

Was that part of Unix as well or is that

Option D:

No.

Option D:

So like a.out used to be predominant format say in the 90s and, there's

Option D:

different formats for different systems that people would use.

Option D:

But ELF is actually a relatively newer format.

Option D:

we're talking about the decades here, a.out, which is still in use on say

Option D:

FreeBSD, for instance can still use that.

Option D:

And how is ELF related to ABI?

Option D:

It's

Option D:

more breaking up the binary into different sections.

Option D:

When you have a program there's lots of other things that are going on.

Option D:

Your program is probably not just one binary more than like 99% of

Option D:

the programs out there are gonna be dynamically linked to a handful

Option D:

of libraries in particularly lib C.

Option D:

You're gonna have a whole bunch of other stuff LibNSS for DNS

Option D:

and, maybe you're Instagram, so you use libmagic or whatever.

Option D:

So you have all these different libraries and somehow the program has to know how

Option D:

to load that and link it in proper spot too, so we know where all the symbols are.

Option D:

I make a call to a function, I know where to actually address that function.

Option D:

And then there's also page permissions and things like that,

Option D:

different parts that are marked.

Option D:

As we mentioned earlier, different parts can be read, write, execute.

Option D:

It's analogous to user permissions, but it's a different concept.

Option D:

We're really talking about parts of memory that have these functions and

Option D:

it's actually something that's showing up again when we talk about Wasm,

Option D:

because Wasm doesn't have any of this.

Option D:

And what's GNU you said?

Option D:

I've always pronounced that.

Option D:

/nu/ realizing now.

Option D:

So what, got a certain Stallman who appears in the picture and

Option D:

likes recursive acronyms yeah?.

Option D:

GNU is GNU's, not Unix.

Option D:

And that's very hipster.

Option D:

What's GNU.

Option D:

we're really tracing back to the FSF Free Software Foundation and again

Option D:

it goes back to the fact that a lot of these companies back during that

Option D:

time, had proprietary versions Unix.

Option D:

And you want to use it, gotta pay for it.

Option D:

That just didn't work broke college students.

Option D:

It didn't work for, hobbyists.

Option D:

If I just look back on my own kind of, upbringing or whatever this

Option D:

was the software that we could use it we couldn't just go download

Option D:

some random, corporate made software.

Option D:

Whatever free was what we could have.

Option D:

And also this kind of touches, I think on this whole like,

Option D:

definition of open source today.

Option D:

So you have all these companies that these BSL licenses so forth.

Option D:

And, some people are getting a little bit crazy too, because they think they

Option D:

have the right to just copy some other code and call theirs because open source.

Option D:

That's not the open source that I grew up with.

Option D:

I'm like 40 now.

Option D:

When I was like, say 12 and I wanted to use Linux to, play a game or whatever.

Option D:

What I would run into is I would go find a voodoo three,

Option D:

whatever graphics card, right?

Option D:

And

Option D:

Yeah.

Option D:

I would compile on X and it, and the driver would not work because

Option D:

parts of the driver were not there.

Option D:

Like literally the code doesn't exist, that was just not something that they did.

Option D:

Same thing with win modems.

Option D:

I was on like maybe a 28.8 baud modem and I want to upgrade to a 36k.

Option D:

I go out, spend my hard earned 50 bucks or whatever it was, and guess what?

Option D:

The modem doesn't work because I literally don't have code for it.

Option D:

It was never about ripping off the modem manufacturer and like

Option D:

rebranding and reselling code.

Option D:

It was more of I just want use the damn product So that's a big difference

Option D:

between today's like definition of open source and like what open source

Option D:

concerns were back in, say the mid 90s.

Option D:

Actually the fun story, just to reiterate your point, of the way I've heard it as

Option D:

Richard Stallman before he started GNU, used to work at MIT on one of the labs

Option D:

and he was working with a printer driver.

Option D:

And the printer driver was buggy.

Option D:

And he was like, let me just fix this because if something's

Option D:

broken, why don't you fix it?

Option D:

And he was like: "wait, I can't fix this because I don't have

Option D:

the source code for this?"

Option D:

That's preposterous.

Option D:

Like how can I not have the source code to fix a bug

Option D:

. So he decided, and I think the biggest thing to come out of GNU was probably

Option D:

the GPL, or the idea behind Copy Left.

Option D:

And the whole idea that, " I'm going actually use copyright

Option D:

to enforce open source".

Option D:

So the idea is behind the GNU licenses , if you want to distribute

Option D:

any of the binary, you have to distribute the source code with it.

Option D:

That's the idea behind it.

Option D:

And Linux adopted GPLV version two, and that's really a big

Option D:

reason behind its success.

Option D:

I would say companies do not like GPLV two very much because they

Option D:

can never close it up anymore.

Option D:

With FreeBSD or with the BSD-style licenses, you can create a closed source

Option D:

version of something if you wanted.

Option D:

Yeah, that's why they call them "viral" licenses, right?

Option D:

Because once you're infected, you can never close it back So, GNU was

Option D:

not, it's a bunch of things, right?

Option D:

It's the GNU compiler, it's a bunch binutils.

Option D:

a bunch of core tools.

Option D:

glibc, right?

Option D:

And then there's the GNU hurd.

Option D:

That, last time I checked, it still wasn't finished.

Option D:

Do you think it's ever going to be feature complete?

Option D:

That's another thing I liked to play with back in 2000, 2001.

Option D:

So yeah, the thing is it's a research toy, right?

Option D:

The core concepts behind it are really interesting.

Option D:

It never really got to the point where, people were really using

Option D:

I mean for not any real purpose.

Option D:

Operating system development is really hard and complicated and takes time.

Option D:

It's not something that, a grad student with a semester or two can

Option D:

just like whip out weap out and make something that's production quality.

Option D:

Andrew Tanenbaum wrote Minix because he wanted to teach his operating system

Option D:

class how to write an operating system, and it was like the best way is to have

Option D:

a working, operating system to play with.

Option D:

And people were like so excited, "oh look, there's operating system and it does this

Option D:

and I want to add this feature to it".

Option D:

And they were like "Hey, here's some code.

Option D:

I want to add this feature, and I want to add this feature, and

Option D:

I want to add this feature".

Option D:

And he was like, "oh, your feature is awesome.

Option D:

I don't have a problem with it.

Option D:

The biggest problem is if I add it to Minix, the operating system becomes more

Option D:

complicated and now I can no longer teach it in a single semester graduate course".

Option D:

So he was like, "no, my primary purpose behind Minix is I want to

Option D:

be able to teach this to people.

Option D:

And if I add all these fancy little features, that are very

Option D:

important and awesome and needed, I won't be able to do that".

Option D:

And eventually people were, that was one of the things that, that was like, oh, you

Option D:

don't have a multi-threaded file system.

Option D:

Are you crazy?

Option D:

Like, that's why it's brain dead, so I'll just make my own.

Option D:

And there was this big flame bar between Linus and Andrew Tennenbaum

Option D:

where, Andrew Tennenbaum famously came out and said Linux is obsolete.

Option D:

And that's actually a fascinating read if you read through that.

Option D:

That's one of my favorites.

Option D:

But I think we are getting back to, what's a microkernel versus

Option D:

a monolith and things like that.

Option D:

So wasn't that one of the main accusations that writing a monolithic kernel is silly

Option D:

and he should have done a microkernel.

Option D:

I a lot of that was driven because when you look at some of the domains

Option D:

that Andrew was working in, outside of his teaching, and some of the systems

Option D:

that really do demand that sort of design our tosses we'll touch on this.

Option D:

And then also a lot of safety critical systems.

Option D:

So think planes, trains, cars anything that moves fast and, weighs tons

Option D:

and can kill you type of thing.

Option D:

So none of that stuff should be running Linux.

Option D:

And it's a good thing that like the F16s don't run Linux because.

Option D:

They'd kill a lot more people than do today.

Option D:

so there's a lot of good things in it.

Option D:

But, touching on that design real quick, the whole premise is that instead having

Option D:

this monolithic kernel that does like everything, and if, you find fault and

Option D:

it just dies, the entire system dies.

Option D:

Micro kernels basically say, Hey if one system dies, it shouldn't kill

Option D:

like the other part of the system.

Option D:

You could say that Andrew actually won this debate because if you look at

Option D:

virtualization, I think Rosenblum, was one of the co-founders of VMware,

Option D:

said something like "virtualization was basically microkernels done right".

Option D:

So what's your take on "why Linux of all this family tree that

Option D:

we're looking at, why not BSD?"

Option D:

Why was Linux that became the defacto standard for running anything

Option D:

other than trains and planes?

Option D:

Well, I think, if you go back to first .com boom, late 90s

Option D:

right up until, 2001 basically...

Option D:

before that, if you wanted to build a stack, say you were, you're some

Option D:

startup or whatever, you either go to Microsoft you purchase a license, or

Option D:

you go to one of the proprietary Unix vendors, purchase a license, so some

Option D:

would be an obvious choice back then.

Option D:

Expensive, both the hardware and the software.

Option D:

And then you had this kind of upstart Linux was free.

Option D:

And so that started becoming a much easier choice to make back then.

Option D:

But so was FreeBSD, right?

Option D:

But they were, again, they were much further ahead.

Option D:

Because if we're saying like, 99 Linux has been around since 92.

Option D:

You had seven years of widespread distribution.

Option D:

In particular, Red Hat has been spreading the gospel for five, six years.

Option D:

So it's permeated everywhere at that point.

Option D:

Whereas the BSDs, they're still used in academia, and so forth, and obviously

Option D:

we have a few companies that are utilizing them for one reason or another.

Option D:

But it didn't have that distribution that Linux had at that time.

Option D:

when first .com bubble hit, it just exploded.

Option D:

Okay, so I think we're going to have to take a closer look at Linux and some

Option D:

of the interesting aspects of that.

Option D:

But before we do that, I just wanted to also mention that there

Option D:

is that little thing called Windows that's not shown on this example.

Option D:

I don't actually know all that much of the history of MSDOS and then

Option D:

the 9x kernels and the NT kernels.

Option D:

I do know that you can actually find MS-DOS source code on GitHub now,

Option D:

which is in a certain way, funny.

Option D:

Do you know the story of MS-DOS, how it came to be?

Option D:

Bill wrote a guy a check for it.

Option D:

yeah,

Option D:

that's that's pretty much what happened.

Option D:

Basically he promised IBM that he would have an operating system then was like

Option D:

"s**t, I don't have an operating system.

Option D:

Where can I get one?"

Option D:

Tried to buy one from DEC.

Option D:

The dude he went to ended up like, ghosting him and going on a flying

Option D:

tour or something like that.

Option D:

The story goes, so then he went and wrote another check, and basically,,

Option D:

the original version I think was called QDOS or Quick and Dirty Operating

Option D:

System or something like that, and it was rebranded at microsoft

Option D:

DOS, and that's where it started.

Option D:

The key thing was...

Option D:

you have to remember that, you're talking about like the 8086 family

Option D:

of processors, which were like these primitive machines compared

Option D:

to, the unixes that were running.

Option D:

There was a processor, a block of memory, and that's it.

Option D:

They were going to run one thing at a time.

Option D:

There was no kind of multi-processing, no kind of memory protection.

Option D:

So the whole reason you could take down a system or, you had "the blue screen

Option D:

of death" was, there was no distinction between kernel space and user space.

Option D:

And you could actually write to the memory addresses in the kernel

Option D:

space, and if you accidentally made a mistake and wrote something,

Option D:

boom, you just crashed your system.

Option D:

I think it used to be the norms all the way until 386 first included

Option D:

the concept of a protected mode.

Option D:

The interesting thing is the Macintosh app came first and the Macintosh in 1984.

Option D:

blew people's minds away.

Option D:

And windows tried to copy that and it was quite horrible

Option D:

until Windows 95 came along.

Option D:

But 95 was still based upon the DOS-based architecture, and there was

Option D:

another kernel that they made, which was Windows NT, which was for companies

Option D:

and server groups and things like that.

Option D:

And the Windows NT is what really morphed into Windows 2000 and the later

Option D:

version of Windows that we use today.

Option D:

I think that's where that kernel lineage goes.

Option D:

All right, so let's think a little bit now about what's interesting about Linux.

Option D:

What are the features and what are the parts of it that made it such a success

Option D:

because it's a HockeyStick show, so it would make sense to look at that.

Option D:

What's the killer features what's unique or maybe what's

Option D:

the most useful about Linux?

Option D:

Honestly, in my opinion, just from my own experience, it really comes back

Option D:

to the fact that it was there it could be used easily, even today, I still

Option D:

buy a license for Windows, right?

Option D:

So that's still a major blocker, especially when you start looking

Option D:

at, you believe a GitHub's quote of a hundred million developers in the world.

Option D:

I don't think I believe but it's definitely measured

Option D:

in the tens of millions.

Option D:

That's a really big deal.

Option D:

Okay, but let's give Linux a little bit of credit.

Option D:

It's got some nice features, right?

Option D:

It's a concurrent computing OS you can have things leveraging multiple cores.

Option D:

What else?

Option D:

It's got a virtual file system, right?

Option D:

That's built on top of the concrete implementations, which I think helped

Option D:

like on a normal day, you probably don't care what kind of underlying

Option D:

concrete file system you have.

Option D:

We've got, virtual memory, right?

Option D:

Memory management and paged virtual memory, which makes things easier

Option D:

from the developer point of view.

Option D:

It's pretty feature complete as well, right?

Option D:

You've got pretty much everything that you need right out of the box.

Option D:

And as we'll talk about virtualization and containers in a little bit that's

Option D:

probably also worth mentioning.

Option D:

It's got some interesting async io things, right?

Option D:

I think we were telling me about that Sachin.

Option D:

What you're describing is basically all the features of an

Option D:

operating system or things that an operating system needs to provide.

Option D:

And obviously Linux being one of the most popular ones, and being used

Option D:

everywhere has a somewhat unique take on some of those features.

Option D:

Probably the biggest thing going for Linux is portability.

Option D:

Because the source code was open, because there wasn't really one company behind

Option D:

it, there were a lot of people like, "oh, I need this, I'm gonna come up with

Option D:

this architecture or gonna come up with this, and I need an operating system.

Option D:

I can just take the Linux operating system and port it to this new

Option D:

architecture, this new CPU set".

Option D:

And that's an easy way of getting an operating system as opposed to good old

Option D:

days where, you know, if you came up with a new CPU or a new architecture, you would

Option D:

have to write an operating system for it.

Option D:

I think that probably had a huge effect of that.

Option D:

That's not to say, NetBSD for example, or FreeBSD even runs on a lot of different

Option D:

operating systems, but I think that had a huge reason for the success of

Option D:

Linux was the fact that it was open, which meant I could really port it to

Option D:

different operating systems that use it.

Option D:

It's feature complete.

Option D:

And if it wasn't feature complete, somebody would

Option D:

contribute those features to it.

Option D:

Having said that, there are a lot of people who would argue that, Linux has

Option D:

a huge case of NIH or "not invented here" syndrome in the sense that they

Option D:

try to reinvent the wheel and try to do it poorly, compared to borrowing

Option D:

from other places and other systems.

Option D:

One of the things we have right now is containers.

Option D:

And containers are an awesome thing.

Option D:

Just that containers are a complete myth.

Option D:

Containers don't exactly exist.

Option D:

There's no concept of a container inside the Linux kernel.

Option D:

You cannot say gimme a container.

Option D:

Containers are made up of namespace C groups capabilities and overlay file

Option D:

system and, a sprinkling of sauce here and there, but they're not really a nice

Option D:

virtualization technique or they're not a construct inside the kernel itself.

Option D:

Let's put it that way.

Option D:

Whereas, if you look at the BSDs, they had jails and might be a nicer implementation.

Option D:

I don't, I'm not sure if I can really say that, but they had

Option D:

a better way of looking at that

Option D:

I think again, this is one of the things that if you look back in history, you

Option D:

start to understand why it even happened.

Option D:

So obviously if you want to trace it all the way back, you got Bill

Option D:

Joy coming up with G Root, right?

Option D:

So that was like before I was even born, that goes way back.

Option D:

But if you go back to the 2000s, this is where I think containers,

Option D:

as we know them, really started.

Option D:

And that was because VMware and Google were butting heads a lot on especially

Option D:

going after employees and so forth.

Option D:

And Google wasn't trying to use any of VMware's software, but they wanted

Option D:

something that was very similar in scope.

Option D:

And so, Google started adding a lot of the support , to what we

Option D:

know as containers with namespace cgroups and things of that nature.

Option D:

They were the ones that came in and, start adding these features

Option D:

to get what would work for them.

Option D:

Now keep in mind they designed it because we're Google, we control everything

Option D:

and we can use it at our company.

Option D:

They weren't really designing it for the entire world at this point.

Option D:

And so that's where certain technical decisions were made that,

Option D:

guys like me might not agree with.

Option D:

But that's only because they weren't designing it for everything.

Option D:

They were just designing it for Google.

Option D:

That's actually a very long history.

Option D:

You'll see these features where something that we've been working on recently

Option D:

called user Managed Concurrency Groups.

Option D:

That's a feature that's been trying to get into mainline Linux for eight years now.

Option D:

And it comes from Google but for lots of different reasons

Option D:

it hasn't been merged in.

Option D:

And it's a very common scenario

Option D:

So if we do a quick rundown of the main things, right?

Option D:

You want to be able to contain the file system, so this is

Option D:

the chroot slash jails things.

Option D:

You want to be able to control the resources, right?

Option D:

We've got cgroups, we've got v1 and v2.

Option D:

Was that also influenced by Google, the cgroups addition?

Option D:

so g root, just to trace that that started off because , there was a

Option D:

desire to have a separate file system view for especially build artifacts.

Option D:

And then also back when, FTPs still regrettably heavily used, but back then

Option D:

that was also a way of isolating different users incoming folders and so forth.

Option D:

It was never designed with like, security in mind is what I should say

Option D:

And then we should probably do the honorable mention of Docker, that kind

Option D:

of packaged it together, the file image format leveraged copy on write type both

Option D:

file system and became a unicorn, right?

Option D:

With A few billion

Option D:

valuation

Option D:

twice.

Option D:

The first one burnt and crashed.

Option D:

I forgot what year it was.

Option D:

2018 or 2019.

Option D:

Something like that.

Option D:

They basically had to recap the cap table, and so everybody on was wiped out.

Option D:

They sold off a large port of the enterprise portion to Marantis, and then

Option D:

decided to refocus solely on the developer dev test desktop sort of experience.

Option D:

And then, over the past so many years now, they're a unicorn again, but the,

Option D:

yeah, the first one ended in a fireball

Option D:

I missed that bit entirely.

Option D:

Yeah.

Option D:

oh, yeah.

Option D:

Very cool.

Option D:

Okay.

Option D:

And then we've got all these other players that looked at it and said,

Option D:

okay well, so this is really cool, but not that hard to write a runtime.

Option D:

So we want to have our own runtime, we've got to runc, we had bunch of different

Option D:

projects from places like, what, Red Hat?

Option D:

We had the weirder one like gVisor from Google, that was a slightly

Option D:

different approach to that.

Option D:

So who controls the container runtime at the moment, is that

Option D:

CNCF, steering the runc development?

Option D:

Who's in power there?

Option D:

As you just mentioned there's no one runtime to roll them all, right?

Option D:

There's sets of standards that people are supposedly adhering to,

Option D:

but at the end of the day, you can go out and make your own standard.

Option D:

So it's with that XKCD comment, where we have seven standards.

Option D:

What do we do?

Option D:

We just go create our own.

Option D:

Yeah, The incredible thing is Kubernetes came along and killed quite of all the

Option D:

other, container clusteration systems that killed Mesos for a better term.

Option D:

Docker came up, saw Kubernetes being a thing, decided to build Docker Swarm.

Option D:

That never really took off.

Option D:

So Kubernetes killed them and as far as Kubernetes is concerned, they have

Option D:

the container runtime interface and that's all they really care about.

Option D:

So even though Container D does its own things and can manage a lot of

Option D:

different runtimes and support a lot of different features, the only one

Option D:

that, Kubernetes really cares about is the Container runtime interface.

Option D:

There's obviously, Creo or Cry Zero, I'm not quite sure what the pronunciation

Option D:

is from what I've heard of it, but that's, decided "okay, we are just

Option D:

going to support the runtime interface".

Option D:

So that's like the abstraction there.

Option D:

And then, behind the scenes, run C is using the Linux constructs

Option D:

and creating containers.

Option D:

And I think there are other people, that are doing their own thing.

Option D:

I know there's Firecracker on Amazon that creates a limited set of containers.

Option D:

I know there's like kata containers and there are all kinds of fancy stuff.

Option D:

And yeah, as long as you support the CRI interface, Kubernetes is happy and

Option D:

that what you do behind it is up to you.

Option D:

I'd be interested on your take on this, Ian.

Option D:

And I think Unikernels would fit nicely.

Option D:

Firecracker and gVisor were basically a response.

Option D:

I don't even want to call it a response, because they were created different

Option D:

but they're used as a response to the, " containers don't contain" argument.

Option D:

Firecracker basically spins up VMs, so it's more of a replacement

Option D:

for QMU than it is for Kubernetes.

Option D:

But people like fly.io use this and there's a few other companies that are

Option D:

starting to use it outside of Amazon.

Option D:

Firecracker basically trades runtime latency for boot time latency so

Option D:

they can boot faster because they got rid of some other things that

Option D:

they didn't think that they needed.

Option D:

But the uh, runtime suffers little performance penalty a little bit.

Option D:

And then gVisor has gone in a couple different directions.

Option D:

And I think they've made improvements since the last time I looked at it.

Option D:

But basically, gVisor also would isolate your program to give

Option D:

it a sandbox layer, so to speak.

Option D:

They used to be using KeyTrace, but if you have access to actual

Option D:

hardware you don't need to use that.

Option D:

There's other methods now, which is good because KeyTrace is

Option D:

incredibly slow in the way it works.

Option D:

I don't know of too many companies that have said that they're really

Option D:

using gVisor outside of Google but you do see quite a few companies raising

Option D:

their hands around Firecracker now

Option D:

So what's Firecracker using to actually run the VMs?

Option D:

Is that KVM under or hood?

Option D:

Yeah.

Option D:

So it uses KVM the same way QMU can use KVM 'cause KVM is the actual hypervisor

Option D:

functionality that Linux has to provide.

Option D:

So it's just like a lightweight rust interface that talks to KVM and a

Option D:

kind of a funny tidbit is that they actually stole this from Google.

Option D:

So Google had a project called CrossVM.

Option D:

And they basically forked that, rebranded it and produced Firecracker.

Option D:

And, now it's taken the life on its own.

Option D:

But it, was essentially a project they just took.

Option D:

we didn't really mention AWS so you talked a little bit about the VMware

Option D:

vs Google that story, then all a sudden we've got AWS joining the party

Option D:

and trying to make their own mark.

Option D:

What did they do like with the virtualization?

Option D:

That's a, interesting story because, again, in the mid 2000s you have VMware

Option D:

that's just starting to get good.

Option D:

VMware's first products were kind of dog shit.

Option D:

It didn't really work very well for the environment, the types of

Option D:

computers that were everywhere.

Option D:

This was like before we had threads, before we had SNP

Option D:

capabilities in commodity machines.

Option D:

They existed before, but commodity, like your average company.

Option D:

And so it took a few years for VMware to get out of the gate.

Option D:

But, 2003, 4 5, around that time period that's like when people are just like,

Option D:

"oh, this actually starts to make sense".

Option D:

And then just not even a year or two after that, Amazon took Zen from Citrix and they

Option D:

slapped an API on top of it, essentially.

Option D:

And that is what we call the cloud today.

Option D:

It's really virtualization with an API that was a major game changer.

Option D:

Yeah,

Option D:

so at the end of the day,

Option D:

where's openStack and all this

Option D:

so a lot of people think OpenStack's dead, but talk to any telco out there

Option D:

and seems like almost every major telco still heavily uses OpenStack.

Option D:

Any alternatives to OpenStack in terms of, free to use?

Option D:

I think it comes down to the size of an installation that you're trying to do.

Option D:

So if you have so much, that you really need, like APIs

Option D:

and you need full blown stack.

Option D:

So like a telco that might have hundreds or thousands of machines running it

Option D:

that's like where OpenStack might come in.

Option D:

But if you're only like maybe 5 or 10 boxes maybe a lot of people will use

Option D:

Proxmox or something like that instead,

Option D:

is kinda like a vSphere alternative.

Option D:

It's better to think about like how big of an installation you really

Option D:

have and where it makes sense.

Option D:

And then the whole, like why are you doing your own virtualization

Option D:

layer versus using the cloud because there's different decisions there

Option D:

so I think the conversation is naturally taking us into the unikernels and

Option D:

Ian's area of expertise, but before we do that, I learned a few weird

Option D:

words that I'm hoping maybe you can help me give some examples of.

Option D:

there are hybrid kernels and exokernels and multi kernels and ramp kernels.

Option D:

And I was wondering you ever heard of any real examples these things.

Option D:

And whether any of that is actually interesting because it sounded to me

Option D:

like a lot of that was a theoretical, "oh, it might be a good idea".

Option D:

But maybe separation kernels made sense to me in like the aviation

Option D:

scope or something like that.

Option D:

Do you have any interesting stories about those?

Option D:

Separation kernels are definitely still used, . Specifically with the

Option D:

Applications that you mentioned.

Option D:

This kind of dive dovetails into kind of the formally verified space.

Option D:

So when you're dealing with like aviation and trains and cars and, all that sort

Option D:

of stuff regulations come into play.

Option D:

And those regulations will sometimes have these really stringent,

Option D:

specifications where " Hey, this part needs to be formally verified.

Option D:

This needs to be, no bugs, yada, yada, yada".

Option D:

You'll see in like a modern day car, there's going to be like many different

Option D:

pieces of software running in car.

Option D:

And the stuff that's on your heads up display is going to be a completely

Option D:

different system than the one that deals with, other controls inside the car.

Option D:

In fact, you can see this play out in real life.

Option D:

There's a guy named Dan who runs this company called Greenhill Software,

Option D:

and so he sold a lot of this sort of software to DOD and organizations

Option D:

like that for the past 30 years.

Option D:

Just go search 'em on YouTube.

Option D:

He has all these videos where he bashes Elon Musk and Tesla

Option D:

for putting Linux in their cars.

Option D:

And he actually ran for governor in California just to try to kill Tesla.

Option D:

I think you bring a very interesting point, which is, I had a scary one,

Option D:

running Linux because half the time, we run into a problem of , what does,

Option D:

customer support or whatever tell you, switch it off, and switch it back on.

Option D:

And that seems to be our solution to everything.

Option D:

That's not a viable solution, if you're driving 70 miles on a highway and you're

Option D:

asked to switch something off and switch something back on, that's just not

Option D:

Or if you're in a 747 30k feet up in the air, probably don't

Option D:

wanna switch that off and on.

Option D:

And I think the big reason for that is back to the concept of state and

Option D:

to what extent do you understand state and can you reason about it?

Option D:

The idea is when a system first boots or when it comes up, you have some

Option D:

kind of indication of what the state is, what are your variables, what are

Option D:

your bits, what do they look like?

Option D:

But eventually as you start building more and more, reacting to the

Option D:

world more and more things happen.

Option D:

System processes are started, processes are stopped.

Option D:

They react to different changes.

Option D:

You eventually end up with a state and usually when you get a crash of some

Option D:

sort, it's because your system is in a state where you can't really reason about

Option D:

it, or you don't know how you got there.

Option D:

And the easiest solution is instead of working on it as, switch it

Option D:

back off and switch it back on.

Option D:

And I think this turns back in nicely into Unix when it came out it was just, I

Option D:

wouldn't say it was designed to be, but it was like, let's build a practical system.

Option D:

Whereas all the research that was happening in the universities at that time

Option D:

was along, how to build a correct system.

Option D:

And there was a crazy ton of work that went into how do we detect a

Option D:

deadlock and, can we ensure that there're not gonna be any deadlocks?

Option D:

And the whole Unix philosophy was "what's a deadlock like?", I'm gonna, be an

Option D:

ostrich, shove my head into the sand and say there's no such thing as a deadlock.

Option D:

And if there's a deadlock, you can just restart it.

Option D:

I think that's a really interesting contrast to make because.

Option D:

There's some systems out there, where you can't allocate new memory at runtime.

Option D:

Like it's outlawed.

Option D:

You just can't do it.

Option D:

Whatever memory you need, you have to have it before the system starts.

Option D:

So that's very different than I work in an office and I need a

Option D:

spreadsheet, you know it's v ery different system, design constraint.

Option D:

And I think it's just what a lot of people are exposed to.

Option D:

It's like a commercial versus a, consumer aspect, in an analogous way.

Option D:

There's just so many more people working in the office than,

Option D:

running a jet or something.

Option D:

Although I think it's not entirely true that there is no Linux on the an airplane

Option D:

because every time I fly there seems to be someone's tablet kind of crushes,

Option D:

and then they do this thing when they said, "oh, we're gonna go and restart

Option D:

it, it's gonna take about 15 minutes".

Option D:

And then they have to stop everybody's movies in the row

Option D:

and everybody's looking at you.

Option D:

"Oh yeah, it's because of you.

Option D:

You're the one with unlucky tablet", so I'm pretty sure that must be

Option D:

some kind of Android there, right?

Option D:

Heads up display versus the avionics.

Option D:

Yeah, I'm okay

Option D:

with, killing the entertainment every now and then, even though I

Option D:

don't think that's really acceptable.

Option D:

But, running Linux on tablets makes sense.

Option D:

Running it on the, controlling the flaps and the air faults of a plane.

Option D:

Hell no.

Option D:

Don't try to do that.

Option D:

So you mentioned Tesla.

Option D:

Do they actually run critical systems on Linux as well?

Option D:

I would imagine that they definitely have multiple systems.

Option D:

I do know that they do have Linux as a form of something inside.

Option D:

But there's different layers of security , or regulation that you have

Option D:

to conform to for different functions.

Option D:

When comes to things like cars.

Option D:

The other thing that Ian alluded to is, a lot of the systems that you run in cars

Option D:

are microcontrollers, and in the case of microcontrollers, when you're coding

Option D:

for them, you don't really have a lib C.

Option D:

There's no concept of a library, there's no concept of a mallock.

Option D:

You basically have a fixed, set of memory and you decide what

Option D:

each piece of memory is gonna be used for, and you stick to that.

Option D:

And it's a very different environment to what, , you might be used to

Option D:

if you're just programming and see on a standard system where

Option D:

you could, do a malock and a free.

Option D:

glibc just had a heap CVE issued for it.

Option D:

That's been in glibc for 20 some odd years now

Option D:

I heard that they found a bug and Q sort and

Option D:

yeah.

Option D:

Yeah.

Option D:

which was really incredible.

Option D:

And it was just using the fact that, your comparison operator should be

Option D:

transitive and if it's not transitive, you can actually exploit it.

Option D:

The fun thing of how they discovered this was actually, there was somebody was

Option D:

looking through old code from Solaris or something like that, and they were like,

Option D:

"this fixes the issue with transitive, with your comparative function not

Option D:

being transitive in while sorting", and they were like, "oh, that's a thing".

Option D:

And then they were like, "oh, glibc still has this bug because

Option D:

they never fixed it there.

Option D:

Right.

Option D:

I love the anecdotes like that, especially when it took 20 years to find a bug.

Option D:

Ian you mentioned twice already that writing an operating system is very hard.

Option D:

So why do you work on Unikernels that basically introduce a new operating

Option D:

system that you're also going to custom compile with all of your applications?

Option D:

Just to clarify when I say it's hard, what I mean is , it takes a

Option D:

lot of effort, it takes a lot of time.

Option D:

So given enough people and enough time you can make something.

Option D:

But if it's just one guy toying in his garage on the

Option D:

weekends, it's not gonna happen.

Option D:

You really do need to put some resources at it.

Option D:

I work on it mainly because I got sucked into it, I come from the security world

Option D:

and it was very clear to me coming from the security world, what the promise

Option D:

was as compared to like how we do things today and what kind of things that people

Option D:

do to mitigate security concerns today.

Option D:

Which me are just completely worthless.

Option D:

Scanning for a hack system or scanning for a system that's

Option D:

going to be hacked is just.

Option D:

It's crazy.

Option D:

crazy to me that's like how people do things today.

Option D:

It was very clear that , one of the main pain points is that the whole purpose

Option D:

a hacker is trying to break into your system is to run their code on it.

Option D:

It really has nothing to do with your code.

Option D:

That's just how they get into it.

Option D:

They find the hole or they use an exploit.

Option D:

That's just the doorway into the house.

Option D:

That's not why they're at your house to steal your stuff.

Option D:

want to run a crypto miner, they want to dump the database, they

Option D:

wanna do something of that nature.

Option D:

And that always involves running at least one, if not many different programs.

Option D:

And that was like one of the things.

Option D:

And then it's " oh, we get this performance boost" and it

Option D:

makes things easier and yada.

Option D:

That's what drew me into it.

Option D:

I guess, I think it would be really helpful if Ian, you could just go into

Option D:

a description of what exactly Unikernels are or what your, take on unikernels

Option D:

are and why they're so incredibly useful or, why are they so alluring to it?

Option D:

We 've talked about containers a little bit, but we haven't really described like,

Option D:

what's the distinction between, let's say a container and a virtualization and a

Option D:

vm, and what makes unikernel so awesome.

Option D:

I guess to start off with, I'll say that there's more than a handful

Option D:

of unikernels out there, and they're all extremely different.

Option D:

Some people might think that they're like different distros

Option D:

or something of the same thing?

Option D:

No, they're completely different.

Option D:

Some are focused on performance, some are focused on security, some

Option D:

are focused on specific use cases.

Option D:

Like maybe , they want to run a 5G stack.

Option D:

There's lots of different reasons why people are looking into this.

Option D:

At least from my perspective, I got interested because of

Option D:

the security side of things.

Option D:

And then I think if you talk to most of our users, I would say 80, 90% of

Option D:

'em just think they're easier to use.

Option D:

Like one command, you build an image, second command you spin it up on Google

Option D:

or Amazon, it takes tens of seconds.

Option D:

It's just easier to use than, say, Kubernetes.

Option D:

That's probably the major reason why our users do that.

Option D:

But to compare and contrast with containers, for instance.

Option D:

So containers, under Linux, A: they're running under Linux.

But B:

say you have five containers or whatever.

But B:

So again, in security last week there was a container breakout again.

But B:

What that means is somebody was able to escape the container and once they

But B:

do that, they can do whatever the hell they want on that host system, including

But B:

attacking other containers, because now they're in that control domain.

But B:

One of the really big problems from a security point of view that I have

But B:

with Kubernetes is that it extrapolates this management control system from

But B:

one host over many different hosts.

But B:

So if you do this container breakout, not only do you have access to that one

But B:

instance that you're on, you probably have access to the entire freaking

But B:

network that Kubernetes spawns on.

But B:

To me, that's a different security threat model than having, say, one

But B:

Linux VM and another Linux vm because, sure, maybe I find something where

But B:

I can break out into the hypervisor.

But B:

But that's a very different type of security vulnerability.

But B:

And it does not happen as much as some people think that it might if it

But B:

did, public cloud would not be a thing because that is public cloud, right?

But B:

That's why, to me, it's like the gold standard, virtualization.

But B:

Literally has hardware backed extensions built into the chip

But B:

to provide this sort of security.

But B:

So we talked about Mmus earlier.

But B:

It's the same sort of hardware-backed guarantee, which containers don't have.

But B:

As soon as you find that exploit like we did last week it's fair game.

But B:

So that's a huge major difference.

But B:

The other thing is like , there's lots of other differences.

But B:

But with the unikernel, essentially what we do is we just bundle the

But B:

kernel portion with the application into one virtual machine and then

But B:

spawn it Like I said, different projects do this very differently.

But B:

Like Unicraft, you pick the hundreds of different libraries that you want to

But B:

include and so they can produce very small images, but then you need that expertise

But B:

on figuring out which libraries you want.

But B:

I don't think a lot of developers have the time or the inclination to do that.

But B:

So we have a different approach where we just load raw ELF binaries which I think,

But B:

again, just from our earlier users, I think most people want that as a default.

But B:

There's lots of different techniques and ways of doing these.

But B:

So can you walk us through what happens?

But B:

I've got, let's say some code written in let's be hipster and say Go what

But B:

needs to happen to that code so that it becomes its own self-contained

But B:

VM with everything it needs.

But B:

Because you gave the example of whipping out and TCP/IP

But B:

stack, that's your problem now.

But B:

How does that work?

But B:

. At least for our point of view we have tooling like, like ops, which is

But B:

a build tool, open source, ops.city.

But B:

Essentially if you're just playing around locally on your laptop, you can do ops,

But B:

run whatever your go binary is, and it'll basically create a disc image on the fly.

But B:

And so that disc image will have your binary and then, whatever else it needs.

But B:

If you're on a Mac, that file system's gonna have five files on it in total.

But B:

And then it just boots it up instantly.

But B:

So that's like a local dev mode, but you could do like a ops image

But B:

create and it'll create a disc image.

But B:

You can then upload that to Google or Amazon, or any hypervisor,

But B:

any cloud, and use it as such.

But B:

When it comes to things like knowing what to include or what not to

But B:

include we don't think our users really need extreme specialization and

But B:

definitely nobody's really asked for it.

But B:

Nobody's asking us: "Hey, can I use L wip?

But B:

Or small TCP?".

But B:

Nobody asks us that.

But B:

And it's crazy to think that somebody would want that either.

But B:

Because if you look at like LWP, for instance, which is the

But B:

networking stack we forked and it is a complete fork by the way.

But B:

We've added so much different support to it that you won't find in the upstream

But B:

because they never, a dead project.

But B:

So like for instance there's things like IPV six for DHCP.

But B:

Why do we have that?

But B:

'cause customer asked for

But B:

there's support like SYN flooding.

But B:

If you go use LWP on savannah.org the mainline branch that totally

But B:

susceptible to SYN flooding.

But B:

So any project that uses LWP out there, can take you down immediately.

But B:

SYN flooding is something that was dealt with in 1998, so keep that in mind.

But B:

There's lots of these little tiny details that you might not think

But B:

of because it's not something that developers do day to day.

But B:

So rolling it back to the original question of what do we think you need?

But B:

Don't need.

But B:

It's a lot more complicated.

But B:

Some people think that a unikernel is somehow not an operating system.

But B:

It most definitely is.

But B:

It's just a different type of architecture of a system.

But B:

It's not like where we take your application and we just

But B:

link a couple things to it.

But B:

That's not how it works.

But B:

It's more of we take your application and we put it inside

But B:

this nice little architecture and then, let it do its thing.

But B:

Let's say you have an application that does asynchronous I/O and

But B:

it's using for the lack of a better thing, it, they wrote it for Linux.

But B:

So it's, based on epoll.

But B:

So are you gonna actually do you have an implementation of the epoll system calls

But B:

or is that how you're operating on it?

But B:

Essentially what you'll find in Nanos, which is our unikernel

But B:

implementation is you'll find more or less a lot of the same sort of stuff.

But B:

So I don't wanna say we have a one-to-one epoll implementation,

But B:

because epoll is actually pretty large.

But B:

And there's lots of like random flags and stuff, so

But B:

what I was gonna ask, like,

But B:

So

But B:

implement the epoll bugs in your

But B:

in your code because

But B:

one shot, there could be edge triggered, there could be there's

But B:

epoll is actually a beast.

But B:

one reason why earlier on it got a lot of flack compared to kqueue from BSD.

But B:

There might be not a one-to-one thing and we deal with it whenever it comes up.

But B:

But the cool thing is there's a lot of software that uses epoll, right?

But B:

Because we have so many people using it, like bugs show up, they get fixed.

But B:

A lot of people , are bewildered that Linux doesn't really

But B:

have a default test suite.

But B:

There's test projects out there, but Linux, the project doesn't have

But B:

own, fully functional test suite.

But B:

It boggles people's minds when they hear this, but the answer is like, well,

But B:

linux is, go look at the uh, git tree.

But B:

There's like thousands of commits every single day.

But B:

So it's, they get to that because it's just heavily in use.

But B:

So are your clients primarily driven by the security aspect of that?

But B:

No, so early on, again, coming from that world I thought

But B:

that would be a big driver.

But B:

What I found out that, a lot of security buyers, they're not the ones that

But B:

would actually use this software.

But B:

Our users are SREs, Sysadmins and DevOps, random developers,

But B:

like people day to day using.

But B:

And so they're not really a buyer, like a security buyer.

But B:

They're buying stuff for their SOC.

But B:

And so, the scanning software, it's a completely different buying experience.

But B:

Most of our users, again, are using it because they just find it easier.

But B:

Like they have a service that they wanna put up.

But B:

We have a lot of rust users, for instance.

But B:

And they build the rest image.

But B:

They spin it up and boom, it's working.

But B:

They to mess with Kubernetes.

But B:

don't to do anything.

But B:

It just.

But B:

sits there and works.

But B:

I think ease of use is a major driver for us today, that used to

But B:

a main complaint for Union kernels was they weren't easy to use.

But B:

So

But B:

is the performance a major consideration?

But B:

What's the like real world difference between compiling the

But B:

same code and running this as container running as a Unikernel?

But B:

Yea, in terms of, for example, your clients moving onto your platform, do they

But B:

see a savings in terms of actual dollars?

But B:

What they see that respect?

But B:

It depends upon which user is using what.

But B:

If it's like a single developer type of thing the ease of use is definitely a huge

But B:

driver for them, it just saves them time.

But B:

A lot of the DevOps toil, if you will, just goes out the window because again,

But B:

like you can't SSH into these things.

But B:

You can't sudo apt-get install whatever want, which accidentally

But B:

installed random library, which a vulnerability, which, goes on, right?

But B:

A lot of that just goes out the window.

But B:

And it has that kind of encapsulation, that containers bring, but it doesn't have

But B:

all the kind of toil that comes with that.

But B:

We do have some bigger clients that do have much larger installations,

But B:

and so for them, security can be an issue depending on who's using it.

But B:

It, it really depends on type of user.

But B:

People haven't really dived deep into the performance aspects of it yet.

But B:

But I would expect I expect that to be a thing in the future.

But B:

So can you use that out of the box?

But B:

I know you said Kubernetes is terrible and there many reasons we can agree with that.

But B:

A little bit of an overkill a lot people, but can you just plug that as a

But B:

replacement for a container runtime there?

But B:

it depends.

But B:

I would say there's a surprisingly large amount of software that does just run out

But B:

of box, like literally ops run my program.

But B:

So your Go example is a perfect example.

But B:

If you have Go or Rust or something like that, it's almost a guarantee

But B:

it's gonna run out of the box.

But B:

Where it gets more complicated it's, say, you're using Python and some

But B:

hot new ML framework, for instance.

But B:

Okay, so how do we build that application?

But B:

These applications say it's some Python ML framework.

But B:

The actual program that we're running is the Python interpreter, and then

But B:

there's like probably a gig worth of crap that this application has, right?

But B:

And so these are like random shared libraries entire folders

But B:

filled with Python code that I don't know what it does.

But B:

You have the models that it pulls down.

But B:

Those are tens of megabytes or hundreds of megabytes in size.

But B:

So these things can, they can be big, right?

But B:

And what you'll find is, especially in Python and Ruby people have

But B:

implemented convenience commands.

But B:

So they, run some command, but that spawns like five different interpreters

But B:

that each run their own command.

But B:

And so in cases like that, we do have to go in and we have to figure out,

But B:

"okay, what's the final invocation that they're trying to run?"

But B:

What's the actual program that they're running here, because it calls like five

But B:

different, calls Python or whatever.

But B:

And so in that case, we'll either throw in a patch or , we'll figure out what that

But B:

is, and then we'll create what we call a package, which is essentially everything

But B:

that we know we want on the file system, arguments, the environment variables.

But B:

That's another thing that gets done is a bunch of environment VARs will get set

But B:

and you don't really know what they are.

But B:

And then whatever they're trying to run.

But B:

We'll create that package and then we'll give that to the user

But B:

and they can use that instead.

But B:

So that's like probably those cases.

But B:

a very extreme case is Postgres.

But B:

So Postgres is one of those.

But B:

System five IPC, poster child type of situations.

But B:

It makes use of everything that we don't like in Unikernels.

But B:

It has multiple processes, huge offender number one.

But B:

It has shared memory, so shared memory exists in almost all cases.

But B:

It means like you have two processes talking to each other.

But B:

It has, semaphores the signal amongst different processes.

But B:

It has a lot of stuff.

But B:

It basically was a re-implementation of ingress from the early 80s

But B:

around the time I was born.

But B:

And then in the 90s it got rebirthed for the fifth time as Postgres, still using

But B:

the exact same sort of programming scheme.

But B:

So anyways that's an example of something that's actually really

But B:

difficult to port, but guess what?

But B:

We ported it.

But B:

So like now we have a multi-threaded Postgres, which didn't exist before.

But B:

This is a topic that actually came up on the Postgres mailling list again.

But B:

I guess it's been debated before, but last year there was another

But B:

kind of debate about "hey, we should do a multi-threaded Postgres.

But B:

'cause now there's all these different Postgres vendors".

But B:

And all of 'em, a lot of the vendors are basically saying, okay, it's

But B:

2024 threads are obviously faster, obviously cheaper than running processes.

But B:

And their customers have very large data sets, so processes get really crappy.

But B:

If you start getting heaps of like 30 gigs and stuff and you have to

But B:

fork that, now it starts taking time.

But B:

Multi-processing doesn't scale very well.

But B:

Especially , once you get like high memory usage.

But B:

What's the uptake?

But B:

What's the kind of market penetration of Unikernels at the moment?

But B:

I know about the fly.io, but there're small potatoes still.

But B:

Fly uses Firecracker.

But B:

They don't do unikernels today.

But B:

So Firecracker and the proponents of Firecracker will

But B:

throw out MicroVM as a term.

But B:

And essentially it's just a container that runs in Firecracker.

But B:

They're not the only platform player out there that's doing that.

But B:

There's a few others like I railway I think is one of 'em and some others.

But B:

I think outside of those platforms, Firecracker still

But B:

doesn't have a ton of stuff.

But B:

Obviously, Unikernels are way less than Firecracker.

But B:

One thing all throughout there is that you can run Unikernels inside

But B:

Firecracker, because again, Firecracker is just the machine monitor.

But B:

It's the host layer.

But B:

It's not the guest layer.

But B:

But yeah we have our users, our customers.

But B:

There's a few other Unikernel implementations out there that people use.

But B:

But by and large, I think it's still very hidden from your average developer.

But B:

You might see some comments on Hacker News where people were like.

But B:

" What's the state of this?"

But B:

But the reality is we have stats on like people who come to our page

But B:

and then people who click download.

But B:

So like, it's surprising to see what a large difference that is.

But B:

Put it that way.

But B:

So where do you see it going?

But B:

Do you think there's a niche where the Unikernels are just going to dominate?

But B:

Is that something that is going to stay niche?

But B:

What will have to happen for it get like a wider adoption?

But B:

In terms of like widespread adoption, think there's certain trends

But B:

that push it to more adoption.

But B:

, like some people think that have to just have a complete huge category to win.

But B:

And I, I don't know if I really agree with that.

But B:

I'm happy with having enough of a ecosystem and a space to play

But B:

in, but yeah, obviously security's a huge driving force, cost.

But B:

You hear about cloud re appropriation and so forth nowadays.

But B:

What is it?

But B:

DHH with Basecamp, he's all talking about screw the cloud.

But B:

So there's a little bit of that sentiment going around.

But B:

At least here in the US the economy combined with tech in general going

But B:

through a downturn I think that's gonna put a lot of pressure on costs.

But B:

So cost is gonna come into view as well.

But B:

There's lots of different like non-technical trends that converge,

But B:

that can help push adoption.

But B:

Our focus has always been to make it as dead simple as possible, to

But B:

the extent that made like two desktop clients last one Mac and one for

But B:

Windows, to where, like we don't even expect users jump into a shell.

But B:

So there's one thing that I would like you to clarify, because when

But B:

you got a bunch of containers paid for vm typically, right?

But B:

And then inside of that, you've got a certain amount of resources and you're

But B:

going to be able to a certain extent.

But B:

For these resources to be shared between the containers.

But B:

And this is often cited as a kind of cost saving effect.

But B:

Obviously there is the side effect that, that they all try to use that

But B:

resource they won't be able to and they're gonna get killed and restarted.

But B:

For a unikernel it's going to have an allocated static amount of resources

But B:

because it's a vm like the other one.

But B:

So does it mean that you're relying on the VM hypervisor ways saving the resources

But B:

like ballooning and stuff like that?

But B:

Or is there anything more advanced that can do when you've got like this small

But B:

VMs with unikernels with single processes?

But B:

I think it's just a different way of thinking at the end of the day.

But B:

So yeah, people will bring up like bin packing, we're like,

But B:

oh, I couldn't stuff, all these containers on one host and so forth.

But B:

What we try to challenge people to do is, think about what resources

But B:

does your application actually need.

But B:

If you have a website that needs 20 containers, but you're on, I don't

But B:

know, 2x large or whatever does it make sense to have 20 containers?

But B:

So that's the thinking that we throw out there.

But B:

If you have a EC2 small, that can withstand all this traffic because

But B:

it's just a little go web server.

But B:

Maybe that's all you need.

But B:

Maybe you don't need 20 different services.

But B:

And so part of this comes from I guess all the way back in 2014, 2015 where people

But B:

start pushing microservices and so forth.

But B:

Some people took that as cue to carve up what could be one app

But B:

into like many different things for scalability reasons, but.

But B:

We push back a little bit on that and say " Hey, like maybe this should

But B:

only be using one VM begin with and therefore maybe it only be one app".

But B:

Now if you hit RAM limit or CPU limit or whatever, then sure throw

But B:

it behind a load balancer, or maybe have a language that does threads or

But B:

whatever and you can vertically scale.

But B:

That's like how we respond to that, if that makes sense.

But B:

It does, although it doesn't help with the, from my experience, it's very hard

But B:

to get people to agree that they need an amount of resource because they somehow

But B:

expect to be able to spike get these resources when they need them, and then

But B:

not have them, and not pay when they're

But B:

yeah,

But B:

not

But B:

Yeah, on that note ops for instance, has support to deploy these

But B:

things into auto scaling groups.

But B:

So if you like that sort of auto scaling where, you start generating

But B:

errors or you hit a certain expected load, you can set auto scaling

But B:

groups to scale dynamically on that.

But B:

That works on both Amazon and Google.

But B:

I think it's one of the arguments where people said Kubernetes is overkill

But B:

for the vast majority of people.

But B:

And if you did have auto skilling groups, you can't do it.

But B:

And to the extent in which, yes, you are running on a hypervisor, but , you can't

But B:

over provision resources on a hypervisor.

But B:

So there's really nothing stopping you from doing that.

But B:

Now as long as, you're only paying the cost for the resources that

But B:

you're actually using and not paying for, the entire thing

But B:

that you've reserved, that's fine.

But B:

Or at least in my opinion, that's fine.

But B:

So it's just, where, how are you paying for it?

But B:

And are you bright provisioned for whatever you're trying to do?

But B:

Yeah,

But B:

So is there an inflection a HockeyStick moment for unikernels where suddenly

But B:

something clicks and all of a sudden the adoption goes way higher.

But B:

Is there anything like that you can think of?

But B:

What would to happen?

But B:

there's these other non-technical trends at play, and I think, one of those might

But B:

be, what actually pushes things forward.

But B:

Some people like to talk about this what do you call Killer app.

But B:

I don't believe in that.

But B:

I that's a, naive to put things.

But B:

'cause honestly, we already have killer apps, right?

But B:

It's not, that's not the situation.

But B:

A, there needs to be a lot of awareness that's still very low.

But B:

And B, there needs to be that non-technical trend I've talked

But B:

about, where enough people start linking those together.

But B:

To a certain extent, I also wonder to what a, I believe computer scientists

But B:

or programmers or developers are like huge fashionistas and they

But B:

always try to run to whatever the latest fashion trend is.

But B:

So if Google starts doing like containerization or starts

But B:

doing, Kubernetes, everybody wants to do Kubernetes.

But B:

If Amazon, or one of the big cloud providers says, we want

But B:

to do X and this is the way we are gonna run our own systems.

But B:

Everybody wants to do.

But B:

Run their system.

But B:

So if eventually you just need one of the big cloud providers to

But B:

say, "oh yeah, we're gonna support native virtualization, and this is

But B:

the way we're running our systems".

But B:

And I think it might be that everybody does, starts doing

But B:

it at that point in time.

But B:

Yeah.

But B:

And I think that can happen too, by the way.

But B:

Some people wonder why we don't have our own cloud offering type thing.

But B:

I have two answers that.

But B:

One is like a lot of our users think it's good enough.

But B:

We're better than enough on, the existing clouds, but b like I could easily see

But B:

somebody like Amazon coming in and saying, "Hey, we're gonna tweak this knob here

But B:

and this knob here, and we're gonna make it like an even better environment

But B:

run things in what exists today".

But B:

So they've got Lambda, but Lambda has all these limitations.

But B:

We're going to remove some of these limitations and

But B:

make a unikernel environment.

But B:

I could easily see that happening.

But B:

Did you try to work with some cloud vendors roll out as a feature?

But B:

Some symbiosis.

But B:

no cloud vendor is going to design something just for us.

But B:

We have contacts for lots of the different clouds and, there's different

But B:

paths that different vendors take.

But B:

Some of these vendors, they're also responding to what they see as fashion.

But B:

So like.

But B:

WASM has a little bit of that fashion, so to speak today.

But B:

And you have various vendors creating environments for things like that or doing

But B:

different takes on, like Microsoft has their thing coming that they mentioned

But B:

All right guys.

But B:

So for anybody who has learned a little bit here and wants to go and

But B:

discover some more, what kind of resources should we recommend them?

But B:

Any books, any the videos that are worth it?

But B:

We'll put the links in the show notes.

But B:

Would definitely put the link to , "Linux is obsolete".

But B:

What else would you recommend to extend this discussion?

But B:

if anybody wants to check out the open source tools that we have,

But B:

nanos.org, which is Kernel and ops.city, which is a build tool.

But B:

those have extensive documentation and videos and a YouTube channel with

But B:

a bunch of tutorials and stuff on it.

But B:

Our tech blog, if you like, nitty gritty kind technical stuff.

But B:

There is another podcast called BSD now that I think I've learned

But B:

quite a bit from at times.

But B:

There's always Wikipedia as long as you take it with a grain of salt.

But B:

There's some Wikipedia articles that are really good.

But B:

FreeBSD comes with the FreeBSD handbook, which is quite amazing.

But B:

And then they're obviously Linux man pages, so if you're gonna use the

But B:

feature, the first place to check.

But B:

I know most people would Google it, the manual pages are still

But B:

really good If you want to.

But B:

Look at things and look at, what the trade offs are or sample code.

But B:

Quite a lot of manual pages actually come with sample code that you can

But B:

copy, paste and use, and you don't really need to go to Stack Overflow.

But B:

You can go to the source.

But B:

And for anybody wants to maybe learn the basics operating systems designs, is

But B:

it worth going and playing with Minix?

But B:

think they had a recent release.

But B:

Actually.

But B:

What I would suggest is that most of the books are older and.

But B:

A little bit too verbose in my opinion, but there's one called OS

But B:

in three Easy Steps, and I think it's out of forgot the researcher's

But B:

names, but it's out of Wisconsin.

But B:

we'll find it.

But B:

I found that book to be extremely worthy and extensive.

But B:

And easy to read.

Next Episode All Episodes

Listen for free

Show artwork for HockeyStick Show

About the Podcast

HockeyStick Show
Breakthroughs in tech, business and performance
Explore the moments leading to exponential growth in technology, business, science and more.

About your host

Profile picture for Miko Pawlikowski

Miko Pawlikowski