hpr-knowledge-base/hpr_transcripts/hpr4284.txt

Episode: 4284
Title: HPR4284: HPR Developer Information
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4284/hpr4284.mp3
Transcribed: 2025-10-25 22:27:44

---

This is Hacker Public Radio Episode 4284 for Thursday 2 January 2025.
Today's show is entitled HBR Developer Information.
It is hosted by Ken Fallon and is about 16 minutes long.
It carries a clean flag.
The summary is, a set of project principles for those wishing to contribute code to the
HBR project.
Hi everybody, my name is Ken Fallon and you're listening to another episode of Hacker Public
Radio.
Recently, Dave has been, Dave is leaving the project and I'm a singular point of failure
now, so I've been writing a lot of documentation and soliciting help from the community and
in order to do that, people need to know what to expect to this project.
It's kind of different from others, so I've written some developer information for Hacker
Public Radio, HBR and these are the project principles associated with that.
So I'll just read them out and then perhaps I'll go through it second time with some
clarifications.
Well, Hacker Public Radio, HBR is a long-term project run by volunteers.
Project principles are as follows.
There are a few things you need to be aware of before you decide to contribute to Hacker
Public Radio.
Our prime directive is that HBR is dedicated to sharing now.
Any software development is done with the goal of supporting the distribution of podcasts
media locally so that they can be played on as many devices as possible.
Priority is to keep the flow of shows coming in and out, then fix any accessibility issues
that arise and then work on any other feature requests.
Some things can change without discussion, but other things we need to get input from
the HBR community.
Changes can take a long time, community approval can take several months, while other changes
require a lot of work from volunteers who are focused on other priorities.
We allow redistribution by releasing all our content under the Creative Commons, attributing
sure like 4.1 international license.
In the same veil, all our code is released under an AGBLV3 or other OSI approved.
We do not track statistics to the judgment of our prime directive.
We make the entire delivery ecosystem redundant using native internet standard and the co-operation
of community members.
All data is available by default.
Community members, sponsors, hosting platforms will change over time.
We have a distrust of online platforms, libraries and niche tools we don't set ourselves as
they can and have disappeared overnight.
We are very conservative in our choice of tech.
As a rule of thumb, all our software choices tend to be technology that was developed years
ago and is likely to be around for years to come.
We make our code as simple to understand as possible, as our replacements may not have
the skill sets we do.
That said, we move at the times when there is a clear advantage to do so.
We run up to date patched stable software.
We have a long tradition of supporting and sharing hacker culture.
Any identified vulnerable abilities are fixed with credit if requested.
We use RSS as a delivery mechanism, which is by default fault tunnel.
Our primary demands are hacker-public-radio.com and hacker-public-radio.org.
Our registered with different providers and the DNS is served from different locations.
All our code is on git-t, please clone locally.
Our database is updated frequently, please copy locally.
All our media is served from our community content delivery network.
Local reports and patches are welcome from anyone without a commitment.
If you are contributing new code or new technology, we ask you to commit to supporting it for
a minimum of two years.
This allows the generous the time to learn the new tech and support it when you leave.
If you're happy with all of that, then you can create an account.
In order to contribute, you need to create an account and git-t, and you also need to
notify the admins as admin as hacker-public-radio.org.
Either via email, master on our matrix, and tell them that you've created an account.
The reason for this is that we get lots of accounts created every day by spammers.
Okay.
That's it.
Pretty much the description.
Two things that's coming out of that people might find a bit odd is they playing locally
stuff.
When we're talking about HPR and the websites and all the rest of us, what we're actually
wanting to focus on is getting that stuff down to an air quotes MP3 player or a media player
locally that you can play it in your car, that you can play it in, you can burn the CDs.
If you have HPR 9876 on your CD, for instance, it's got all the media, it's got an index.html file,
that index.html file points to all the images that are uploaded to the show notes, points
to any scripts locally, points to everything.
The thing that you need for that show should be locally.
If you're posting shows yourself linking to your own blog, then it's fair game.
We're considering that blog and to be creative comments as well.
Just so you know.
So ideally, please put it into this.
We have the WYSIWIG editor now.
You have the ability to add image, but also do your links as actual links.
It takes you a few extra seconds, but those extra seconds turn into minutes, turn into
hours that we need to do, because we need to do it for everybody else's show.
So using the WYSIWIG editor, that will be great.
So that's that localy thing.
Changes, some changes, fixing typos, no problem, adding how to is no problem.
However, over changing our project principles, then that needs to go to the community.
When in doubt, I have a, when in doubt, ask on the mailing list, definitely needs to go
to the mailing list, and if it's something really big, then we need to announce it on
the community news, and then wait for feedback from the listening community.
So that's kind of that.
Changes, contact time, sometimes, the janitors have vacations, and we can work on it, and
sometimes we're busy with work and personal stuff, and we don't have time.
Specifically, as our focus is getting the shows in, getting the shows out, we don't have
a gap in the queue.
And then as we say, we'll fix accessibility issues, if and when they arise, and then we
do any other feature requests that come.
So please do do feature requests, and do make suggestions.
If you want to discuss a first in the matrix channel, that's fine, or send us an email,
that's also fine.
We will get back to it.
I'm just currently working on something that Dave and I were discussing in 2016.
So now all of them are that old, but some of them are, and some of them are older.
That's, that's, we don't track statistics to the detriment of our prime directive.
Yeah, that's, if you're going to have a free and open internet, that's kind of the
price we pay.
And the reason a lot of the internet has been just centralized, as my opinion, is in
order to facilitate a single point where people go through.
And that means single points of failure, and then you put in additional layers upon layers
of onions on top of that, because you want that central lugging and stuff.
But if you don't care about that, then a lot of, it gives you a lot of freedom for all
the stuff.
So we are trying to maintain a balance now by having, we do have a central point of failure,
which is a served web site, HackerPublicRadio.org.
And if that goes down for some reason, then you know to switch to HackerPublicRadio.com.
And if all of those go down, then we'll use the communication, mailing this, and all
the rest of us, and bring up another domain somewhere else, and switch the main feeds
to that.
But, and then of course we have HackerPublicRadio as well, and three domains there.
Okay, okay, let's see, the licenses should be fairly obvious, yeah, trying to use it.
And this is the thing about trying to use very generic stuff, getting burned by platforms
and libraries disappearing.
Right now we're having an issue where the metadata on the episodes isn't being added
incorrectly, because a library and a portal program has disappeared.
So that's a problem, and it happens, yeah, I know that, but we're actually using quite
a lot of tools as well, and they change over time.
And that means maintenance, so it's a pain, it's a pain.
Equally, we will also do simpler queries, for example, from a database to mention a lot
of the things that Ronan and myself were doing, in order to make it simpler for the next
guy, who will have to come back to it.
So rather than doing it just using a database script, we're going to address a simpler, address
a piece of technology trying to keep it simple, because the next person who comes along may
not be as good to databases or may not be as good as scripting or whatever.
So even something like using expanded options in bash scripting, so that in the fine command,
you don't use abbreviations, dash v, use dash dash for both, or sorry, not dash v for
version, but let's see, you know, dash q in WGET, use dash dash query, so that as you're
reading the command, you can at least follow what's going on.
This is actually quite a lot of stuff going on here, as I'm documenting it, is we built
our own delivery network, we built our own replication network, we're building essentially
YouTube's infrastructure, but on a sheath's ring, thank you Josh, just now from Anonstools.com
who provides our stuff, but also thanks to the internet and also thanks to the CCDN community
content delivery network. And that is, if you've got a machine line round and like for
terabyte artists that you can plug into it, you can ursync our data over and you can then
be part of that network, so that when somebody comes into the main site, when somebody comes
into the main site looking for a media file, it gets randomly distributed over currently
random distributed over the content delivery network.
And later, we will possibly do GOIP locations so that you get the media file from the nearest
location, which is cheaper and more efficient and just nicer, basically.
And we need to also think about, yeah, there's a little bit about redundancy there, about
all the code, copy the database, copy the code locally, everything, you should have everything
available to you. There is one table that we don't just, that's the reservations table,
we do distribute it if you're a janitor, but it can be recreated pretty easy as well.
And that's because it contains the IP address information of the people uploading for the
duration to show us in process. After the show is processed, we delete that. What else?
Yeah, we use stable stuff, stables. Yeah, 20 years ago is when this, this year, this
project will be 20 years old. And therefore, you know, stuff comes goes, platforms come
and goes, tools come and go, uh, grep, they'll remain with us. So, you know, that's, that's
kind of where we're going, stable, update maintained platform. That said, we're running like
the latest web servers on the front end. I'm why not? And their patch notes cause we're
serving basically static files. And there again, you can afford to use slower queries and
more expensive queries if you're only running them once an hour, uh, and producing a text
file or a HTML file that anybody can register. And that's what we're doing. So the statistics,
uh, to get the stats page, that's, yeah, it could be more efficient query. So if we were
running everything that every med that stats file available to the public and that is up
to date with a minute's accuracy, you would need to run that query expensive query for every
person who hits us. And then maybe somebody's building a dashboard and is paying that query
every minute. So that's very expensive on the, uh, very expensive in terms of processing
power. And I don't know, I don't know, also cost because this at the end of the day, each
of these things costs Josh, uh, on his AWS instance. So the other way around that is because
we're a slow project, one short day is a change. Um, therefore we can afford to run the
query once every 15 minutes. And then put the output of that out to a text file. So if
you submitted the show and we will get to it at some point, it usually takes a few days
to do that. Currently, as we put the wizard again editor of it broke everything on the upload
part and all of a sudden all the libraries ceased to work for the encoding part. So not
only was the entire, the entire back office part of the HPR has been broken for the last
few days. And it's still broken. And here I'm recording a show. And that's exactly why I want
to record a show is because we need more developers coming on board and helping out. And in order
for to do that, things need to be documented and things also need to be fairly sane.
Going forward, we'll try and maybe modularize it. Um, let's see, community members, everybody's
changed over time. Yeah. So I'm also looking at retiring, retiring, at least stepping back a bit,
and having to come on doing rather than just the two of us doing all the work, um, we can divide
it up, uh, among virtual. And it does not have to be coding. For example, we're currently looking
for somebody to take over, um, organizing at least, not necessarily participating in, but organizing
in the community news, um, show. So that's one thing you do once a month. Keep an eye on us.
Keep an eye in the news. Keep an eye in the midst of scripts and everything that Dave has.
Probably a lot of it could be automated. So, um, make the tickets to get that
automated and keep an eye on, uh, send up a reminder somewhere so that you send out the mail
to the mailing list about community news, um, as, uh, trying to organize a rotating host to come in
for, for the shows so that other people can do it. So you could own us. You don't necessarily need
to do it, but you could own the management of that like an office, sort of office manager project
manager task. Um, so that's, that's stuff that you can help out with. Um, we also have an
Arthur 72 now and some guy in the internet. They're managing, uh, our matrix channels, um, by managing,
I mean, being on there, answering people's questions, pointing them in the right direction.
We're building up a little team of people who can help us with, um, coding and producing good
quality podcasts and stuff. Obviously, obviously, you know, my area of expertise. Um, so, yeah,
and as for the rest of us, we're, we're in a good position from the point of view of redundancy.
Yeah, it's, if the show doesn't come out today, it comes out tomorrow. Now, in principle, we make
sure we release it every day, but from an RSS point of view, um, if somebody doesn't open
their RSS reader today and they open it in two days time, they will get three day shuls, uh,
we're quite redundant to you. So that's, that's kind of good. And by the way, if you're into
computers tech and networks and stuff like that, um, but don't have work experience or, um,
have nothing on your CV or resume where you can say, uh, look, eyes of work done on this sort of
stuff. This is, this is what the big boys, uh, and girls do. Most of the boys, that's racist because
it's a male dominated field. Um, but this is what the, what we can do, get an access to actually
building a distributed metric, everything they come. There you go. Oh, yeah. Keep an eye on the, uh,
join the matrix channel, create a GT account if you're interested. And that's sort of thing.
Uh, submit issues, try and help out basically. There are lots of mobs. Pick one.
Tune in tomorrow for another exciting episode of Hacker Public.
You have been listening to Hacker Public Radio. Hacker Public Radio does work.
Today's show was contributed by a HBR listener like yourself. If you ever thought of recording
podcast, click on our contribute link to find out how easy it really is. Posting for HBR has been
kindly provided by an honesthost.com, the internet archive, and our synch.net. On this
otherwise stated, today's show is released under Creative Commons, Attribution 4.0 International
License.