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

630
hpr_transcripts/hpr3665.txt Normal file
View File

@@ -0,0 +1,630 @@
Episode: 3665
Title: HPR3665: UNIX Is Sublime
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3665/hpr3665.mp3
Transcribed: 2025-10-25 03:05:23
---
This is Hacker Public Radio Episode 3,665 for Friday the 19th of August 2022.
Today's show is entitled Unix is Sublime.
It is hosted by Ben R.C. and is about 60 minutes long.
It carries an explicit flag.
The summary is I talk about all of the reasons I love Unix.
This is my Unix episode.
It's more so not necessarily implementation, but some of the designs of a Unix operating
system that make it sort of a sublime experience to use and to think about.
I also have a couple of subtitles I was thinking of as I was writing.
The first one is how to use a computer without hating yourself for it in the morning.
The next one is Unix is basically a simple operating system, followed by ellipses.
It's not super simple compared to real simple operating systems, but it's pretty close.
My third subtitle, My Wearingness and Distain for Computers grows with each additional
unit of knowledge, and then my final subtitle is Worse is Better.
So where did Unix come from?
Unix is not Multix.
Unix is a pun on the Multix name.
Multix might be a thing.
I've never used Multix.
I've never heard of anyone in 2022 using Multix, but Multix was too big and complicated.
So the Bell Labs boys, let's make something better.
It's smaller, simpler, easier to use, easier to maintain, and that's sort of the idea.
Unix is supposed to be simple.
I found some cool links.
First one is how to emulate Multix in 2022.
I have no idea what's going on in Multix.
I couldn't figure it out.
I emulated Unix version 5 and Unix version 7, and then there is a computer history museum
and you can access some of these older systems using SSH guest accounts.
And sort of the idea in my head as I was playing with these things is cool but useless.
A lot of the stuff that's older is cool, but it's not really useful.
Again, I don't know anything about Multix.
I don't know if I should even learn it.
It doesn't really seem useful and it's not really interesting to me immediately because
it's very complicated and alien feeling.
Let's talk about the implementation of Unix.
So I think of Unix.
I don't think of the trademark philosophy.
I think about design principles, user interface, and sort of how a Unix system behaves.
I usually think POSIX-like is similar to Unix-like.
And my example here is that Linux and GNU are not really Unix-like in the sense that
they don't really follow the Unix philosophy of making simple things that work together.
I think they pass the duck test.
The duck test is if it walks like a duck, talks like a duck, and acts like a duck, it's
a duck.
So for all intents and purposes, Linux is a Unix, even though when you get under the hood
it becomes difficult.
And also when I say Unix, I don't mean proprietary, I mean free Unix-like operating systems.
Because a lot of the, I guess, additional aspects aside from the design that make Unix
such a pleasant thing to use is the fact that it's hackable and you can't really hack
a proprietary operating system.
I mean, you can, but it doesn't work and, you know, it breaks your Macbook or whatever.
So I mean open source Unix is a public source, things that you can look into, modify, even
if you're violating some weird licensing terms, you know, it's not enforced hardly ever
as long as you don't tell people about it.
If you can hack on it, it's something that I'm interested in.
Of course hacker in the traditional sense, not in the stealing people's credit card numbers
and social security numbers and selling them online sense.
So what is the Unix philosophy?
There's, you know, different people have said different things, but it pretty much boils
down to do one thing and do it well, design programs that work together using text as the
common interface, test early, test often.
And the fourth one is the KISS philosophy, keep it simple, stupid.
And then another design philosophy is everything as a filer process.
The sort of, it sort of boils down into, you know, Unix is a simple operating system
and sometimes, worse is better.
A complicated solution isn't very useful because nobody can maintain it, but the original
author, whereas I guess a less clever function, a simpler function, using less weird, I guess
it would be like standard library hacks is a better solution, even though it's objectively
worse, it might be slower.
If someone can read the solution, I guess the source code to the program, right?
The program that is the solution to our problem and understand it, that is a better solution.
That's sort of the Unix philosophy.
And I think this show I'm not going to go into specifics, super specifics, like I said,
but I'll talk about like 10,000 foot view.
So the design, Unix is a multi-user time-sharing networked operating system.
It runs as an always online service.
So traditionally, a Unix system is a single mainframe computer and users connect to it concurrently
through dumb terminals.
And the dumb terminals have like, you know, no processing power or just enough processing
power to draw your X windows or whatever you have.
So what this means is time-sharing.
The users take turns using system resources.
And this sort of design makes actually a lot of sense because when you think about how
people actually use computers, they typically will spawn a process or series of processes
that spin up the CPU in a series of short bursts.
So if you get multiple people on the same computer, you're actually making better use of
your hardware so you can save money on sort of hardware costs, maintenance costs because
you're only maintaining one thing, power, so on and so forth.
I think this is something I would like to see more in the modern era is sort of the
concept of mainframe computing as opposed to walking into an office and having hundreds
of ultra small form factor windows PCs that are all individually full of viruses and
un-maintained and sort of breaking in their own ways.
It seems like at least for me in my perspective, it seems kind of asinine that you would
essentially give each user more processing power than they'll ever use and more opportunity
to destroy things and cost the company money than they should be allowed to.
And this is not necessarily restricting the freedom of users argument, it's more so
from a pragmatic standpoint.
It's a lot easier to manage a single system than it is to try to manage hundreds, especially
when 99% of the time, those like ultra small form factor, windows, jet engine sounding
things that are about to explode, they seem really unnecessary, especially when everyone's
just doing data entry in a web browser anyway, like that's really what it is is data entry
and a web browser.
And really that could all be accomplished on the mainframe.
I think tangents aside, let's continue.
The actual software running on the mainframe, I visualized it in sort of hierarchical structures,
Unix is flexible, but it's organized and sort of each concept builds upon the concept
above it.
So if you know anything about computers, you know that the very lowest levels of hardware
on top of that is the kernel, which provides system calls that allow you to write kernel
modules and drivers, which enable file systems.
On top of file systems, you kind of have the organization starts to break down as now
you have a foundation, right?
You have system demons, which are services, users, shells, and then on top of shells,
you have user applications.
And sort of all of these things culminate together for this little purpose of enabling
the end user to play video games and watch videos and that's what 50 years of Unix has
gotten us.
That's the end goal.
So I'm going to start from the bottom, explain some of these concepts and verbosity will
ensue.
So the very lowest level, we're ignoring the hardware.
The kernel, you don't hardly ever interact with it directly.
All of the hard parts of writing software and using the system are abstracted.
So it's not like when you're on a Commodore 64 and you have to poke them in your address
to load a program from tape.
You just type the name of the program you want to run and the kernel just does it.
The next aspect, the kernel enables multitasking.
So this is resource sharing.
This is necessary for multiple users.
So when a user starts a process, the process is, hey, kernel, give me CPU type.
Give me a turn on the CPU.
And each user process is the way I think of it is put into a rotational queue.
All of the other users' processes and system processes are put into this queue.
A lot of times there can be like a round robin approach in the current era, typically it's
weighted.
So like a kernel process will always have priority over a user's process.
And additionally, when you have multiple users, you can assign them hard limits or I guess
levels of, you know, if a process is owned by this user, take it before any other
user, right?
That's what the root account is.
So this sort of idea helps prevent system crashes in addition to time sharing.
Because when the root user needs to log in and fix something, the root user gets priority
over some guy running a fork bomb, for example.
Another kernel thing, virtual memory.
So abstracting memory management.
This makes multitasking almost possible.
Because instead of each program directly asking the hardware for memory, like in a more
primitive operating system, primitive might be the wrong word, but I'm going to use it
anyway, because it's funny to call DOS primitive.
Sort of the idea is that the kernel manages all of the memory and the end user doesn't
have to touch memory ever, ever, ever.
The other thing about virtual memory is that you don't actually have to have physical RAM.
You can have a swap partition, which functions as RAM in air quotes, kind of not really,
but kind of, you can also, if you're really, really making a bad decision, you can mount
a cloud provider's disk as a swap.
And then all of your passwords get submitted to your cloud provider, because that's where
passwords are stored as in RAM.
And your luxkey for your hard disk encryption is submitted to your cloud provider.
And so on and so forth.
Actually an interesting thing about virtual memory.
So virtual memory enabled me to run Gen 2, very heavy Gen 2 installation on a system with
4 gigabytes of RAM, because I had 16 gigabytes of swap space.
So functionally, although it was destroying the hard drive as it, with each additional
compilation job, that functionally gave me 20 gigabytes of memory for, you know, compiling
large things like Firefox and sort of the idea behind virtual memory and swap spaces,
that the kernel doesn't panic when it runs out of memory.
So this means non-essential processes can be killed, or sent to swap, or even idle
processes, typically idle processes are automatically sent to swap after they've been idle
for so long.
But what the idea of swap space means is you can push your system a little bit farther
than it probably would with a different operating system if you're using Unix, because you
have this buffer of virtual memory.
So that means hypothetically you have 16 gigabytes of RAM, and you should probably have 24
gigs of swap, because one and a half times memory is about how much swap you should use.
So you can suspend, and then also have, yeah.
So what this means having the ability to do virtual memory, it means when you push your
system too far, it's able to recover without crashing typically, and you don't even notice,
which is kind of cool, whereas a non-unix system or a system without virtual memory,
it crashes every time you push it a little bit too far.
It's not forgiving, and I think forgiveness is kind of important in operating systems,
especially when we do ridiculous things, as end users, or we make mistakes, or for example,
we copy and paste the fork bomb, and instead of crashing the whole system as a non-privileged
user, the kernel just kills the fork bomb process, and the system continues to run.
And then eventually it will recover as it clears up memory.
Another interesting thing is paged memory, which is sort of logical memory, it's kind
of like logical disk management, or like Linux, LVM, logical volume management.
So paged memory is really cool, instead of allocating memory, so when a program starts
it requests memory, and instead of allocating memory in a continuous block, a continuous
chunk, so see your program asks for, it's a big program, it asks for two gigabytes of
memory.
It's going to get exactly two gigabytes exactly in line, and when the program swaps out,
that whole two gigabytes has to go out, enter out, all at once.
This doesn't really allow for a lot of flexibility, but what paged memory is, is it slices up the
available memory into smaller slices, you know, it depends on what kernel configurations
you're running, and what implementations of paged memory you're running, but what paged
memory does is instead of allocating you one continuous chunk, when you're operating system
for start to probably be one continuous chunk, but as it's running for longer, the memory
becomes fragmented.
So when you have your big, you know, two gigabyte web browser in memory, instead of swapping
out the entire thing, if written appropriately, it can swap out specific pages, which contain
tabs.
So the example here is not, not stalling your web browser by swapping out unused tabs
to disk.
And sort of the idea behind paged memory is that you don't have to allocate things exactly
directly in continuous chunks of memory, and having the kernel do this means the end programmer
doesn't even realize, you know, what's going on.
So when you're writing C, you know, you're incrementing a long memory on a pointer.
You might be going to all sorts of different places in memory, but to you or to the program,
you're just going along incrementally, and the kernel does all of the hard stuff in the
background.
And I think the kernel looming all of the hard cool stuff for you to improve performance,
that's really probably difficult for someone like me to implement.
But it's very beneficial for the people who do know how to implement these things.
Oh, also multi user, multi user processes are multi user systems.
That's what paged memory is good for.
So hypothetically, you have multiple users logged in at the same time, someone's not using
their web browser that gets swapped out, and it doesn't stall any single one user's log
in session because parts are coming into memory off of disk and being sent to disk off
of memory back and forth, fast enough where you don't even really realize that arbitrary
parts of your programmer being swapped in and out constantly.
So I have two parts for programming interface, the other one will come later.
So the first part is sort of system calls, kernel modules and drivers.
So system calls improve security and make programming a lot easier.
So instead of your program directly asking for memory or for network access or for disk
access, instead the program says, hey, kernel am I allowed to access or give me access to
this file and the kernel says, no, the kernel says, sure, here you go.
And also this means we don't have to write assembly to access files because these things
have been abstracted.
All of the hard parts are done for us and forcing some of these more, I guess, dangerous
or potential for danger system calls to go through the kernel adds a layer of protection.
Your web browser doesn't need access to all of the memory because that means your web
browser can read your disk encryption keys that are stored in memory.
Instead, the web browser should say, hey, kernel, give me a memory instead of just taking
memory without getting permission from the arbiter of all.
And then kernel modules, I think of them as like dynamic extensions as kind of plug-in
play except sometimes not and it crashes everything.
So kernel modules, it's a thing you can load into the kernel, it gives your kernel extra
capabilities, sometimes file system support or hardware support.
And the idea behind kernel modules is it's a component of the kernel that's not directly
compiled into the kernel but is dynamically loaded and unloaded when needed.
Sometimes kernel modules are a pain, especially when they don't load when you need them to.
But the benefit behind kernel modules is that whenever say there's a bug in your mouse
driver or your Wi-Fi driver, instead of having to recompile a kernel, install that kernel
and then reboot into that new kernel, you can just update your Wi-Fi driver kernel module,
unload, reload, and now you have new kernel module without the bug.
Some people call these drivers, I call them KMods or kernel modules because that's what
they are.
It's a module of the kernel and what it performs as arbitrary, it doesn't actually have
to be a driver all the time.
So the next thing is the file system.
So Unix, sometimes I think of Unix as sort of, it's not really anything but a hierarchical
file structure that became a monstrosity.
Because if everything is a file, isn't that just mean Unix as a file system?
So unlike a disk operating system or something that's claiming to not be a disk operating
system but is still a disk based operating system, the Unix file system is hierarchical
as a virtual file system, which are logical file systems.
What this means is that instead of having an A drive, a B drive, a C drive, and a D drive
and continuing all the way till Z when you run out of letters and now you can't mount
any more drives and now you're struggling because you can't mount any more drives even
when you have the interfaces to mount past the Z drive.
You can use virtual file systems to sort of get around this constraint of, I guess, lettering
drives.
So virtual file systems, multiple disks are presented to the user as a single unified file
system, this is completely ignoring what actual type of file system is on that drive.
So local disks, NFS shares, the contents of your CD ROM, depending on how you mount it,
the storage on your cell phone when you plug it in, it's all presented as one big drive
because mount points are entirely arbitrary.
You can put whatever file system, whatever disk you want, wherever you want in the file
system, you can mount it wherever and it's just one big file system.
One big hard drive, you don't have to think really hard about where things are, you don't
have to change disks.
All you have to do is think, you know, I'm going to mount this to this sub directory and
now it's just part of the file system.
It's part of the one big hard drive and I don't have to worry, I don't have to think,
I don't have to change how my programs run or change hard coded values, I just type
mount disk, whatever here and then it just mounts there.
Another interesting thing is bind mounts.
So a bind mount is when you mount a directory to another directory and this idea, I haven't
found any practical application for bind mounts but it's kind of interesting.
So this means hypothetically you plug in a drive, of course you have to mount it as root.
Let's say you want to read it as a normally user, you can bind mount that directory to like
slash home, your user, CD rom or whatever it is and bind mounts are really interesting
because the entire file system, right, virtual file system is so flexible.
You can think of it as one large file system where you can put anything anywhere and there's
not really any restrictions and it's completely, I guess ignorant, right?
The kernel, what the kernel presents to you allows the end user to be completely ignorant
of what disks are where, which I think is a really useful thing and I use this concept
quite a lot.
When I mount a like a remote system over SSH or FTP or however I mount it, I typically
put that in like slash home slash my user slash remote and because it's not a hard coded
value and it's not in my FS tab, I can put whatever I want in that remote directory,
whatever computer I'm remotely connecting to, I can just put it right in that directory,
the home slash remote directory, similarly you know home slash disk is what I have and
every time I plug in a disk I'll just mount it there.
So I don't have to adjust my muscle memory every time I just plug it in and I don't even
think about it.
And I think it really makes it easy for a user to be able to use virtual file systems.
The last thing I'm going to say about virtual file systems is the idea of a RAM disk.
So a RAM disk, remember how I said you can use a hard drive for RAM kind of using SwapsWaste.
A RAM disk is the opposite, you're using a portion of your RAM as a piece of physical storage
and you mount that presented as any other device, any other directory.
That's how it's presented to the end user.
Again, shoot foot here, we all know RAM disks are sometimes a bad idea.
Like I said before, in Unix everything is a file to elaborate on this idea, not everything
is actually a file, but everything is presented to the user and the programmer as a file.
So the big example is that DevU random is the random entropy generator.
It's presented as a file.
So when you're a Unix programmer, how do you get a secure random number?
You read some bytes from DevU random and now you have a securely seeded random number
generator.
Another example is that the kernel translates mouse input into a data stream.
That data stream is presented as a file with some of the programmers writing a graphically
user interface instead of having to also include a mouse driver into their program.
You just read input from DevU random and it's just a data stream.
My first exercise is to cat on Linux.
If you're running Linux, type sudo cat slash dev slash input slash mouse zero and then
wiggle your mouse, there's the data stream.
You can run it through a hex dump if you want to see what it's really doing on free
BSD.
It's cat slash dev slash this mouse and of course this is going to change depending on what
hardware you're running.
But I think those are the two most common.
Another example, the TTY, the virtual terminals, the ones you can get to when you push like
control all F3, that's just a file and you can actually print this file using the set
term command.
So my example here, I have these examples in the show notes.
I guess the second exercise here, use the set term to dump the contents of a TTY because
everything is a file.
Just sudo set term dash dash dump and then the number of the TTY in my example, I did
TTY 3 and you just print the contents of the file.
Wow, the terminal is actually just the file.
And although these things seem kind of like hacks, when you think about from a scripting
perspective or from a programming perspective, presenting everything as either a file or
a process or a socket, which is kind of like a file, it really simplifies programming because
really every single program you write basically just reads files and writes to files, you know,
reads a file does some logic and then writes to a file and that's all you have to think
about when you're programming, you know, even a pipe is a file, but I'll get to that.
So linking.
So sometimes when I think of how to make links, this is like hard links and symbolic links.
I think of linking like like mounting a directory to another directory, but without actually
using a bind mount.
So it's accessible in both places, sort of two types of links, hard links and short links.
Hard links adds a new index to a file, so the file has the exact same I note.
And when you add a hard link, basically you're saying, you know, file a and file b are pointers
to the exact same file.
So if I delete file a, file b still points to the file that was also pointed by file a
before remove file a different name, same file.
Links are actually like pointers, because once the original file is gone, the simlink breaks,
but a simlink, when you say tell your text editor to open a simlink, you say, hey, open dot slash
simlink to whatever the whatever file just opens, because a simlink, when you try to open
it says, hey, actually the file you want is this other file, I'm just telling you where
this other file is.
And I think using, I don't really use hard links, but using simlinks makes it really convenient
to access files in places you normally wouldn't access them and also to, you know, pass
like your MariaDB sockets or your PHP processing sockets into its root that otherwise would
be kind of difficult to do, you know, things like that.
File extensions, this is one of my favorite, I guess the most mischievous aspects about
a Unix system is that file extensions are entirely arbitrary, because the guys who wrote
all of our Unix tools, instead of reading file name extensions, what they did is they
said, hey, the file tells us exactly what kind of file it is, why do we have to care about
extensions.
The file system doesn't break when the extension doesn't match, what you're expecting
your programs don't crash when you throw it a file that doesn't have the, I guess in
Windows world correct file extension, I always tell people, you know, why are you sending
me a text file with a dot TXT when we're both using Unix systems, you know, why do you
have to put a dot TXT on everything, I can see that it's a text file just by typing
file using the file command, so I always say extensions only matter when you will fully
associate with Microsoft users and the types of people who leave issues on your software
or repository saying, like, this doesn't work.
In sort of my hypothetical response to those types of people, it's not my operating system,
so it's not my issue, and also all of the code I'm writing is open source, so you can
fork it if you don't like it and add file extensions, but for myself, really the only time
I use file extensions is when I'm publishing something on the web, or when I'm trying
to coerce a specific code forge, I think is the right word, a specific code server to
add syntax highlighting to the thing instead of just treat it like plain text.
So back to multi-user, the concept of a time sharing operating system, so multitasking
that enables a multi-user system, right, that's the round robin, each user gets put in
a queue for system resources, and my exercise here is sort of attempt to use a Microsoft
operating system like a multi-user system.
I think they're now claiming that Windows is a multi-user operating system, but it doesn't
have discretionary access control, you know, it's not multiple users concurrently.
You can't really set up, I guess technically there are services, but you know, the running
is typically not a service account, and I think, you know, if you try to use a Windows
system like a multi-user operating system, a true multi-user operating system, you just,
you can't, you know, it's all advertising.
Multi-user means multi-user, not representing you a login interface that allows you to
change your user, but really it's all running basically as an admin account with a deescalated
permissions.
It's a little bit ridiculous, and I have encountered some issues with like multi-user type stuff.
When I've had the misfortune of having to touch a Windows computer, the big one is discretionary
access control, the fact that you can't really do discretionary access control at all, that's
not viable for a multi-user operating system.
You might have multiple users, but it's like plugging in, you know, 20 screens and 20 keyboards
to the same thing, and everyone trying to get stuff done, it's really chaotic, and you
can't prevent so-and-so from removing your files that you put on the network share.
You can't prevent so-and-so from filling your files with garbage data that you have to
put on the network share.
It's kind of a pain, especially when you have sysadmins and network admins who don't
care that people are causing chaos and sort of slowing productivity, users and groups.
This is something that I think is really beneficial, is that every user is a user, but every
user can also be part of a group, so that way we can assign permissions to an entire group
and users inherit those permissions, we can, you know, set, I guess, priority rate for
the CPU time or how much memory a person is allowed to use.
We can set that for the entire group, similarly file system access, and it really speeds things
up when you need to, for example, you have to grant the accounting department some files,
so you just grant the accounting group read write access.
But the HR department doesn't need write access to the accounting stuff, so they only get
read access, right?
It's sort of that idea, you know, the classic example.
And if you're using FreeBSD, the RCTL program allows you to create log-in classes and
also give like hard resource allocations, or I guess hard resource limits.
To specific users and groups, so what this means is that you can set a limit to where
a normal user can't use more than, say, 20% of the system memory, so that the user doesn't
crash the system.
A similar vein to users, our system demons or services, so since every process has to
be owned by an owner, a service is also owned by an owner, and this allows us to set permissions
on the service in the exact same way we set permissions on the user.
It's really clever how in Unix line we do pretty much everything the same for everything,
we don't really have to think too hard, you know, if we learn about, you know, managing
a log-in user account, guess what?
We also now know how to manage a system user account.
In the idea behind putting, you know, your web server and your DNS server running them
under a non-root account, right, a demon account, is that you're not running a web server
as root user, which means if the thing is exploited, only that system account is exploited
and that system account doesn't really have access to a whole lot, only exactly what
you give it, or exactly what your distribution maintainers give it, and that means someone
can take over your web server and not get remote code execution, necessarily, although it
is possible.
Another thing I talked about access control previously, I mentioned it, but since Unix
is designed to be a multi-user system, access control is absolutely necessary.
So access control means assigning permissions to people, it's controlling access, that's
what it means.
So access control, you can use the octals, I just remember RWX, this read, write, execute
flags, whoever owns the file can grant those flags, systems administrator can grant those
permissions, and the order is owner, group, and other, or UGA, right, user, group, other
all.
This is something that you just get in the habit of knowing when you use ChimadaLot.
This is discretionary access control and means you can modify files at your own discretion.
So this means, for example, you want people to be able to read your hypothetically VIM
configuration, right, the other users on your network to read your VIM configuration,
so they can learn from it, but you don't want them to write to it.
You grant the, you're in the user group, right, the users group.
You grant the group read permissions on your home.vimrc, so other people can read your
VIM configuration, but not write to it.
But also you could make it so they could write to it or execute it.
There are problems with discretionary access control, a bit typically, most people don't
change those things.
You kind of have to be thinking, I want to share this with a person, they already have
a shell, let's just change permissions.
Most people don't think that way, most people think how do I send you this file?
I instead think how do I grant you permission to view this file.
Okay, now actually using the thing, this is the second part of my programming interface.
So all unique utilities, at least the ones that I think are worth using, they have three
data streams, standard in, standard out, standard air.
When you're writing a program, you read from standard in the same way you read from a file.
When you're writing to standard out, you print to the same way you write to a file or you
write to the terminal, which is just a file, standard air, you print the exact same way
you write to a file, and you read from standard air the exact same way you read from a file.
Everything is files, even interprocess communication, the way that is implemented in the standard
libraries is just files.
So when you think about file input output, it's really just file input output.
When you think about interprocess communication, not in a socket sense, but in a unique
spipe sense, passing data through a series of filters, it makes it really easy to program
for.
I don't have to think really hard about how am I going to get input from a different
program?
No, I just read from standard in, and if there's nothing coming from standard in, set
a flag that doesn't take standard input into consideration when calculating results.
Similarly, I guess not similarly, but there's also a fourth-datastream kind of, it's environmental
variables.
That's how CGI programs pass data around.
Using environmental variables to push data around, it's kind of a hack, but that's one
of the cool things about Unix is all of these accidental hacks, these things that were created
by accident flexibility.
It allows you, the end user, the programmer to think of a creative solution to a problem,
but without really not thinking that hard.
So for example, if you didn't know about environmental variables, you would just probably pass form
added text, comma delimited or using the IFS variable or what have you, but if you didn't
know about file input output, you think, oh, I know about environmental variables, let's
pass data through environmental variables.
There's all sorts of weird but clever ways to do things, and sort of the ability to achieve
the same result in an infinite number of, or I guess it's kind of like when you do math,
you can sort of change the function into something that gives you the same result as all
of the other possible permutations of the function.
This is permutation, not in the math sense, but in like variant, it'll give you the exact
same result.
You can do this with the Unix too.
You can put any string of commands you want and get the exact same result that you want,
but you can also do it in a completely different way.
And so I'm going to do it this way and so I'm going to do it that way.
And it's really, instead of memorizing sort of a context, mental health, you just think,
what is the result that I want and how do I walk backwards from that result?
And there's not really a whole lot of, I guess, memorization of answers.
It's more so I have this mental algorithm to achieve a result.
What are the puzzle pieces I know to get the result?
And I think that's one of my favorite parts about using Unix is that there is no set function
to get to the desired answer.
It's just what do you want?
And here's a toolbox figure out how to get there.
How do we do these things with the shell?
So the shell is actually what you interact with when you use a Unix system.
I always say that the shell is sort of a human computer interface using human language.
And whenever someone's like, I can't figure out how to use a terminal, I tell them.
It's literally just human language interface with the computer.
You know how to talk to your like Amazon wiretap that you put in your house?
You know what words to tell it to give you what the result that you want.
Using a command line is no different except that no one is spying on using a command line.
And I think explicitly telling the computer exactly what to do, it's a lot less painful
than trying to interact with the computer that interprets user input
and tries to do what the user intends rather than what the user explicitly says,
especially when these interfaces that translate explicit instructions into what does the user mean,
not what does the user say.
They all seem really over engineered and poorly designed and they're very inconsistent.
They always give you a different thing every time depending on, of course, interface implementation.
The other thing that I really like about using the Unix shell, this would be like Bash,
Posit shell, Corn shell, right, that's what the shell is, that's what the shell stands for
in all of them.
The shell is a scriptable interface.
So math is kind of difficult to do in Posit shell scripting, but most of the time you're
doing math in a different math-specific language because the shell is for human language, numbers
are kind of somewhere in between human language and computer language, but most of the things
you can accomplish are with just strings.
And I think this again goes back to the tool box full of puzzle pieces to get to an answer
is that you can put things in the pipe in whatever order you want and get probably the exact
same result if you're shooting for a specific result.
And I think one of my favorite interesting thoughts I've had about the Posit shell is
that the Posit shell is strongly typed and statically typed because the only data type
is a string.
You have one data type string, so therefore it is strongly typed, it is statically typed.
And of course there are problems when you only have one data type string, you have problems
doing math, case in point, JavaScript, but this sort of idea that let's rate something
super simple or the only data type is string, it's almost magical that we can't actually
do math in shell when the only data type is string.
And I guess my last point to the shell is that if there's a shell utility we don't have
to accomplish our goal or we need a math function or you know a purpose specific what's
the correct term for an application specific solution.
We can just write a simple shell program or a simple C program that fits into our shell
pipeline and it's entirely trivial to do to add a new filter I guess to our existing
shell script which is really just the form of meta programming.
And I think the last concept is the concept of piping, I mentioned this, but the Unix
philosophy, right, everything is a file and programs will transfer data to other programs
in the concept or in the format of a data string, right, plain text, the pipe character,
you know this is the Legos, this is building blocks for shell meta programming, it makes
things really easy because each program is basically a filter, right, that's another
Unix ID, I don't think I wrote down, write shell programs that are basically filters for
other programs.
A lot of people I guess maybe in the olden days you would just use AUK, but I prefer shell,
I prefer taking these tools that I use all the time for like one off, problems to solve
and combining them into something larger, something monstrous, let's see, I'm not sure if I
said why Unix is sublime, this really just turned out to be all the reasons I like Unix
and sort of a thousand foot view of the operating system.
So I'll use my bonus once, so the bonus, right, everything in Unix is a plain text configuration
file unless you're using system D, the fact that everything is configurable in plain text,
although it's not the same format, it makes it really easy to copy settings from specific
things, programs on different systems back and forth, there is no registry editing
hellscape, pretty much all the log files are just a CSV, except the commas usually not
the delimiter, this is one that the reason why people use Linux is that the operating system
vendor doesn't force you to upgrade to a newer version of spyware, whenever the new
version of spyware comes out, you can choose not to upgrade, right, you as the systems administrator
which you are, if you're running a Unix system or a Linux system on a personal computer,
you are the systems administrator, you get to choose modular design.
I really like the modular design of Unix, if you think back to all of the things that
I said, really it seems like modularity is an operating system goal, virtual memory you
can put memory, however you want it, wherever you want it, you can use any storage devices
memory, you know, virtual file system, you can put anything you want that is capable of
storing data as presented to the user as a hard disk, when everything is basically a file,
we can interact with non-file hardware devices, if you will, as if they are a file, you know,
users and groups and services you can do, you can make your own custom deem in account,
the exact same way you write a normal user account, you read the configuration for that
normal user account, you know, shell scripting, that is the essence of flexibility that we
see from a user's perspective, but not exclusively a systems administrator perspective or
an implementation perspective, and also what this modular design means is that the entire
infrastructure for your IT department doesn't go down wind explorer.exe crashes, right?
And if your GNOME shell crashes, the system keeps running as it, the kernel restarts the
GDM process, and I think the last thing, the one thing that I kind of failed to mention
at the beginning is portable design, so let's circle back. You know, Unix, the boys at Bell
Labs, they made something smaller, less complicated, easier to use, with the goal of portability.
This is really right once run everywhere, even though you do have to do some porting
sometimes, Unix really is the common interface between various architectures, and that's
because Unix is kind of the, or as I've said before, POSIX is the lowest common denominator,
so if you target POSIX, your code runs everywhere you can think of, and that's because no one's
porting Windows to Risk, no one's porting Windows to a Vax emulator. Everyone's porting
Unix to Risk, everyone's porting Unix to the Vax, these types of ideas. I think my
summary here is that, at the end of it all, Unix is basically a simple operating system,
but it's really a non-simple operating system. It's designed for, you know, 1970s main
frames, but it's the least bad thing we have. You know, a lot of these things don't seem to
make a lot of sense, a lot of the Unix concepts are kind of like hacks, but these hacks
don't make it so endearing, I think. You know, Unix is big comparing it to like a hobbyist
operating system. Unix is massive, even like a minimal, minimal, I guess, non-system D system,
you know, something built with busy box or muscle-lipsy, you know, something that's a linux plus
canoe, or even a BSD system. All of these hobbyist operating systems are much smaller, but that's
because they tend to be written for one specific goal, as opposed to Unix, which is general
purpose, you know, right once, run everywhere for any purpose. I think that's something I'm
going to start saying. And I think compared to commercial operating systems, Unix can be as
smaller as big as you want, but typically, I think, or at least in a lot of the forums I have
read in the past sort of the goal of Unix, you know, sort of a challenge of these Unix users
to assemble the most minimal operating system they can, because they can do it. And I think
Unix is more than a minimum viable operating system, but that doesn't mean we can't turn it into
a sort of a maximum viable operating system, you know, something too big and unwieldy, just barely
able to wield it, or we can make a minimum viable. That's the flexibility to do what you want with it.
The design is to be flexible. And I think my final link before I stop and edit the show
is my see also the Unix Haters handbook, you know, worse is better. And I think maybe Unix's
sublime is the wrong title, but I sort of started writing and I said, what are the reasons I like
Unix? What are the coolest things about, you know, posics likes? It's the fact that they're all
familiar and there's a lot of clever things, you know, worse is better solutions
that make it quite pleasant to use. And anyway, thanks for listening. Hopefully check out some of
these links. If anyone knows a lot about Maltix, I would be interested in interested in listening to
something about Maltix. Similarly, if anyone knows a whole lot about Minix, that would be something
I'm interested in, sort of all I know about Minix is that Mr. Tenenbaum didn't want to pay for
Unix license, so he invented Minix. And then Mr. Torvalds didn't want to pay for a Minix license,
so he invented Linux. And that is the entire history of free software and a nutshell.
People didn't want to pay a license, but they like the idea, so they just implemented it themselves.
So if you know about Maltix, I guess that's my show request. If you know about Minix,
that's another sure request. As for traditional Unix, I think, you know, cool but useless.
You know, the Unix, the Bell Labs Unix, cool but useless. So again, thanks for listening.
And now it's time for me to start thinking about the next show.
You have been listening to Hacker Public Radio at HackerPublicRadio.org. Today's show was
contributed by a HBR listener like yourself. If you ever thought of recording podcasts,
you click on our contribute link to find out how easy it really is. Hosting for HBR has been
kindly provided by www.unsthost.com, the Internet Archive and R-Sync.net.
On the Satellite status, today's show is released under Creative Commons Attribution 4.0 International
License.