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

140
hpr_transcripts/hpr1238.txt Normal file
View File

@@ -0,0 +1,140 @@
Episode: 1238
Title: HPR1238: Word processors are overrated
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr1238/hpr1238.mp3
Transcribed: 2025-10-17 22:05:21
---
Hello, business, you are on the flute again with my second submission for Acre Public Radio.
I am going to talk about how word processors are overrated and why we should use Markdown
instead.
Word processors are overrated, too often they are used instead of better alternatives.
For example, to write a report, to describe a workflow or a vision, a lot of people just
grab Microsoft Word, which is a bad idea.
Should you use Libra Office, Writer, or Open Office?
Maybe Google Docs?
No, they are not much better.
If the focus of your text is on the content, if the structure of your text is important,
and if the way the text is laid out is less important than the consistency of the layout,
or if you want to collaborate with other people, you should not use a typical mainstream
word processor.
Because they have some major problems.
The first one is that you will probably end up with page layout errors.
If it's not important how your text is laid out, you should focus on the actual information,
and you shouldn't invest your time in making your text look good.
With mainstream word processors, you often end up with formatting inconsistencies, incorrectly
indented bliss bullets, run fonts in a text after a copy-based operation, and inconsistencies
in the formatting of section titles.
Especially when you have to collaborate with other people, the result will be ugly.
And when some contributors use a different word processor than you are using, all bets
are loose.
If multiple people work together on a document using a mainstream word processor, and if
those people don't really care about the page layout, they will probably create an ugly
document.
And that's a shame.
Then it does not have to be this way.
Another problem with the typical word processors is that the learning curve is underestimated.
Experienced user of a word processor will add you that you can avoid all those layout
problems if you use the software the right way.
But that means that all the people working with you on the same document should know how
to use your word processor.
Some of them might have to invest in training.
And even then, it's easy to make mistakes.
A typical word processor has a witty way to interface.
What you see is what you get, which seems very easy to use.
Even a three-year-old child can produce a text.
But any advanced user of a search on word processor will agree that there are many ways to use
it in a wrong way.
The last problem I want to cover might be personal, but many texts that are created with software
like Word are not especially beautiful.
It is not difficult to produce ugly text with word-like systems, and it happens a lot.
Some users need to be protected against the common sense of this world.
If you don't care about your page layout, you should not spend time in laying out your
pages.
You have a computer.
Your computer should take care of the looks of your document, so that you can concentrate
on what actually matters.
So we have to look for alternatives for Word.
Not LibreOffice, not Google Docs, not IP Word, they have the same problems.
We should be looking for something completely different.
Like for example, Latte.
Latte is very good if you need mathematical formulas in your text.
If you have to write a mathematical text on your own or together with someone else,
you obviously choose Latte anyway because there is nothing else.
But if your text is not about mathematics and you have to work with someone else, Latte
is usually not an option.
The majority of people are easily scared because a Latte source document is rather hard
to reach.
What else can we use?
Plain text?
That's an option as well, but the possibilities to format a text are really limited.
Plain text is good for quickly sending an email, but as soon as you need some advanced
formatting, it won't work.
So maybe HTML is an option.
HTML is a whole lot richer than plain text, but also it comes with some disadvantages.
The source code is still quite difficult to read.
It requires some work to get a nice printout, without for example headers and footage from
a browser, and I personally find that HTML text annoying to type.
So now I come to the point I want to make, which is markdown.
Markdown is a great alternative for writing texts.
I won't pretend that it is the perfect solution, but it has some nice features.
It has a decent user base, and a learning curve is quite low.
A markdown file is a plain text document.
Meta information about the structure is added using symbols like the asterisk or the
hash symbol.
This way, the source text stays very readable, and you can easily see the structure.
Text documents can be opened by virtually everyone, and because the possibilities to stretch
the text are limited, the possibilities to make mistakes are limited as well.
A markdown document is just a text file, but there are a lot of tools that render markdown
files to a formatted text.
A lot of blogs and forums accept markdown as input format, and so does GitHub.
So if you work on a text with someone who understands the workings of Git, GitHub renders
your text, and you can easily find the history of each file.
Next to those web applications, there are also a lot of native text editors, which show
a live preview of the text you are typing, like for example, retext for Linux, and markdown
path for Windows.
If you are comfortable using the comment line, you can also use Pandoc to convert your
markdown documents to Lattech for pretty output, two words for conservative readers,
to HTML and to some wiki formats.
There is also a comment line too, called mSider, that converts markdown documents to an HTML
slideshow, but at this moment you will probably have to do some hacking to fine tune the layout
of your resulting slides.
Markdown is not ideal though, it has some limitations, like for example, there is no clear markdown
standard.
Putting tables or images in your document is not always supported, and support for footnotes
is often nonexistent as well, and so on.
On that level, I think DocuWiki has a better markup language, but unfortunately, the
DocuWiki syntax is less used than markdown, in fact, I don't think it's used anywhere
except on DocuWiki itself.
Another disadvantage is that most people do not know markdown yet.
And even worse, Windows doesn't know markdown, or doesn't want to.
As said, markdown documents are just plain text files, but they typically get the .md
extension.
And if you try to open such a document in Windows, then you will get a message that a file
format is not recognized.
So if you work on a document with a Windows user who does not know the difference between
plain text and binary file formats, you probably better use the .txt extension for your file
name.
And if you do not use Windows yourself, make sure that your Windows colleague gets a text
file with Windows line endings, otherwise, notepad is confused.
So that was the point that I want to make.
If you want to write a text, do not use word, just use any software and create a markdown
file.
I want to thank Hacker Public Radio for hosting this file.
And if you want to read more or less the transcript of this talk, including the links to the
different pieces of software, please go to my blog.
You can find it at Johanv.org-node-204, that is j-o-h-a-n-v.org-node-204.
Thank you.
You have been listening to Hacker Public Radio at Hacker Public Radio.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by a HBR listener like yourself.
If you ever consider recording a podcast, then visit our website to find out how easy
it really is.
Hacker Public Radio was founded by the Digital Dog Pound and the Infonomicom Computer
Club.
HBR is funded by the binary revolution at binref.com, all binref projects are crowd-sponsored
by lunar pages.
Of shared hosting to custom private clouds, go to lunarpages.com for all your hosting
needs.
Unless otherwise stasis, today's show is released under a creative commons, attribution, share
a line, lead us our license.