hpr-knowledge-base/hpr_transcripts/hpr3299.txt

Episode: 3299
Title: HPR3299: Linux Inlaws S01E26: Make your Linux harder
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3299/hpr3299.mp3
Transcribed: 2025-10-24 20:25:50

---

This is Haka Public Radio Episode 3294, made at 25th of March 2021, to main show in entitled,
Lilux Inlon, S-Nero 1-E26. Make your Lilux harder and in part of the series,
Lilux Inlon, it is hosted by Monochrome, and in about 50 minutes long, and carry the next
implicit flag. The summary is ever wanted to know about Apama and the C-Lilux.
And this is your show.
This episode of HPR is brought to you by AnanasThost.com.
Get 15% discount on all shared hosting with the offer code HPR15, that's HPR15.
Better web hosting that's honest and fair at AnanasThost.com.
This is Lilux Inlon, a podcast on topics around free and open-source software, any associated
contraband, communism, the revolution in general, and whatever else, fans is critical.
Please note that this and other episodes may contain strong language, offensive humor,
and other certainly not politically correct language. You have been warned.
Our parents insisted on this disclaimer. Happy mum?
That's the content is not suitable for consumption in the workplace, especially when played back
on a speaker in an open-plan office or similar environments. Any miners under the age of 35,
or any pets including fluffy little killer bunnies, you trusted GuyDog unless on speed,
and Q-T-Rexes or other associated dinosaurs.
Martin, how are things?
Yeah, very well Chris, how are you?
Drinking a hazy jane from BrewDog, BrewDog, if you're listening, if you want to spawn this show,
please get in touch. The address is Sponsors at Lilux Inlon, study you.
Yes, we are open to suggestions, BrewDog, and yes, this is free promo, no, I really like it,
do you know BrewDog?
It's okay.
Full disclosure, Martin is a drinker of real air, camera, exactly.
Camera, if you're listening, Martin is one of your strongest supporters on Birmingham.
Need to say if you want to sponsor us, or Martin anyway, the address is Sponsors at Lilux Inlon,
study you. For the few people that do not like real airs, there are alternatives, of course,
available too, like New England IPAs, as a matter of fact, that's something right now.
And in contrast to real airs, of course, these England IPAs would be served very close to
freezing point as an eight degree centigrade. As a real air drinker, prefer their beer on 20 degrees,
as in just room temperature or something.
Sorry, I'm sorry, Martin, this is what I learned when I visited the country.
Maybe not in England.
They don't like ale if they serve at 20 degrees in Germany.
No, no, they don't, Martin, they only do this in the UK.
I don't feel which century you went to the UK.
As a matter of fact, this one.
Okay, but this is not a show of real air drinkers.
I still want a piece that I call beer, but this is entirely reserved for the grumpy old photos.
Okay, I know, sorry, this episode is actually about something very important,
namely security in Linux.
So Martin, why don't you get us started?
Yeah, so I know, I know someone who started this for a profession, I'm trying to show why.
He appears to be on the show as well, so I think he's going to be a good candidate for this.
Okay, but yeah, I mean, it's not, it's security is obviously not limited to Linux, right?
Any system you're going to run is going to need security, including macOS, Windows,
any operating system of your choice.
Windows, I keep assuming you are, I mean, this is debatable, right?
If you're not exposing your computer to the internet, then you probably don't do that.
I'm fine running this, but if the strange operator says yes, indeed, so yeah.
But this is not a show about bashing Windows, this is rather something called Linux in-laws,
which is of course, as the name suggests, about something about Linux.
Okay, Martin, what do you know about security in Linux?
Security in Linux, well, it bends, okay, so obviously you have your users, your users have privileges
and so on, and then you have route to us, all the privileges in the world.
You're not running anything as routes ever.
Unless you're using two frameworks called abnormal or SE Linux.
Oh, yes, SE Linux, yes.
Because in that case, in that case, especially if you're running these two frameworks in
enforcing mode, and we're going to cover that in a minute, routes cannot do everything,
like in ordinary Linux systems, where you, where we're, where we're, where we're,
where we're as Martin, right, so it can do everything.
So while we are on the subject of SE Linux, most software packages I've come across that need
to be installed, we cry, I see the next to be turn off. Interesting. Would you like a comment?
A comment? Yes, and that case don't use them in production. That will
be a recommendation of this. No, I mean, thank you for this, that's about it.
I thought we didn't want to go down the, I must not have thought we didn't want to go down
this commercial route. Let's leave that product, right? No, Martin, why would that be poor design
if you have to turn off SE Linux if you want to run that software?
Well, it's, so there is obviously off and there is off during install, right, which
those are the two kind of distinctions to make, I think.
Well, off during install is probably okay, but before we go into these details, let's cover some
of the basics. Good idea. Do you know what discretionary access control is?
So that's, that's really leaving it up to the user to define his, that the privileges to his
objects, whether they're files or ports or whatever they are, right? Hence, yes, go ahead, Simon.
Yeah, so with any system security comes down to all the points of access, which is
files, ports, what else do we have? Networking. So at all these levels, yeah, you
and in discretionary access control, you define it yourself, right? Anyway, but why don't you go into
a bit more of a deep dive on this? More than happy to. As the name indicates, it's actually at the
discretion of the user to define any protection on objects. And the typical ACLs, the access
controllers that you find in ordinary Linux and unique systems, like RWX for owner group and others,
as in world, are probably the best known example for this. Any user that creates a fire can
subsequently, because he's the owner of this, set these ACLs as he or she or she sees fit,
whereas in contrast to this something called Mac, as a mandatory access control, is normally
only reserved for certain administrative users to set. In contrast to DAC, a Mac is enforced
and we'll see this one we discussed the prevailing to frameworks as an up armor as well as as
in Linux. And cannot be changed typically by the owner of set object. So if you create a file,
if you're just using DAC as in discretionary access control, of course, you can modify as the ACLs.
In that case, you need being the creator of this file, you can allow additional access,
writing, reading, executing, that sort of thing for this particular object. In contrast to this,
if you're using a mandatory access control, a system administrator does this for you,
are you yourself do not necessarily have the permission to change these access types?
That's the most important thing here. Yeah, so I guess as an example, would you consider
ports underneath a thousand as a mandatory access control example? This is enforced by the
very rudimentary Mac, yes. But this is kind of security by definition, right? Because
this is this is basically where Unix comes from. Only services that are below a thousand,
1025, I think, even, which are normally run by loot because otherwise they won't be able to access
these ports can do so. And the user process is confined to the remaining port range.
So essentially, it's a very kind of brute, I wouldn't say brute force, but rather rudimentary Mac
by implied by the kernel design, let's put it this way, or by the history of the kernel design.
Yeah, indeed. I mean, you can obviously still set the permissions on a, well, actually,
you know, okay, so this comes back to the non-user ability to set access on a
on a program for a portness. By the way, did you know actually that
owner user programs can circumvent this? Yes, but not by themselves, right? You have to
have we to be able to enable that. Yeah, or you have to actually set a capability in order to do so.
Yeah, but that's exactly what that's beyond the scope of this episode. So let's go back to
mandatory access control and discretionary access control. Okay, what is also important is probably
a little bit of history of historical background in this context. Martin, do you know what the
Linux security more in your architecture is? I probably know as well. This is what we call good
preparation for Linux in our episode. And Martin, of course, gets full score for no, no, no,
Joe jokes aside, jokes aside. I mean, it's a bit special. You're security studies, by the way.
Does Martin does has matter for you? I wonder. No, I'm just curious. This is for anyone out there
wanting to take up two weekends through to the pregnancy, no worries.
No, it's. Say again, what's he calling in your certification?
I quite a few of them actually. Well, the security on obviously. Security quite a few too. So
and this is what LinkedIn for is for rather. It's good to my LinkedIn page. You'll find
are you sure there's a made up? No, they're not. That's what most people do on LinkedIn.
It's a certain Martin, this comes to mind.
That's a certain question when it comes to mind. Okay. So next time you come,
Martin, I have the unaltered PDFs to prove it. So the words.
Okay, back to the LSM. A bit of history, a little bit of history here. The LSM was first introduced
about nearly 20 years ago when some people thought that Linux in in addition to the then prevailing
discretionary access control, i.e. stuff that was coming directly from Unix and friends
would need a more enhanced approach to security. So LSM was born due to the idea that
no specific framework would be incorporated in the kernel, but rather the kernel would contain
hooks. And this is basically where it gets it gets interesting. The kernel would contain hooks
that would then allow a policy framework or simply a framework, which is orthogonal to the kernel
to be invoked when certain access to certain objects would be done by a user and entity,
like process. So let's use an example example. If you open a file, ordinary Linux,
you have a process opening that file with that process. There is typically a user idea associated
based on the ACLs of this file. The kernel can check if you are allowed to access the file and if so
in what capacity can you access the data that file? Can you read it? Can you write it? Or can you
even execute the kernel as a file, depending on what's stored in it? In contrast to this,
the LSM facilitates the following. If a user wants to access a file, the LSM typically takes a look at
the file and then goes back to the policy framework or to the framework, which then can check
based on profiles in that armor and what this is we're going to cover in a minute,
or something called policies in SC Linux, whether that process in addition to the DAG
defined for this object is allowed to access this object. So this is the main difference between
ordinary Linux and the LSM enables. The idea was of course that each separation of concerns
essentially the kernel would implement these hooks and then the the framework running
on top of the kernel would implement the MAC mechanisms as in the mandatory x-control mechanisms
independent of any kernel implementation. That would give an additional level of flexibility
for any framework being implemented to to realize mandatory access control.
Let's go into two examples for more typical mandatory access controls. Something called
app armor and SC Linux. What do you know about SC Linux modern? It's very annoying.
Spot on and it was actually developed by something called the NSA.
About 20 years ago, I was a little bit more complicated because the NSA funded a government project
and this government project basically then had the for initial implementation of SC Linux.
At his kind of intention or well, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, for aim,
let's put it this way. Okay, so what and the interesting bit of course about SC Linux
is that something called Android has been using this for at least the last four major versions
as the main security framework. Particular manufacturers like like Samsung do a
an enhanced version of it in the Samsung, for example, calls it nox, but at the end of the day
when it boils down to is is essentially slightly modified as the Linux implementation protecting
the smartphone. Cool, that sounds good. Okay, you want to, sorry, for those of us running Android of course.
Well, what else is there? You can of course run iOS. It's quite a few Apple users have.
Yes. So why don't you walk us through a high level overview of SL Linux?
Can do if you like. Yeah, well, it's a bunch of patches right to the kernel
implementing the vendor checks as control things.
Well, the NSA has done. Yeah, I'm sorry, go ahead.
You're enforcing or mandatory and what else can what else is the element? Is there an option?
Oh, I miss it.
I miss it. Thank you. Yes, I think you're welcome.
Yeah, so those are the three main settings for OSC as you may mix memory. Yes.
Yeah, so what else would you like to know? What typical entities SL Linux can define?
Well, it's about policies, isn't it? Yes. There's the main difference between one of the main
differences that put it this way between something called AppArmor and SL Linux is of course,
but of course, but rather is that SL Linux could define something like a role-based
access control model, also known as an R-back. AppArmor does it slightly different,
but maybe it's good idea to define what an R-back is first. Yeah.
That's right. Yeah.
Yeah, a role-based access control model basically has users, roles,
and the relationships between these entity defined, and also basically then based on the
combination of user roles, defines the access rights or the user rights to certain entities.
Imagine Martin you're running a brothel, right? A brothel that has more than two branches.
But yeah, I'm sure you can shed some light on this here.
I'm just using that as an example. Martin probably would use a cartel, but
the difference are negligible, so don't worry about it. So imagine Martin you're running a brothel,
you have about 10 branches, the brothels, of course, let's start with the users.
Oh, sorry, let's start with the roles, rather, which is one of my interesting. So each and every
entity in this brothel context would have a certain role, like you would have
dams of negligible factions. You would probably have admins of running that brothel.
You maybe have optional pimps, taking care of the promotion of set brothel, and of course,
you would have something called. Yeah, you would have Martin, exactly.
My you would have Martin to do it. And of course Martin, you would have most
importantly, because otherwise you wouldn't be running a brothel, you would have punters, right?
I assume so, yeah. But I mean, without punters as a customer, running a brothel probably
would doesn't make much sense. So these are the roles that you have. And of course, you may have
also subsequent roles in terms of you would have super dams of negligible factions, i.e. VIP.
What's what I'm looking for hookers? Exactly. Like VIP hookers that are only accessible by VIP
punters, as in they have to have a certain status, they should have spent enough though with the
brothel to reach that status. Ordinary punters wouldn't have access to these VIP hookers. And ordinary
punters need to say are not the VIP punters themselves, unless they pre-qualify or they qualify
for this role. Users then would be people associated with these roles. So you would have Joe
though, you would have Martin Visser, you would have Donald Trump just using three random examples
being punters. You would have, and by the way, Martin Femke rings a bell, right? Because she came
up with that example. Apparently that's basically how she implement the whole thing back in the day.
She's the Colonel developer. Oh, okay. No, she's not. No, she's just run to brothel too.
Femke, that, that, that, full disclosure of people, listeners, if you go back a cup of episodes,
you know what Femke is all about. The next three modules, yeah.
Okay. Okay. And going back to the, to the, to the, to the users, and then you would have
games of negotiable affection like Femke, what else comes to mind? Grown you, probably.
And Chivon, okay, to use to Irish names, purely made up, of course. Then you would have a
couple of pimps, and then you would have ethnic stuff running this. So the idea is that, for
example, in this completely made up context, a punter can only access ordinary, they, or can,
or can, can, or can only make use of ordinary names of affection, because a normal punter hasn't
reached this VIP status yet. Only a, if Joe Dow, or Donald Trump spends enough money, he's
being promoted to VIP punter, and can access the VIP names. So this is essentially the role-based
access control model in terms of uniform roles, uniform instantiations of these roles called
users, and you define access mechanisms, i.e. getting together with, with the, with the name of
negotiable affection, or paying or self-flatists. Any questions? Yes, I do have a question on this.
So what you're saying is if you're a Linux user, and you pay enough money, then you can elevate
yourself to root. Linux is a little problem. Linux, Linux is a little brothel, right?
What? You were downfall. Last class, how much I checked anyway. This is just an example. It doesn't
necessarily relate to the Linux, to the Linux kernel as such. I was just using this as a,
as a, as a, as a, as a, as a, as a scene setting, scene resetting, scene resetting for something
called the role-based access control model i.e. these are the typical entities you would find in
an hour back. You have the roles, you have the users, and you have the access control that
these users, that these roles define, exactly. Yeah, the, the, the main difference, I guess, that
says being able to elevate yourself to a different, um, status, right? As a user.
In terms of privileges. Normally, this is done for you as part of a Mac.
Yes, indeed. So your, your role, your role and your associated privileges are fixed
unless changed by another party, right? This is exactly the nature of a Mac, yes.
Okay. Okay. Going, going back, going back to the, to the SLA Linux. So essentially what,
what SLA Linux does, it defines a role-based access control model. Users are normally ordinary Linux
users, and then the role would be a definition of something like admin staff, ordinary users,
and all the rest of them. And there's also something called a type in SLA Linux, which is an entity
that can be associated with a process. In that case, a type or domain, as it is also known,
defines how a subject, which is in turn the user, or representing the user, can access an object.
And an object in SLA Linux in contrast to AppMR can be anything. It can be a database,
it can be a socket, it can be a port, it can be also an entity representing an X window system,
which is quite comprehensive in contrast to something called AppMR. Right.
And there's quite a few differences with AppMR. Yes. And then you have something called policies,
and the policies essentially define how roles, users, and types relate. Our policies define
the way users, our processes, started by users, can access a certain object in a running Linux system.
And we won't go full disclosure, I'm sorry, full disclosure, yes. We won't go through the technical
details of each and every framework, because this way to comprehensive as a Linux alone
is quite powerful, and also as Martin already pointed out, quite complex. A full coverage probably
would stretch this episode way into a couple of hours. So we will leave it at that, of course.
Only two. Maybe three or four. Of course. The show notes will contain pointers to the relevant
documentation. Yes. So in terms of AppMR, is the biggest difference with SE Linux that you
are, the programs are the objects of security abilities, or have I understood that?
To an extent, let's put it this way. The type that is defined as a Linux can also actually reflect
to an object, in that case, it's not bound to a user, but rather specifies how any entity can
access this object in what way. So it's actually a two-pronged approach. You have a process
that wants to access a certain object, and then you have policies, just covering a full object
in terms of being valid across roads, like a default. Let's put it this way.
The details are quite intrinsic and complex. So as I said, in this context, very important.
SE Linux has a great wiki that gives you a very comprehensive introduction to the subject
without getting lost in the details. Let's put it this way. Of course, the links would be in the
show notes. And most importantly, SE Linux and contrast AppMR defines actually modified utilities
to examples, LS and PS. If you specify a minus Z with both commands, you actually get what is
known as a label. Yes, Z, exactly. Sorry, Z in American English, Z in British English.
And this command-on option, or flag, gives you basically prints out the label, which is a
combination of the entities that I just explained. Okay, that's useful.
Right. Why don't you tell us a bit more about AppMR?
It's you, Sonsosa, and Ubuntu, and there's wiki.
That should be sufficient.
Is this, this is not running on the envelope? No, it's not. No, the jokes aside. In contrast to
SL Linux, AppMR is less complex, let's put it this way, but also less powerful.
The equivalent of a policy in SL Linux is something called a profile, and there's also the
main difference that typically a profile is associated with files. Martin, that's plan 9,
ring about, plan 9, cloud 9 does. No, plan 9. There was a movie called plan 9,
from outer space. It doesn't think about? No, I should not need plan it then.
No, it does plan 9 in terms of operating system, fling about.
No, it doesn't. Okay. You heard about, you heard about an operating system called
Unix. They agree, they agree. They agree. Why do a few people who implemented the original
Unix, the original Unix operating system, i.e. system 5, continued on to something called plan 9.
And plan 9, in contrast to the original Unix, had an important property, and a guy called
Linnestow was essentially just stole it or bought it and never gave it back. Each and every entity
in plan 9 can be expressed as a path of file. You'd see this, actually, if you take a look at
modern Linuxes, where you have something called a process file. That directly comes from plan 9.
And the idea behind app armor is actually to, apart from a few exceptions,
like, for example, TCP network traffic, to treat everything pretty much as file.
Okay, so profiles, which, again, are the definition of how a user slash process can access an
object slash slash file, are just basically relating, as I said, to mostly two files.
Yep. And this is one of the main differences, where SE Linnest has quite a comprehensive
role-based access control model. App armor keeps things simple. For example, it doesn't define
a full role-based access control model, but rather it just defines how users or processes
can access in the majority of cases files. So, if you want to do a full
R-back for app armor, actually, you have to combine PAM as the pluggable authentication module system,
typically found in the Linux with app armor, because that only did only that combination
gives you a full R-back. Okay. Hmm, where you say it's limited to Ubuntu and Susie.
This would be the two prominent distributions that use it. Full details are on the app armor
project side, also reference in the show notes. Okay, so why did they go to app armor?
We'd better ask Mark Schalworth, jokes aside. No, they didn't on the show. I feel listening, yeah.
Mark, there was a mail that I sent to you last August. You never replied. Anyway, it doesn't matter.
Both frameworks have their pros and cons. App armor profiles are inherently easier to maintain,
but also less complex. In contrast to this, distributions like rat heads, like centro S,
like what's called scientific Linux, prefer the complexity and the power fullness of
SNLs over app armor. Needless to say, both frameworks are available on the majority of Linux
distributions, more often than not as part of standard repositories. So as usual with open source
software, you are free to choose as you see fit. Both frameworks have their advantages and disadvantages.
It's just the case that some distributions prefer as a Linux, some distributions prefer app armor.
Well, it sounds like app armor is limited to only a few.
Well, the main difference basically being that app armor doesn't define a full-road base access
control model, where it doesn't have the choice if it's not available on, say, a centerway store
of adaptor. It is. Okay. You just have to install it. No, no, sorry. It's just that certain
distributions have a preference for one or the other. Okay.
And funny enough, actually, I think open source is the only RPM-based distribution that
prefers app armor. Of course, there might be wrong listeners. If you have different views,
the email addresses feedback at Linux.edu. Okay. So I think there's that cover of the differences
between the two. A full comprehensive discussion probably would take up at least a couple of hours,
so we leave it at that, I suppose. Okay. But so, are there any other LSM implementations
you'll have? There might be, but I think app armor and reserve would be the two more,
yeah, most prominent ones that you see in the wild being used on a daily basis.
Okay. Cool. I mean, I don't know many deployments, many redheads or center-ass deployments in
production, that is, that you do not use at least some simplified SE implementation in terms of
policies. Yeah. Yeah. I mean, for example, full disclosure, the website or sorry, the server behind
something called the Linux use group in Frankfurt is running center as seven. And of course,
has an as a Linux implementation in terms of a comprehensive set of policies modified for this
web server. Okay. So how long did that take you to set up? We have two admins running this. Yens did
most of the work. Yens, cool if you're listening full marks. Okay. Well, I suppose a couple of weekends.
Let's put it this way. Right. I mean, essentially, it's a standard implementation plus
modified for the particular for the particular piece of software that we run the back one,
for example, as our CMS, we use more and more in. Okay. So any advice for any listeners out there
indeed. Take a look at both frameworks. Take a good look at the at the at the at the documentation
because both of them can be quite powerful. As usual, basically, it's the use case that drives that
decision. If you need, I mean, both frameworks have a certain level of flexibility, because without
saying, if you want to have something easy to set up flexible, easy to maintain, and with lower
implementation effort, but confined in functionality, take a look at up armor. If you're not afraid
of steep learning curves, complexity, but much more power in terms of the exact definition
of security that you use case is looking for. Take a look at SL Linux. Yeah, that makes sense.
So in your Webster example, would you need that complexity?
That's overdrive a little bit more than just a Webster. So that quite a few other components
installed on this, including, for example, main maintenance and all the rest of it.
And it's running center S. So the decision was taken, basically, to remain with SL Linux because
it's a standard Rbeck framework running on top of center S. Okay.
Any closing thoughts on this, Martin? Well, to me, for my limited Linux,
his admin activities, I think,
a really good use case I'd go with that armor, isn't it? A deficiency that can be corrected,
of course, given enough time. Yeah, this is quite an interesting concept, isn't it, time?
The good news is Martin, it has been run for a while. It has been run for a while, but it's also limited
in, it's in a month. Not limited in a month, but limited in a month for there's mortals
amongst us. Indeed. The trouble is, of course, time will outlive the two of us easily.
Yes, it's quite good about that. It has been since its invention, I suppose.
Yeah, they designed that one quite well. Who is, who is they, Martin, explain?
Well, the great time inventor. Who's this? I don't know, you tell me.
I don't know. I'm sorry, I can't help you.
Okay. Okay. This is it. Yeah, that's good. Okay. In that case, we should probably move on
to the feedback, which we haven't done for a while, but now it's the time to catch on up to
with by, I don't know. Okay. Kevin O'Brien writes in, and that's been a while because I think
that feedback, that back, that's back to January. In case you've heard this feedback for Chris
that shows me we haven't done it yet. Kevin O'Brien's back on the 29th of January. I'll
love the show, great show, and I'm promoting it on my social media. Kevin, Kevin, well done.
Please do continue to listen. We are available on the major podcasting networks. We, of course,
are available on Hacker Public Radio. We are not confined in contact to other software
podcasts or something called SoundClouds. I might add. This is a proprietary podcast
platform, I think. Okay. David and Thomas, if you're listening, it's a free word, go for it.
Yeah. Okay. Then the next feedback. Yes. Yes. Read this one out, Martin. Please.
Claudio, thanks for the invite. I'll have my agent contact for you. Claudio,
call it star, ragazzo. Claudio, if you're listening, we would really like to have you on the show.
Indeed. If you're so inclined, please get in touch. The email address is feedback at Linux
in-laws.au. And with this, I think it's now time for the boxes. Okay. Which is, of course, the
pick of the one. Yeah, pick off. Thank you, Martin. Pick off the week. Yes. I should know this
because I came up with it. What can you do? Okay, Martin, what's the pick of the week?
It's a movie called Man Down. Okay. Which is a, yeah, it's quite a, it's a gripping story.
It's really well written, I think, in terms of storyline.
Which, I mean, two minds, whether to talk about it or not, because if I do, then it gives the whole
plot away. So the final description does contain, or the following teaser does, the may contain
spoilers. Yes, yes. Okay. Fair enough. Go ahead, Martin. Sorry. Yeah. Go ahead. Okay. So it's really,
as you're starting in the future and what it comes down to is someone is living in a reality,
in an alternate reality, the way he sees it. So based on events that have happened in this past,
and then slowly the story unfolds, and that's the reality turns out to be a little bit different,
and that's not to say too much, but it, sorry, it comes together at the end, really, in terms of
the two storylines converging, which is, it's very well done, I think, in that way.
Um, well worth a watch. And man down, this is what a drama teacher gets a wake-up call when
his girlfriend leaves him. No. No, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, I am
DBA trip originally. Yeah. Which is involved in it. When was it, when, when was it released?
Quite recent, I think. Okay. Let me check that for you. In the meantime, why do you not tell us
about your pox? Yes. My pox is actually a TV series called The Midnight Grospoil.
How can I put this? It's the rage with younger people. Let's put it this way. Without giving
a, without giving too much away. Essentially, it's about, it's about a bloke, specifically
using British English term here. It's about a bloke living, living on the planet and who's
able to travel to other planets. And the, the, the plot of each and every episode is that he
meets through some time-traveling machine or whatever, whatever that gadget is called. He meets
quite a few other beings on this planet. And while the, while the planets disintegrate of the
cause of an episode, they discuss most philosophical and other topics of great importance.
The fun part is, of course, you see all, all things strange happening while the
discusper is ataric subjects. It's rated quite highly on IMDB, if that's anything to go by.
And the fun, I mean, this description sounds rather dry. And I'm not going to go into the
details because that will spoil the whole fun. But if you have a chance to, to, to watch it,
just go for it, just amazing. So this is a movie or series, sorry? It's a TV series. Right.
If you, it debuted to last year in 2020, where can people find this TV?
You will find links in the show notes. Okay. And I mean, if you're into quirky,
animated, by the way, this is animated, this is not kind of for, I'm, I'm really people doing
that series. If you're into quirky, animated, sci-fi, funny on the funny side, just don't miss it.
Entipoxys Martin. Entipoxys. Yeah. Nothing, nothing for me this week, really.
Not even GPU-based databases. No, no, hey. Okay. Well, I guess they, they sort of
pale in significance compared to quantum computers, but they're not by the way.
I think they're stuck on the way there.
Okay. What about your antipoxidant? It's, it's a beer called Corona.
No, that was a joke. Corona virus, if you're listening.
No, seriously, we had it. We just had it. Do yourself a favor and vanish.
Seriously, just go away. No traces, no phone calls, nothing. Just disappear.
It's enough. It's over. What we could do, actually, with the money is currently being spent on
vaccines. I will, I won't, I won't even go near imagining it. I mean, you're talking about five
star vacations, including... Well, I mean, there's a blow and all the rest of it.
If we're talking about money, that could be spent better. There's a number of people in the world
that could be, help accountable for this one. Jeff and Elon, if you're listening,
yes. That will be my antipoxidant, antipoxidant of the week, yes.
Very good. Very good. Okay. Okay. Of course, closing your marks, of course, we can be found on
Hacker Public Radio, where we will continue to broadcast or to, to upload the show to,
can, if you're listening, thank you. Thank you, Ken. Yes, Mr. Fallon, we do appreciate your,
your hosting services, capabilities, whatever you want to call it. We will be on Hacker Public
Radio until we say so otherwise. And if feedback, please, also, if you have topics for upcoming shows,
so we don't have to think of the crap ourselves that we talk about, please be free, claw your
not to get in touch with us at feedback at Linux in law study you. Yeah, well, we do have a number
of interviews lined up, don't we? So that's, that's quite nice. Something to look forward to. Yes.
With Alan Tesla, sorry, Alan, what's his name again, Jeff and other people? Maybe.
Any particular Alan? No, just saying randomly, I don't know.
And if we can, and if we can find the gray farts, we actually might dig up, what's his name again?
Nikita Tesla? Nikita Tesla? Yes. That's what I'm trying to show for which purpose.
We crossed that bridge mark when we come to it. I think we can leave it there.
This is, if you know where Mr. Tesla is buried, please get in touch and feedback.
And with that, I thank for listening and looking forward to have you on the next episode in terms
of listen to it too. Bye. Bye. This is the Linux in laws. You come for the knowledge, but stay
for the madness. Thank you for listening. This podcast is licensed under the latest version of
the creative comments license type attribution share like credits for the intro music go to blue
for the songs of the market to twin flames for their peace called the flow used for the second
intros and finally to select your ground for the songs we just use by the dark side. You find
these and other dd's licensed under cc hmando a website dedicated to liberate the music industry
from choking copyright legislation and other crap concepts.
You've been listening to hecka public radio at hecka public radio dot 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 hbr listener like yourself. If you ever thought of recording a podcast,
then click on our contribute link to find out how easy it really is. Hecka public radio was
founded by the digital dog pound and the infonomican 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 status,
today's show is released on the creative comments attribution share like 3.0 license