lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

710
hpr_transcripts/hpr2269.txt Normal file
View File

@@ -0,0 +1,710 @@
Episode: 2269
Title: HPR2269: Chocolate Milk
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2269/hpr2269.mp3
Transcribed: 2025-10-19 00:40:48
---
This is HBR Episode 2269 entitled Chocolate Milk.
It is posted my first time postman on and in about 42 minutes long and carrying a clean
flag.
The summary is a sample show of the Nixon podcast, Adam's story, Milky Chocolate, Unicomp,
and Plan 9.
This episode of HBR is brought to you by An Honest Host.com.
With 15% discount on all shared hosting with the offer code HBR15, that's HBR15.
Better web hosting that's honest and fair at An Honest Host.com.
And this episode will discuss with Adam about three things, Unicomp, Plan 9, and Chocolate
Milk.
The M faces of the discussion is on Plan 9, an operating system that intrigues many and
the Unics real.
Plan 9 has a deep, two-way relation or connection with Unics, both as being inspired by it and
by inspiring it.
And we also took the liberty to discuss other topics for the leisure and enjoyment of
the listener.
And I was surprised by how composed, calm, and serious Adam was from my small previous
encounter with him.
I thought he would be different, but my assumptions were wrong, don't judge others.
He knows his subjects to the core and is truly passionate about them.
I've learned quite a lot during this podcast and here we go.
I'm VNAM and the company of Adam slash APK and you're listening to the Nixers podcast.
So who's this Adam slash APK guy?
Which one do you prefer?
Adam or APK?
Adam, I guess.
He doesn't really have any preference, but Adam's my name, so.
Why do you switch to APK instead of APK?
I don't know, I got bored and I think APK is like a bit more Unix-y, you know, like
Dennis Richie used DMR and then I guess Ken used Ken, but that's because it's three
letters.
I don't know, I got bored of Adam slash his name.
He's an infamous or famous forums member that is quite eccentric.
He's most noticeable for his true love of Unicompan Plan 9.
And one day on IRC he even went on Howard's epic story telling of the Plan 9 history.
And you can find the story log and the show notes if it interests you.
Let's start with Unicompan, which is a mechanical keyboard.
And for those who don't know mechanical keyboards are popular and the computing word in general.
Especially with Unix users, as they tend to have more textual interface and spend most
of the time typing.
There's also a lot of keyboard layouts and keyboards where they remove many keys, 10 key
less, 10% less.
Yeah, let's, how about the Unicompan first?
I think the Unicompan needs you want to talk about, not just the Unicompan, but what
I do with the Unicompan, I guess, so.
In my knowledge, the Unicompan is like this, not so old company, but like in the 90s
and they have this infamous IBM model M, where it has the sort of buckling string, versus
a sort of tube inside and you have the spring doing a sort of clicky sound.
It's sort of like different than the Cherry MX series.
So how would you compare it to the Cherry MX, and what do you have to say about that Unicompan?
Yeah, well, so yeah, you got it pretty, down pretty well.
The Unicompan is like the mechanical, or not necessary Unicompan, but the buckling
screen is like the mechanical, the mechanical, right?
It's super loud, super clacky, it uses like an actual mod of spring and all the keys
in the incident.
And the Cherry keys, the Cherry switches are a little bit more sophisticated.
They're designed specifically for a certain type of tactile response and audio, like
in your auto feedback, while the buckling spring is sort of this like raw key switch that
was like used way back in a day.
And so the Unicom, it's sort of like an emulation of the model M, the IBM model M, which is
a legendary mechanical keyboard in the community.
So it does feel that I'm amazing, that phenomenal when you click it, I mean, you have other mechanical
keyboards.
How would you compare the feel?
Is it like between red and blue or between transparent or white keycaps?
I don't know.
I would probably, if we're talking about like the pair of some between Cherry and the buckling
screen, I'd have to go with green switches, Cherry of screen switches, which are, I think,
I think if I remember correctly, the green switch is the like the lattice switch that Cherry
manufactures.
And it's also the one that requires the most force to get to the actuation point because
the buckling spring.
I mean, you got to have, it takes some strength, it takes some stamina to use the buckling
spring cord.
It's not easy to push down on, it's not quiet.
So the Cherry of screen, and I actually have a green board, do you feel like you're splitting
in half the spring or something?
It's a very hard question, I don't know.
Yeah, so the spring, so the way it works inside the spring is the spring, so it gets compacted
down.
And then it kind of works a little bit like a cherry, and then there's a little piece
of plastic with like a hook on it or so.
And I guess there's more like two, and I think about it in the buckling spring.
And so the spring gets pushed down kind of, you know, tilted a bit, depending on the
key switch, like the letters and the numbers are smaller than the space bar going on.
And so that's not the different, but in general, it does take a lot of strength to push down.
I mean, it's just a key switch that doesn't take like noticeable strength, but if you're
doing like rubber dome typing and you switch to a buckling spring, you're going to notice
some serious difference and actuation point, and I don't think I can like that.
Do they still manufacture them?
Oh, yeah, yeah.
Yeah, the unicorn.
I mean, the whole point, I think, behind a new kind of, is sort of like the revival
of the buckling spring keyboard, you know, because they're kind of hard to come across.
These days, if you're finding a buckling spring, it's not a new comp, it's probably some
like old, old 30 year old IBM, you know, bulky board from EAs yourself.
So I got it.
I got it on sale, actually.
A while ago, it was about $100 or so, pretty expensive, in most of them are.
Well, $100 is not that expensive for a mechanical keyboard.
Yeah, I think you would agree.
I would agree with that.
I would.
But I think, you know, a lot of people, like when they first came in, they can't keep
boards.
They see the price tags on some of them, and they just kind of like their jaws drop, you
know, like, how could a keyboard be this much?
Compared to the cheap ones you have on the, or any, the OEM, like HP Dell keyboard, which
are like, you know, 20 bucks or so.
And I think you remember very well what I did as a result of purchasing that keyboard.
I was standing to forums about it.
You did.
Yeah.
But I still, I did leave like two spreads on the forum because you were happy with that
thing.
Right.
Yeah.
I didn't dedicate a few threads just for the Unicop and I remember correctly that that
was all the than me getting banned from it for like a week or so by you.
Because all I do is just post stupid shit all over the forum, but yeah, I love Unicop
man.
It's a good keyboard.
Okay.
So now, back on the Unic's topic, does it have any relation here, the sort of IBM model
with Unics directly, like, was it used on PDP one?
I think not because it's two of you.
Yeah.
It's not that old.
It's probably probably worked towards the 80s.
So during the time we're at a class terminals, we're the, we're the norm.
And of course, in the 80s, we did see, you know, start of a monochrome displays and
even call displays in the mid 80s.
The IBM model piece, the idea model in, I don't have a lot of knowledge on it myself.
It was soon to be fairly standard with the, with the like high-end computer users, you
know, people who did computing for a living, although, although back in the 80s and back
in that day, when you had, you know, like serial ports and you had the terminal connect
into a mainframe, you had really the terminal was sort of like connected.
To the keyboard, you know, in most cases, like a lot of deck terminals and things like
that, the terminal and the keyboard were kind of all one big unit, you know.
And then when the personal computer came along, that's when you saw, like, the keyboard
been split up with the monitor and then the actual computer, you know, master, depending
on my keyboard computer you got.
I think it did make sense to have it in one unit because the terminal was the endpoint
of the CPU because the CPU was somewhere else.
It was the processing unit somewhere else and you just had the thin client, the, yeah,
the end output and then came the personal computer with the peripherals and you can plug
stuff around and then it came, came to, to be unplugged from the main machine, right,
right.
Yeah.
Okay.
So, yeah, you have anything to add for the unique comp, obviously, you have phrases and
that.
Oh, yes.
It's a good keyboard.
Yeah.
If you can get your hands on one, even if you can just, like, touch one, see what it's
got, because buckling springs are different beasts compared to this chair switch, which
is an Alps and topper or something like that.
That was a deep, passionate view on Unicom keyboards.
So Unicom were really distinct by the buckling string, historically go along with the professional
computing on terminals and the advent of personal computing.
They have their plays, more or less, in the Unix history.
Now, let's touch another topic that surrounds and embraces Unix.
Plan 9.
Let's go for the discussion with our favorite Plan 9 expert.
Let's move on to your favorite topic.
Plan 9.
Plan 9.
Okay.
So, I don't know that much about Plan 9.
I did my research this week and I did try it a bit on a France machine, a virtual machine,
that's really full and strong on the hardware itself, because from what I know, it doesn't
have really that big of a support for hardware.
Right.
Anyway, from what I know, it was made by the same people that were working on Unix.
It was inspired by Unix, but it's not Unix, it's just inspired by it.
So it's done from scratch, totally from scratch, with ideas from the people who were working
on Unix.
Right.
Many years working on Unix and then using those operating system knowledge to build something
completely new, they took those ideas and still integrated some tools that are Unix
like, but they read it them from scratch.
They took the concept of pipe over and over again.
There is no root, there's per process, namespace, per user access, there's something, there's
total integration with the network and a lot, a lot of cool stuff, like Unicode, and
it has a built-in graphical environment, etc, etc.
So that's really a general, generic overview of the thing and I'm not really knowledgeable
about little details, but what would be like for someone who knows Linux or BSD or Solaris
or the newest kind of Unix, what would be your definition like in two sentences or one
sentence about Plan 9, like you would explain to them what's Plan 9.
If I had to describe Plan 9 in one sentence or a couple sentences, I would say, first I
would say everything's a file, like everything is a file, everything is a file, if you think
like it's not a file, you're probably wrong and the second thing would be it is the
true successor to Unix.
Nowadays, it's probably the most obscure thing out there operating system wise, but historically
speaking, it was the successor to Unix, it was supposed to be relative to purposes, Unix
version 2.0.
So yeah, I would probably have to summarize it with those who said this is everything's
a file, and it's the true successor to Unix.
Okay, let's dig on that point that everything is a file.
From what I know, they have something that is called a union directories and then namespace
and they don't have really a difference between local machine and remote machines.
How does that happen?
What do you know on that level?
Did you try it?
Did you do a network or what do you know about it?
Yeah, a couple of years ago, I actually managed to get a small cluster of Plan 9 machines
working.
I had about three or four ANOVO's dig centers, they're really small, that's copyc's, I would
never have been used in Ethernet.
I installed the base distribution of Plan 9, the one that came out of Bell Labs, I installed
it on all of those, and I wasn't really trying to do anything practical with it, I was just
trying to learn how to network the machines together because it was built, this is the most
built to be used on not just one machine, but multiple machines over a network.
What I did was I signed different rules to different servers, and in Plan 9, I remember
quite a bit, I think there's three different types of servers, I guess four technically.
You have a CPU server, which does a lot of the computation and processing.
You have an authentication server, which I think the KC users and services on the cluster.
You have a hard drive storage server, which has a bulk progress base, and then you finally
have all your terminals, your small fan clients.
Connecting to those machines.
The system was designed in a way that would allow the user to access all the resources from
the CPU server and the hardware server, the storage server, and authentication server, and
they presented to them in a way that made it seem like all those resources were on the
same machine, and that was multiplexed to all the terminals on the network, so every
single user would have the same kind of resource pool to pull from.
So I did that with about fear for IBM, or not IBM, Lenovo think centers.
It was a pretty crappy design on my part, because the computers were bad, but I did get
to like my hands dirty with it and whatnot, and it was pretty cool.
Yes, so from my level.
That's impressive.
Yeah, from my level, that's the networking part of it, you know.
Okay, so you said there's this, you can assign to a machine like the CPU role and the storage
role, et cetera, from what I know, there's no root user on Plan 9.
It's completely renewed the concept of access control.
They use a communication protocol called 9P and set of BSD sockets or sockets.
So does this have a relation with like inside the 9P protocol?
They have a authentication to know which one should access, and how does access control
that really have the only way to communicate between stuff is with the 9P protocol.
And you don't have any root user, so there should be some authentication inside the packets
or something.
Yeah, and so 9P, I call it, this might be, it's like, I do a definition, but this is what
I call it, I call it an amp area ubiquitous that were transplanted protocol, which is
to say that it's protocols used practically everywhere in the system, from authentication
to connecting the services to accessing resources.
And it's never transparent in that it can use TCP, it can use UDP, it can use application
layer protocols.
It uses all these different things, but it still uses the same interface.
So when you do, when you use 9P, you could be using it with a server around the like
somewhere across the world, or it could be in the same building, or it could be the same
machine.
And their 9P doesn't really care that much, you know, it's designed to be transparent
in that regard.
So on the topic of authentication and the absence of a root user, there are actually, there
is an account, I think it's called the host owner, which is given on every machine.
So the CPU server will have a host owner and the storage server will have a host owner
and if anything else, it will have a host owner.
And it's not necessarily a root account, it's host owner, but it's an account that's really
used for maintenance stuff.
You can use the host owner to add hardware devices, you know, upgrade hard, upgrading hardware,
you can use it to manage some services on the system.
Because when you're in a network where there's no like administrator user, you're still
going to need to use some kind of privileged account to do some certain tasks, that's just
kind of something you can't avoid.
But with that said, the host owner account is still pretty limited in its privileges.
They'll allow us to do a pretty good job of making a system work really well with how
to root an account.
And authentication wise, it's a tough subject to talk about in my opinion.
Authentication of the N9 is really a exotic thing, and in fact, they didn't actually implement
a robust authentication process until about like the fourth edition or so.
They wrote this thing called back totem, which is the relative to purposes, it's the authentication
protocol for the system.
In fact, totem uses a really interesting design, in the way it works just kind of fascinates
me.
I haven't used it as much as I'd like to.
I remember a few months ago, I hosted a nine front server, nine front, say a four good
plan nine, a derivative of plan nine.
I wrote it.
I wrote it.
I ran it on a virtual private server, and a bunch of nixers guys connected to it, and they
must challenge it.
And that was kind of my dive into fact totem, because I needed to use fact totem to
authenticate everybody.
And the case where I had my small cluster of thing centers, I was the only person using
it.
And the case was not really a priority for me, but with the VTS running nine front, when
I had multiple people, that's where fact totem came into play, and that's where I really
got to understand at least from an interface perspective how it works and what it is.
So yeah, generally speaking, authentication plan nine wasn't really a primary goal until
later on.
And in fact, totem was really a fascinating piece of software.
It's confusing, but it's pretty cool, yeah.
So talking about those exotic things, do you think there's something like that?
That was inspired, like really directly inspired by the unix, by some unix tools, but that
was like a super set of it.
I think it was, they took piping, and they made something called plumber, but plumber
is pretty new, I think.
Yeah.
So do you think it's a supper set of it, because it's made by the same people?
Yeah.
Yeah, they definitely use some concepts from research unix.
Plumber is a good example, like you said.
So the plumber is in a process communication mechanism, where you can send text over a,
I guess you can call it a pipe, you send text to plumber, and depending on what kind
of text it is, the plumber could parse it and understand where it needs to go or what
you're trying to say with it.
Like I could plumb a string of numbers or string of numbers and characters that falls
to certain, like, regular expression, and an application will open as a result.
So I think a good example is Acme.
Acme is the plan nine, one of the plan nine text editors were written by a prop pipe.
So I could send like a string of text from a const from a terminal.
It could have like a file name and then a number of line and just plumb that as is in
plan nine.
I guess the plumber would be smart enough to know that's a file that needs to be opened.
And so what it would do is it would open up Acme with that file already opened and it
would highlight the line that was inside the string text that you plumbed to it.
So I think that's a good solid example, but the plumber is.
And in fact, actually, there were a lot of usually in applications that were directly
ported to plan nine.
You know, you still have things like Cat and LS and PS and some simple programs like that.
Some of them were ported directly to plan nine and C while others were rewritten in RC
and RC's scripting language used for plan nine and it's also the shell used for the
terminals.
So yeah, it's pretty easy to notice some principles used in traditional Unix with plan nine,
which makes a lot of sense, you know, because they came from the same guys.
But they definitely revisited a lot of things with plan nine at record.
So I think I've saw, but I'm not sure of it.
I really not sure of it, but I think they're using another C dialect.
Can you confirm that?
Yes.
Yeah, they use their own dialect to see.
Okay.
So there's something that I was surprised at first, but plan nine is graphic oriented.
And there's a guy called Eric Rayman.
I think you know it from the art of Unix programming.
And he says that one of the things very specific to a Unix system is that it's first based
on text and then the layer above comes with graphics or whatever fancy overlay you want
to add to it.
But plan nine comes like graphical first.
Yeah.
Do you think it was a good choice to go for that or because it's made by the same people
who did the Unix, so probably they did it for a good reason.
Yeah.
Yeah.
And that graphics discussion, I think one thing you need to look at with that is the time
period.
That plan I was developing, you know, the initial development started in the late 80s time
period.
So we're looking at like operating systems like Windows and early versions of Mac OS.
Well, I guess I guess in the early 80s and not the early 80s, Windows was in the
whole of west.
It was just a program for dots.
But anyways, so we had graphics using interfaces come and do home PCs, personal PCs.
We also saw networking take a huge influence over that.
So yeah, I think they were, you know, they were correct in making graphics a integral
part of the system.
You know, and sometimes really need to be said about the Unix guys, you know, basically
taking a stance on graphics and kind of showing the world what they think they should
be.
Because they did a pretty good job.
And the interface to plan nine graphics wise is as usual exotic, because the plan manages
to very strange operating system bluntly put the way they did graphics and compare some
to operating systems like Mac OS and even Unix desktops like CDE and X-Loading Manager
like TWM and whatnot.
The way plan nine did it was just so much more simple in my opinion.
Not just from an interface standpoint, like the user interface, but also the software
we've used to show that graphical experience was really quite a feat.
Yeah, eight and a half was one of the, well, actually, eight and a half was initially
written for Unix by Ralph Pike and then they kind of worked on that more and wrote Rio,
which is the current one of manager for plan nine.
But yeah, eight and a half was sort of a precursor to what would be the graphical user interface
for plan nine.
And you can see that with photos of eight and a half in Rio, eight and a half was written
for modicums plays and then once been mapped to play, it came out of the picture.
That's when they added color and Rio had support for that and a few other things as well.
But yeah, eight and a half was a precursor to the interface.
I think the novelty behind it comes from the fact that Ralph Pike did write the graphical
environment, the graphical server before X11 and before any of the big, big, like graphical
environment, but was still something new.
So he wasn't biased, he wasn't copying something else.
He did his own thing, his own concept.
Yeah.
Yeah.
In the early 80s, 1982 or so, he created the Blitz terminal, which is a graphical interface
and even that from 1982 and plan nine development, let's start until six or seven years after
82.
You still see the Blitz terminal.
You still see plan nine and it was used on Unix, obviously, but yeah, Ralph Pike, he
had that idea for a long time, that whole user interface graph user has had that idea
for a long time.
Let's move to a section like how plan nine affected other operating system, how what
it did really inspired others or how it did take it to another step.
Like for example, the minimalism philosophy, just without Unix, just minimalism itself instead
of having like other operating systems and the thousands of system calls, plan nine has
only 51 system calls, which is really impressive.
When I did the research on system calls for one of the podcasts, I was reading them like
for plan nine, it's just headers and numbers and that's it.
Yeah.
That's about minimalism, but there are stuff like really other operating system completely
copied and they took from plan nine itself, like the slash proc directory, the union
file system and sort of like Docker, the software Docker, like UTFA itself, it's a standard
nowadays network file systems to, anyway, what do you have to say about like the inspiration
for other operating systems?
There's someone that says that sooner or later, plan nine cannot reach the point where
it's going to be popular, but sooner or later, other operating systems are going to try
to incorporate some function that plan nine already does.
So it could somehow get inside or merge with some other operating system.
Yeah.
Yeah.
A lot of these can be said in that regard.
I think two of the largest things you need to look at with that are UTFA, like you
said, and the proc file system, both of which originated in plan nine, and in fact, Rob
Pike, Ken Thompson created Unicode, Rob Pike was with him.
I don't know why I remember this, so it was like the whole story so vividly, but I do.
I think it's pretty cool.
You know, Ken Thompson, who worked on the original Unics with Dennis Richey in the late
60s and early 70s, came with Rob Pike in a diner, just somewhere in a diner, somewhere
I think.
Ken managed to write down what Unicode was in the back of like a placemat or an acronym
or something, and it's designed, it was just so sophisticated to get simple, and I think
as computer scientists and programmers, you know, we need to follow the kind of philosophy
with everything we do.
And plan nine definitely did that.
And so UTFA was a lot of things.
Actually, it was backwards compatible with ASCII, which was a huge deal because you didn't
have to do anything else.
Like, if you had a string of ASCII text, ASCII could just be used without any extra effort
at all.
UTFA could use ASCII and that was that.
Another thing was used a bit, the stream was a number of bytes that you could use for
a character with arbitrary, which means that you didn't have to fix them or fight to work
with.
So when you're sending bytes over the wire, over network, UTFA was able to know how many
bytes it was expecting for a certain character, and then read those bytes as they were.
And so when you're dealing with a lot of languages, that's a big deal because, you know,
you have different sections of bytes for different languages, and actually it's different
sections of bits as well, actually.
So for UTFA to be able to do that at the time was pretty impressive.
Nowadays, we kind of take that kind of thing for granted, but when networking was a little
bit more expensive back in those days, being able to know exactly what you're expecting
as it's going over the wire was pretty cool.
And so UTFA was quite an accomplishment on their part, and to go on with that a little
bit more, the time period as well.
When you're dealing with a lot of locales like ASCII or ISO 8859 or, you know, some Japanese
or French or German, whatever it might be, whatever language it might be, having an encoding
that's capable of expressing tons of languages and even having enough room just so like,
you know, emoticons and things like that is amazing because you can have files that are
in UTFA, you know, they can express different languages effortlessly, right?
If you're doing like encoding A to encoding B, you might get a lot of weird symbols and
stuff because the coatings are different.
But if you have a standard encoding for all languages, that's good because the file could
be in that encoding applications can use that and we're all kind of on the same page
in our garden.
So UTFA was great and that was obviously taken by their operators and the web as well.
UTFA uses a lot, you know, UTFA is huge on the web and the proc file system kind of
changed its subjects.
Data origin on a plan 9 and the proc file system exposes processes at a process of model,
you know, hence the name.
So you can view things like PC, right?
Yeah, yeah, yeah, you can use the right PC, yeah, and you can use it.
I think another good use of it is deep biking as well, deep biking applications but being
able to view, you know, the memory it's using, when it's accessing things like that,
it's pretty cool.
And proc is used directly in Linux and some of the BSDs, I don't think open BSD uses it,
I think free BSD is free BSD, yeah, yeah, yeah, and so the proc file system is pretty cool,
yeah, yeah, the proc file is pretty cool and I think that relates back to everything as
a file on plan 9, like I said before, everything is a file, you know, to TCP packets, to with
the mouse, to the keyboard, to the monitor, to other hardware devices, sockets, again,
processes, acme windows, or files, it's really, it's really cool and the proc file system is
a good example of that everything is a file philosophy that plan 9 implemented so well.
Union mounts, but I think the purpose by Union mounts in plan 9 was to kind of get rid
of environment variables, specifically path and those related environment variables.
So you could have, you know, a slash bin, a slash bin directory and you could mount other
directories on the slash bin, right?
So plan 9, they like to divide their binaries up by architect, as well as, even in some
cases, language.
So on plan 9, you might have like slash 386 slash bin, which are all binaries used on 386
machines, and so you can mount that as a slash bin and you'd have like 36 binaries, you
could have like...
So that binaries are shared also across the network, so you have one machine that's
rolling only to serve binaries, you can have that.
Yeah, that's a possibility, yeah.
And the reason they say that's a good way to make sure that like the architecture of
binaries was taken note of was because plan 9 was operating system that could be used
on several different architectures, right?
It's a architecture, a nasty kind of system.
You could run a spark bin area on a 386 and that would work perfectly fine because of
the way it was designed.
And you could mount all those binary directors on the slash bin, and you could even use
you can mount them like before or after other directors, so you could like say, if I have
two versions of the same program, and I want a specific one, I could use mount to, you
know, but that specific one before the one I, the one that might already be mounted or
with mounted later on, and that's used in other places as well.
And in fact, mounting in that sense is pretty integral to plan 9.
You're always mounted stuff on plan 9 because in plan 9, not only is everything a file,
but almost everything's a file system as well.
What surprised me on that topic of union file system is that nowadays people are like
mesmerized at this concept, especially when it's on distributed computing and containers.
And I really, it's a real situation that happened.
I had a friend come to me and he was, yeah, yeah, yeah, Docker invented union file system.
And then when I heard about plan 9 and I checked that, I was like, wait a minute, everyone
is so surprised or so fantasizing about containers when in fact distributed computing and union
file system, the solution was there all along.
Yeah, it's been here for a while.
So yeah, it's really inspiring you software.
So yeah, union file systems, well, actually, you brought a Docker.
I think a cool comparison would be made with Docker.
So Docker, yeah, as it contains, you know, programs they can roll up, but Docker container
which could run like a D-stroke or whatever, I don't know much about Docker, I just kind
of understand it vaguely.
But terminals on plan 9 are kind of like that, kind of like Docker.
They're sort of like containers, you know?
So when you open up two terminals, the terminal has its own overview of the network, which
is to say it has its own overview of the machine.
And so you could mount, let's see, you could mount like, you could mount today a network
card from different machine onto one terminal and the other terminal would have no idea.
So you could not access that card with the other terminal.
And so there's sort of a sense of isolation in that regard, which Docker does a good thing,
which does as well as isolation well because it contains software.
So yeah, yeah, yeah, you can say that Docker has maybe not directly, but definitely indirectly
taking a lot of things from plan 9.
I don't think we can add anything here because we'd confuse everyone.
So let's just talk about the mascot or maybe not.
Oh, yeah.
That's what I'm talking about.
I got the name itself.
Plan 9.
Yeah.
So plan 9, the name of the original distribution is called plan 9 for Bell Labs.
And that's a jab at this terrible movie on plan 9 from outer space.
And so the developers, the Unix guys, the Unix guys at Bell Labs, we were deciding in
it.
I don't know why they chose that specific movie to name the operating system after, but
they did.
Maybe because it was so bad.
I don't know.
But yeah, the story behind that is pretty simple.
It's just plan 9 from outer space.
I think honestly, I think that movie is kind of regarded as like the worst movie ever
created ever.
And so for some reason, the name of the operating system after that.
And it's just kind of ironic, in my opinion, because I think plan 9 is like a work of art
really.
It's a flawless example of computer science principles and it's a great implementation
of specific concepts, but it's named after a terrible movie.
So it's just kind of funny.
I guess Glenda.
Glenda is the bunny.
The mascot.
Glenda or Glenda.
Glenda.
Also from the same, a centerist as a plan 9 from outer space.
Oh, is it really?
I don't know that.
It doesn't make a lot of sense, doesn't it?
But yeah, yeah.
So Glenda is the bunny.
Glenda was drawn by Rob Pike's wife, who also, I'm pretty sure, also designed the color
scheme.
I don't know, like, if he knows it very well, but the color scheme, I think Rob Pike
comes down to color scheme a couple times and they paid a lot of detail to the colors
used.
They're bright colors, you know, but they're also very kind of column colors.
There's not a lot of contrast and going on.
The video used on a bit map display isn't 24 bit color.
There's a photo, actually, if you go on the website, just go on the plan 9 website.
There's actually a photo, a screenshot of it, up a desktop that showed us the colors
pretty well.
But yeah, there's like hints of blue and hints of yellow.
And so she designed the color scheme, she designed Glenda as well, the bunny rabbit.
Well, that's interesting to have the person who designed the mascot design, also the color
scheme for the operating system.
Yeah.
Actually, that's quite weird because you don't
have the same flexibility for window managers on plan 9.
You're forced to have real because you don't have anything else.
Right.
Anyway, let's finish on something.
Let's finish about plan 9 on something more Unix-like.
Eric Raymond has in his book, like, a section for plan 9, and it's a book about Unix
programming.
Yeah.
And he describes it at the title of the chapter is plan 9, the way the future was.
And the first sentence is, we know what Unix's future used to look like.
It was designed by the research group at Bell Labs that built Unix and called plan 9 from
Bell's Lab.
Plan 9 was an attempt to do Unix over again better.
Mainly it was an attempt, but it's still an ongoing attempt.
More or less, we don't know if it's going to take over one day, but other people are
taking from plan 9, that's true.
So anything to add as an end note for plan 9.
Yeah.
Just try it.
I don't know.
Yeah.
Definitely give a shot.
Eric Raymond.
Eric asked Raymond.
I think he also had a comment about that.
I think he said, when it came to plan 9, Unix was just good enough, you know, even
the end of it was just good enough.
I think he said there were like, yeah, if you have a working system already running and
it's good enough, why change it?
Exactly.
So even if plan 9 did stuff better, Unix was already there and it was being by then
as used for about 20 years or so when plan 9 came out.
I think the thing is to be said about that when people are developing new systems and
new answers to questions in software.
I think one of the worst things that could happen is the current solution is just good
enough for everyone else and that would defeat the purpose of a new solution.
Yeah.
So even if plan 9 didn't really take off the way it could have, like you said, we do
see a lot of examples of it in current operating systems today.
That was a fairly long talk about plan 9.
Now what's to take out of this talk and Unix related?
Plan 9 is inspired by Unix and it inspires Unix.
Okay.
So that's what is to remember out of this talk, the conclusion.
Now let's move to chocolate milk.
What's that?
What?
Wait.
What?
Adam?
Why do you like it so much?
Yeah, why do you like it so much?
Oh god, it's so tasty, man.
I love it.
Actually, funnily enough, I can't stand white milk.
I can't stand the fragrant milk.
I taste even like the slightest bit and I get sick for some reason, but chocolate milk
I could just drink that for us in my life and be fine.
I don't know why I like it so much.
I don't know.
I mean, we kind of all have our favorite drink and I guess I might like chocolate milk
a bit more.
As a matter of fact, I just picked up some more that the grocery store and I was drinking
some before we started this podcast.
I don't know, man.
I'll do all day, so I'll look at Peter and drink chocolate milk.
I think some day there was a drunk ex and he posted that, I think, Jeff Imagine where
someone pours all his chocolate milk into the sink and you were like, that's the torture.
Yeah, man.
He likes talking about that, yeah.
And actually, whenever he draws a photo of me, because he's a great artist, and so
right now, I'll ask him to just draw some kind of picture of me and he has that chocolate
milk in his somewhere.
Chocolate milk and plan nine, here is that chocolate milk and plan nine to it.
But yeah, he needs to do more of those, probably, yeah.
So this is everything for this episode about Unicom, plan nine, and chocolate miracle.
And here are some M4 if you want to contact Adam slash APK.
I'm starting to get back on the higher excuse server.
I'm on it right now, actually.
So I'll be on there, I think more frequently now.
I'm just APK on the higher excuse server.
I do have an email address.
I kind of, I have a spirit to think where I change it like every, every month or so.
But my, my Gmail, which I use a lot, and have use of passes, Adam, my first name, Adam,
and then the Baron.
So Adam's a Baron at gmail.com.
So give me questions about plan nine or chocolate milk, hit me up, dude, or Unicom.
Or Unicom, yeah, or anything in between.
I love, I love talking to you now, so don't be scared.
So let's move to the section where we talk about what we did this week and last week.
Let's start with a little review of last week.
Last week, podcast was about the booting process on Unics.
And I dealt with the really generic overview of what happens at every level.
And why is it really related to Unics and why it's important to understand all
those parts for debugging and the differences between all the new West Unics like distributions.
So that was it this week, what did I do this week?
This week I didn't do much, so I don't think I'll spend too much time talking about that.
Now this was it, this was it, if you want to contribute as usual, as usual, if you like
what you're listening to, you can contribute in multiple ways.
The first easy way is to just give your appreciation on IRC or on the forums extended podcast
threads.
It gives us a push to know we're going in the right direction.
The second way to contribute is by adding some relevant information on those extended
threads.
A fourth way would be to help me fill the transcript on some episode that are missing
some.
And the last way would be to join me on the podcast.
And you can do that by asking for a podcast key on IRC or on the forums.
And with that key, you can log into the user interface on podcast.nixers.net.
And on this interface, you set your available time for the next week.
And then the best time, the best common time is chosen and you can join at that time.
And remember that you can find all the episodes on this little short link, podcast.nixers.net
slash what WHAT or you can check the feed URL that I just mentioned, podcast.nixers.net slash
F-E-E-D, podcast.nixers.net slash feed.
So this is it.
Thank you very, very, very much for listening and have a wonderful day.
This was phenom for the nixers podcast.
You've been listening to Hacker Public Radio at HackerPublicRadio.org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out
how easy it really is.
Hacker Public Radio was founded by the digital dog pound and the Infonomicon Computer Club.
And it's part of the binary revolution at binwreff.com.
If you have comments on today's show,
please email the host directly, leave a comment on the website or record a follow-up episode
yourself.
Unless otherwise stated, today's show is released on the creative comments, attribution,
share a light 3.0 license.