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

114
hpr_transcripts/hpr0340.txt Normal file
View File

@@ -0,0 +1,114 @@
Episode: 340
Title: HPR0340: RTFM
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0340/hpr0340.mp3
Transcribed: 2025-10-07 16:42:30
---
Please excuse me for a quality of the audio.
Campus recorded this episode a lot on times, and believe it or not this is the best version.
Good afternoon ladies and gentlemen, my name is Ken Fallon and this is another episode of Hacker
Public Radio.
Today's episode is entitled RTFM.
RTFM stands for Read the Video Manual, and you'll see it on forums, notice boards,
email this, and it's essentially used where the person applying to you feels that you
haven't done enough research on the question that you're asking and that by simply looking
up the manual you would get your answer.
Well, the origins of this acronym comes from the days when computers were delivered in
big crates, and along with these big crates came another big crate which contains the
documentation for your system.
Now we're not talking a lot of books here, or sounds manuals, or big computer for dummies.
We're talking about essentially what would be a transcript of an engineer standing beside
you detailing everything to do with how to get your computer into operation, how to do
normal everyday tasks, and how to continue using your system.
So they tend to be very dry and boring.
The first manual typically was they required hardware, the required environment, the voltage,
the temperature, the power supplies, how to connect things together, how to screw
those safety information, all that sort of thing.
Then the next manual would be on how to load the operating system on your computer, how
to do backups, how to configure networking, how to configure printing, and so on and so
forth.
My first IT job, we had some novel servers, and they were supplied, one box was a box full
of floppy disks, and then there was another crate which was 15 or so manuals that filled
out an entire bookshelf, and there again everything was detailed, all the commands on your system
were detailed, how to do backups, how to configure networking, how to install services,
how to run commands.
And it was easy for me as admin to take one of those manuals home, read it during dinner,
read it nice, and you learned a lot about your system.
And essentially what I want to convey here is that that's still a valid thing for everybody
to do.
I've gone to Google and I've typed in documentation space, red hat, and you get dumped
into the red hat documentation page, documentation space, open cellars, same thing, documentation
space, Debian, same thing.
A lot of these projects still have manuals that are available for you to download, and
you should download them, and either put them on your pva or other device or print them
out.
If you print them out on a booklet printing with four sheets per page, then it's not
that environmentally unfriendly, and you have a copy if you're ever in a situation where
you need to configure your system, and you don't have access to the internet, especially
important.
If you're in a data center that doesn't allow internet access externally or you're in
a dead spot where you have no mobile internet, or if you're trying to configure a device
to allow you to the internet, so your internet browser, for instance.
It's also a very valuable thing to do to download the manuals for your system, your operating
system, and for your hardware, because what actually happened was in the intervening
time between manuals being shipped with systems.
People had the bright idea, well, they had no choice but to ship the manuals with the
systems at the time, because there was no internet.
You had nobody else to ask, so it was either you found the answer in the manual or you picked
up the phone and you spoke to an engineer, a very expensive consultant, in most cases,
who would answer your question for you for a fee.
So as time went on, that's the manuals.
The printed manuals went out of vogue, because people thought, hey, we can save a lot of
money and we can put the manuals on to the CDs, and this sold that to us under the heading
of CD, you would be more current, it was more convenient, it wasn't, and that isn't,
but it is, yeah, it is what it really is, at least, systems used to be sold with CDs.
Now systems are not sold with anything, and you're told that the manuals that you're
required on some website, well, good, go ahead and get the manuals for every system that
you have now, because I guarantee you, in five years' time, when you're looking to update
some backplane on that system that you have, you're not going to be able to find the manual
because it's an archive system, it's no longer sold, or the company that had it was taken
over and those products are phased out.
So it's part of your backup and maintenance routine to take a copy of those manuals
and burn them on to CD and have them with your recovery disks, it's a very useful thing.
Very useful thing for anybody in engineers as well, wants to get into the field, is to
download the manuals for an operating system that they probably couldn't afford.
For example, something like Red Hat Enterprise Linux, you can download the manuals for that
for free and use the non-copyrighted version released by Santo S, and you essentially
have all the everything that you need in order to gain a lot of valuable experience about
Red Hat Enterprise Linux.
And you notice that as time goes on, when you're reading more and more manuals, that you'll
find that you're able to skip through a lot of the sections, for instance, the section
on ping is going to be similar across all systems.
There may be some differences between the switches on Solaris and FreeBSD to Linux, but
if you're reading Red Hat manual and then you go on to read the Debian manual, there's
not going to be a lot of difference, there might be difference of where the configuration
files are kept, but it essentially means the more manuals to read, the more manuals
that you read, the less time you have to spend reading new manuals.
So getting back to this old RTFM thing, it didn't actually be used ever.
Now there is no excuse for using it because back in the day, when people have manuals,
you could refer to, if somebody asked about it, well, I have a local system, and I want
to know how to load the HTTP service, well, you go to the book on the HTTP service,
and you go to page 37 and you read it, that's what you should do, you paid for the system,
and you've got a manual for the system.
Now it doesn't work that way because the manual is often hidden somewhere, and people
have gotten out of practice of reading manuals, people post questions, and begin an answer
on the forums.
I can't remember the last time that when I put a search tone into Google for something
that I ended up actually on the manual of the customer, usually I end up on the forum
that links to the manual, and that's, well, I don't know if that's how it should be,
but that's the way it is.
So there is absolutely no excuse for somebody writing RTFM, unless, of course, you point
them to the manual itself, in which case you would say, here is the manual.
Have a look on page 13, if you have more questions, get back to.
In that case, you're not being rude to somebody, you're helping them out, but you're also
giving them the tools that they can educate themselves.
This has been about the 90th time that I've recorded this show, and I will dedicate this
show to Zogue, and I hope that that is the last time he encounters RTFM out in the world.
Ladies and gentlemen, thank you for listening.
This has been another episode of Hector Public Radio, and as always, tune in tomorrow
for another possibly more exciting show.
Thank you.
Thank you for listening to Hector Public Radio, HBR is sponsored by Carol.net, so head
on over to C-A-R-O dot N-E-T for all of her team.
Thank you for listening to Hector Public Radio, Hector Public Radio, Hector Public Radio, Hector Public Radio, Hector Public Radio, Hector Public Radio.