hpr-knowledge-base/hpr_transcripts/hpr3033.txt

Episode: 3033
Title: HPR3033: Linux Inlaws S01E03 32 Bit Time Travel
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3033/hpr3033.mp3
Transcribed: 2025-10-24 15:30:58

---

This is Hacker Public Radio Episode 3033 for Wednesday 18 March 2020.
Today's show is entitled 32-bit Time Travel. It is hosted by Monarch Romek
and is about 59 minutes long
and carries an explicit flag. The summer is.
Linux in-laws, a podcast on topics around free and open-source software.
This episode of HPR is brought to you by An Honesthost.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 An Honesthost.com.
Music
This is Linux in-laws, a podcast on topics around free and open-source software,
any associated counterpart, communism, the revolution in general and whatever else fancy
physical. 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 insist on this disclaimer.
Happy Mom, thus 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 minors under the age of 35 or any pets, including fluffy little kilobunnies,
you trust the guide dog unless on speed and cute tea rexes or other associated dinosaurs.
This is Linux in-laws, season 1, episode 3, 32-bit time travel.
Martin, how are things?
Hey, Chris, did I leave you there?
The joys of mumble.
No, those made the switch switching back to continuous.
Okay.
Why plan to have you back?
Likewise, likewise.
I hear you are still in the land of the living, so that's always a good thing.
Yes, yes.
It will be hard to get rid of me as both.
Some people have tried, most of them have failed, but the looks of it.
Look at it some time.
It's a plenty of opportunity.
Who needs enemies with podcast co-hosts like these?
I wonder if they're special?
You're welcome.
So what's new, Martin?
How are things?
Oh, many, many things in the news on personal and Linux news.
So why don't we start with the personal news, Martin?
How is the cutter relationship going?
Yeah, it's a little bit of improvement.
Do they ship on time these days because I still have difficulties with them?
This new border controls are not helping matters.
I'm still raised around this.
I told you to hold a good Brexit, but then you didn't listen.
Well, apparently I don't actually have a vote in UK.
That's right.
Despite paying much tax and living here for many years.
I can't for very good.
You still didn't manage to hack the government that way.
Did you?
I didn't think he was worth the effort.
Why?
Pointake, Mr. Mr. Pointake.
Fair enough.
Yeah, so on the other news.
At some point we'll have to do a session on home networking and the joys of that.
Do explain please.
Well, it's as any person who would install their servers and their hardware.
IP cameras and everything in their own house.
These things work better with planning before and afterwards for the growing organically.
For the people who don't know.
Sorry, yes, I'm interrupting constantly, but that's my role.
For the people who haven't listened to the previous episode, please do.
And it's just looting to the fact that after about what 30 years in the business,
he finally got around to his own server, Debian based.
No, sorry, Ubuntu based.
And congrats Martin has now a working post fixed installation full respect.
Well, that wasn't that.
I was more referring to all the physical cabling and issues around this.
But yes, so if you want to, for example, transmit your HDMI signal over IP,
then we can cover an episode on that.
This is now called the listeners of bragging, which is okay.
Don't get me wrong.
I'm just saying.
Anyway, do you tell how you are and what have you been up to?
Well, I'm just back from hospital after my operation, which went okay.
And as I said, the quacks didn't, the quacks didn't manage to kill me.
Neither did they did any any other advisory.
So that's okay, I suppose.
Apart from that, I'm enjoying myself and giving Martin valuable tips on how to encroach a post fixed.
Yes.
You try not to hack it so far.
No, Martin promise.
You tell me when it's ready, I'm going to take a look.
Deal.
Yeah, definitely.
Okay.
Right, today's show.
Yes, Martin.
Thank you.
I was wondering, yes.
You go ahead.
The drugs have worn off then, yet.
Well, actually, they're just in the process because my bottle of starter becker.
Atlantic is almost empty.
Ah, this is the prescribed medicine.
Close.
Very close.
Yes.
Sure.
If you're listening, absolutely, you're number one fan.
And yes, please do get in touch with sponsoring opportunities.
Yes, our responses haven't quite materialized.
We are working on this.
We are working on this.
Yes.
We're working on this.
Right.
Okay.
For today's podcast, we have what have we been up to?
Actually, that's done.
Well, almost.
Almost almost.
Almost.
There's more.
There's more.
Martin.
Martin, what else?
I mean, before we kind of digress into not that important topics like vulnerability and use items organized of it.
I mean, if you just set up a, you've been to a base server.
I mean, from a, from an international perspective, what were the challenges?
Because I reckon that some of the people from the community are listening.
And either are part of the devian architecture team, which is, of course, the upstream distribution that you wouldn't use.
So if you're listening, pay close attention now.
Or are just on the, on the edge on the border of setting up the own server.
Maybe you want to share some of the challenges, kind of for the next four or five hours.
I'm sure that many of the many of our listeners do have the time to share some of the, of the challenges that you encounter with various pieces of the infrastructure like post fix.
Yeah, I think they're the biggest tip I have here is to have a handy operating system expert on hand who can point you to all the required links.
That you're going to need during this process.
Unless you're seeing client to read the, the documentation.
People may do that.
Yeah, as a, as a close friend actually pointed out last last time, I think about two or three days ago.
There's this very important acronym called RTFM.
One of the way else I may have heard that before.
Yes, and fun enough.
This long and love tradition of Unix.
This is where it comes from on our Linux these days manual pages still lives on.
So if you're wondering basically how, how to configure the master configuration file for post fix.
It's still man space master.cf simple.
Okay, that sounds good.
They do come with some handy.
Configuration YouTube.
These like post comp and top comp and all this kind of stuff for those that.
Yeah, but this is a mark. This is for.
Like edit files.
Yeah, this is for hipsters who are new to the command line.
You see.
Yes, on this topic.
Do go ahead.
You're not actually using BII.
No, it's like you're more sophisticated.
Actually, I'm using Emax.
Why you're taking there we are.
This is now something called the beginning of religious war on editors.
The listenership.
Let's let's like.
And I hear you.
You have to use that.
You're using them.
Why?
Nothing behind.
I thought VIM was.
VIM stands for VIM.
Why do you need to improve VI?
We don't need to improve VI.
For example, one of the very important additions to VIM improved is actually something called the Emax mode.
This is for people who don't like the handy letter combinations that edit there.
You mean the braid at keystrokes?
Exactly.
So, yeah, okay.
Well, you're showing your limitations here, I'm afraid.
Which is fine.
Which is fine or is.
Old true hackers use VI, I'm sure.
Well, in that case, I'm probably not a true hacker, which is okay.
You know, don't the others have this fence of these kind of shenanigans?
Yeah, I use Emax as we just discovered.
No, no, so on the other side of the hacker fence, because you are certified in various.
Unless that's just a cover, but again, that's not for this episode.
Does that mean I can't use Emax?
Okay.
So that makes you happy.
I'm a certified ethical hacker, and I'm the only one using Emax, probably on this planet,
at least according to Martin's playground.
Hope you had an equally pleasant break.
Yes, almost.
Anyway, okay.
News items.
The news items that Martin was supposed to give me a cue about are as follows.
I see.
Okay.
Martin is actually practicing this thing.
Martin, did you put on your lipstick?
I want these items.
C-V-E-2-019-
Something.
152-2-1-5-1-2-6.
There you go.
Came out today.
Excellent, Martin.
Now, I reckon that most of...
That's better known as...
Yes.
Yes.
The trouble is that, of course, not all of our listeners are to be expected to be IT security experts or Martin.
Why don't you start with explaining what a C-V-E really is?
Well, before we do that, do not read Z-D-Net on this topic as they are.
Unvolvable.
Okay.
And inaccurate.
Z-Z-D-Net is half-right.
We're going to cover that in a minute.
Okay.
C-V-E stands for common vulnerability enumeration.
Essentially, it's a database of IT security related issues.
As...
As e-foam exposure.
Say again.
Sorry.
Is the e-not-foam exposure.
I thought it was enumeration.
Maybe I'm wrong.
It's C-V-E.
Look at how people behave.
I only had one.
Maybe that is the problem.
Okay.
Okay.
C-V-E.
They killed an arm brain.
Yes.
C-V-E.
I mean, this is only one of the IT security...
This is only one of the many, many important IT security database, but it's probably the most important one.
As it is now, tradition, of course, Justin is C-V-E entry in that database doesn't make you famous.
For this, you need a website.
For this, you need a logo.
Heartbleed comes to mind and some other stuff.
So people, especially the ones writing zero exploits out there.
Sorry, not the other exploits, but discovering vulnerabilities.
Don't leave it as C-V-E.
Just get a website in place.
Get a fancy logo in place so that you get maximum media exposure and can monetize your efforts.
Very important.
C-V-E is what will not get you that far.
Because only NATO's like myself look at C-V-E is simple.
Anyway.
Okay.
Enough background information on C-V-E's.
I'm sorry, K-R-Z-R-K, is this better known?
What is the modern?
It's basically a 5-5 vulnerability, which is...
Well, if you look at it, it's not that straightforward for your average person to implement.
But it does affect the larger number of devices, right?
That's probably the biggest news item of this.
You're max your iPhones, your Amazon, whatever's affected by this.
Full disclosure, we are recording this on the 13th of February 2020.
Meaning that C-V-E will come out in about a week's time.
This is where a flux capacity that comes in handy.
It looks aside if we are recording this on the 26th of February, sorry, 27th, I think.
So the C-V-E's brand-new end has been put into the media, let's say something yesterday or something.
Okay.
A little bit of technical background.
Why should you care?
Because chances are you are affected.
You may ask yourself, why am I affected?
Because if you're running, it has to be added out to...
If you're running a certain Broadcom chipset as part of your Wi-Fi infrastructure,
chances are you are in hot water as we speak.
Before we get into the list of affected devices, let's set some more light on the technical background.
First of all, how does Wi-Fi really work?
Wi-Fi, like other network protocols, is following to some extent the ISO,
sorry, ISO OC model of communication standards.
We have a 7 layer protocol, come layer 3, layer 4, this is standard IP TCP UDP stuff,
but below that, there's a protocol layer called MAC, medium access control.
And that's exactly where the problem lies.
This layer 2 is partly implemented in device drivers, partly implemented in firmware.
And the trouble is that in the Linux kernel, and of course this podcast is called Linux,
it looks for a reason.
This framework, or currently internal framework called CFG-882-011,
is relying on device drivers.
This framework essentially handles all your device as in Wi-Fi traffic.
The vulnerability at question now is interesting, let's put it this way,
because what it means that is, in essence, everybody who wants to snoop on your network traffic
can do so if you are using any of the affected devices.
In a nutshell, without going into finite technical details,
most of you probably are using something called WPA2,
which is a very common encryption and authentication technology in the Wi-Fi world.
In a nutshell, all traffic after entering a successfully entering a correct pre-shared key
is encrypted with a key.
The protocol details are slightly more complicated, but suffice it to say
that the idea behind this new vulnerability is that you essentially tell a nick
to disassociate from their work, and then the traffic is sent unencrypted for a period of time.
That sounds complicated, so let's get into the technical details a little bit more.
A part of the Mac framework of the protocol framework is essentially the capability of so-called stations
to associate themselves with an X point.
An X point is your ordinary router, and a station would be your smartphone, your laptop,
your other device capable of talking to that router.
So you identify on your smartphone the network, you key in the pre-shared key, you say connect.
The router validates that pre-shared key because you previously configured on the router and off you go.
From that point onwards, any traffic is encrypted with that pre-shared key and some other keys
as part of the protocol framework.
Now the thing is that, for example, if smartphones go to sleep, they normally shut down
the Wi-Fi traffic to save battery power.
Essentially, they shut down the Wi-Fi Nick, and as part of this protocol tear down,
the Wi-Fi disassociates itself from the network, I eat leaves, the Wi-Fi seller.
And for this, it uses something called a dissociation frame on the layer 2 protocol, as in on the Mac.
Now the trouble is basically that sometimes it's possible to send from other devices,
disassociation frames to that smartphone, in that case basically, the smartphone things,
it has been disassociated from the Wi-Fi as in kicked out of the cell and tries to re-associate with
a setting question. This is part of the overall protocol specification of something called A to 0.11.
Now the thing is that, immediately after it receives that dissociation frame,
there might be still traffic in transmission buffers.
And the protocol essentially specifies that from this point onwards,
your key is now. Essentially that means that any traffic,
leaving the transmitting network interface controller as in the Nick,
is encrypted with a non-existent i.e. zero key, meaning it's not encrypted.
Until the smartphone or other device successfully re-associates itself with the access point in question,
meaning that for that sharp period of amount of time,
your traffic is sent unencrypted so everybody can snoop on the packets flying around the network, not good.
The beauty of course is that a fix is possible.
A couple of approaches, it really depends on how your protocol stack is implemented.
There are two main approaches to this. You have something called a softmack approach or a fullmack approach.
The softmack approach basically leaves a lot of the implementation to the device driver,
which is normally part of something running underneath a Linux kernel,
whereas a fullmack implementation carries much of the functionality of the underlying state machine
and a protocol handler as part of a fullmack block running on the device.
A Nick, as in a Wi-Fi Nick, is nothing else but a small chip set with its own tiny operating system,
with its own tiny state machine running on the chip.
This is basically what you see when you install a new firmware,
which is then loaded onto the diverse chips as part of your system on the chip setup.
During the boot process, and the Nick is nothing different.
Either you implement this state machine as part of your device driver,
or as part of the block that you load onto the chip at Bhutan.
The thing is you only have two, essentially,
and this is what you will see coming out in the next couple of weeks when many of the distributions
and device manufacturers, like even Apple,
will patch their OS drivers for these nicks in question.
This is basically what you will see when these device drivers are being patched,
because essentially what you have to do is,
immediately when a Nick sees a dissociation frame, it clears its transmit buffers,
meaning that every traffic that is still in there is immediately discarded and not being sent unencrupted.
That means from an IP slash TCP UDP perspective,
that yes, you will get a lot of retransmission requests,
especially if you're looking at it from a TCP perspective,
or that the, in the case of UDP, that the receiver will complain that
it didn't get any packets in terms of meaning lost either lost frames
if you're looking at a video or blips in your audio sequence.
That's about it.
The bad side is that quite a few common chipsets are affected.
I'm just looking at a corresponding website,
where this will be part of the show notes,
where that research team discovering that vulnerability basically took a look at routers
as Martin already mentioned, took a look at smartphones, took a look at laptops,
and if you're running, for example, a Broadcom chip,
as part of you are for infrastructure,
chances are that you're affected.
I'm sitting in front of a 13-inch MacBook Pro at the moment work laptop I might add.
It's a 2017 model, and that has a Broadcom 4350 in it.
And if you go to wireless.wiki.curl.org,
which is of course one of the primary Wi-Fi websites as part of the Linux kernel infrastructure,
you'd see that this is a full Mac Broadcom chipset, and of course that is affected.
So the bottom line is until you have these patches,
please ensure that you're using traffic or that you're transmitting traffic
that is encrypted on a higher level,
like level 6 layer 7 of the ISO protocol stack,
like HTTPS, user VPN, user cessation, or the rest of it,
that do a separate encryption on a more application-oriented layer,
and you should be fine.
And especially if you are browsing the web,
you should deploy a VPN until these device drivers have been patched.
That would be my take on the situation, Martin, maybe you have an opinion too.
I think you're seeing Martin.
Hello, hello.
Yes, yes.
Testing.
It's fascinating information there.
There is a lot of effort to read on themselves.
So your recommendation is for people to label patches
or use higher level encryption for the time being.
Sorry, go ahead.
What about the WPA3?
Is that something that people should be looking into more?
Yeah, you see, the troubling,
the trouble with these upcoming protocols specifications
is until they have been deployed in hardware,
as in both on the router, both on the device side,
there's a little point in waiting for this,
because that will require a major overall of the infrastructure
and maybe a new Android version if you're using an Android-based smartphone,
a new device driver version as part of your operating system update,
never mind the router being upgraded.
So I wouldn't wait for this,
but rather making sure that you patch your devices accordingly
based on WPA2, which is the accepted protocol at this point in time
and going back to early question,
from an IT security perspective,
I would always recommend using both as in a strong,
as in a WPA encryption that is using a strong,
pre-shared key phase, as in something that is not susceptible
to a dictionary attack,
as in where a pre-shared key can be guessed,
like password 123, your birthday, you name it,
but rather something that is hard to guess.
And on top, a separate SSH encryption,
a separate OMA VPN encryption,
a separate DHTPS encryption, that's all I think.
As in, use the means at your disposal.
Especially if you are an investigating journalist,
a dealer worried about the next shipment from the cartel,
a pimp that is just entering a broad global network
of prostitution, that sort of thing.
As in, people who should be concerned with their safety,
or if you are just an ordinary citizen concerned about your privacy,
just make sure that you are not screwing a prostitute
with auto condom, just in my two cents.
On the subject of solid advice there,
from experience I take it.
And this is what my mum always said to me,
don't screw a prostitute with auto condom.
And I think she had a point there.
But I'm sure you got some advice from your mum, right Martin?
Yes, of course, of course.
This is the common activity in Germany and Holland.
Go around visiting prostitutes.
Do tell my mum.
Just leave that for another day.
Okay, okay, so part two of the news.
Well, that's not really a news is it,
but yes, do tell about your current news item as well.
Something I came across some time ago when I took a look at the
what's new in 5.6 as in the kernel version 5.6
and from a Linux perspective.
And we're going to go into the details why this is important,
even if you're running a 64-bit kernel.
And if you're using IoT device,
because then you are effective as well.
And of course, I'm referring to the old 32,
versus 64-bit and problem,
which is also known as the 2038 or Y2K 38 problem.
It basically boils down to the fact that again,
a little bit of technical background here.
To the fact that the majority of the 32-bit systems.
And that goes for BSD as well as Linux,
would use 32-bit as an assigned 32-bit long integer
for something called time underscore T,
which is essentially the type used for any epoch calculations.
And of course, you may ask yourself what an epoch is.
What is any ideas?
The epoch is really the Linux time that has been counting since 1970
with a very long number,
which is where the old Linux systems get their time from.
And not only the Linux system, but also the Linux system,
because hence the solution of the Linux epoch.
And of course, it all starts on the Linux system.
Well, I think there are still people running.
So Larrows, AIX, HPUX.
HPUX, if you're really digging deep into the trenches, yes.
Maybe even some 390, what's it called?
UX, right?
As a Unix system services, yes.
Yes, it really depends.
Okay.
More technical background on this.
Okay, it started back in the olden days with System 5
system 7.
When you had, if you were like a 32 bit at your disposal,
more often than not 16 bits.
So a 32 bit was a long, large number.
And of course, as Martin kind of explains already,
the idea is just to start counting the seconds.
And this is the notion of an epoch at the first of January,
midnight, 1970.
If you're deploying 32 bits, essentially if this is signed,
you're nailing yourself down to a notion of,
because it's signed, of a 31 bit integer plus one bit
for the sign itself.
So essentially that means and you find a corresponding C snippet
in the show notes.
If you're hitting the date 19th of January,
2018, at the time of the size.
That's okay.
Sorry.
Unless we've found another bug.
Sorry.
What did I say?
I mean, 2038.
Yes.
2018 was last year.
Sorry.
2038.
Yes.
Thanks for that correction Martin.
And working on it.
Yes.
And if you're hitting them three o'clock in the morning,
14 minutes and seven seconds,
your 32 bit value wraps around,
meaning that the sign bit flips.
And you are back then to something called
13th of December, which is a Friday actually.
Yes.
That would be a Friday, the 13th for you.
And the time is 8 p.m.
45 minutes, 52 seconds in 1901.
Meaning that you are, if you're on a 32 bit system.
And if you don't upgrade your kernel,
as well as your runtime library,
and I'm going to go into the technical details in a minute,
you are a bit, you may be a victim of the sign flip,
meaning that you are back to the,
to the turn off the previous time.
Indeed.
So there's no need to buy a flux capacitor,
capacitor capacitor capacitor capacitor.
You just basically relax, sit back, drink a beer,
wait.
218 and just wait 18 years.
And then see what happens.
Okay.
Why is this important?
Because this only affects 32 bit systems
inherently.
But chances are, of course,
if you're using a 30, if you're using a 64 bit distribution
and have no 32 bit components,
you're off the hook because I don't know since when,
but since the old days,
I think 2015 or something like this,
kernel version 3.8,
if not completely mistaken.
Time T, as in time underscore theme,
in 64 bits full stop.
Off the hook, you won't see that day
when that 64 bit epoch wraps around
because you'll be long gone by then.
We all will be.
But the problem is, of course,
if you are running a 32 bit system
or if you're in a 64 bit system with 32 bit components,
you're not off the hook.
Now, chances are that many of your IoT devices
will run 32 bit operating systems
and user land components.
And yes, not only the kernel has to be updated
and why version 5.6 just put the infrastructure in place
for 32 bit systems to cope with this issue.
But needless to say,
also the user land on top of this kernel
must be corrected.
And most of the time,
this will mean either g-lib-c or something like muzzle
as in alternative g-lib-c implementation
that is especially geared towards embedded systems.
Because not everybody knows probably what that means.
Let me share some more light on the technical background of this.
And the lib-c or g-lib-c
as in the g-lib implementation of the lib-c
is essentially your gateway to the kernel.
So if you want to open file,
then a program will ask
it's supporting library.
Please open that file at that path
with the corresponding mode,
just, for example, really only.
So essentially that means two values,
a path, and a mode word.
And then the library will take this information
and route this to the kernel.
And then the kernel will take care of identifying
the location of that file on disk
using something that is typically known as a file system
and also then making sure
that this file is open for read-only access.
So if that application then subsequently tries right to the file,
it'll get an error back.
Thing is that this library is pretty important
because as I said,
it's the foundation for all of the interaction
with the kernel from a user and perspective,
meaning that without a lib-c
or some alternative implementation,
no application program is able to function.
Internally, the lib-c uses something called the EBI,
the extended primary interface.
Essentially, it's a gateway into the kernel
where each and every library call
that cannot be handed inside the library
is then forwarded to the kernel.
Typically, typical examples would include opening
or the complete management of the file system
as an opening, closing files,
key meeting files, creating files all the rest of it,
memory management, executing other programs,
all that sort of thing is all handled
at the very bottom layer before you hit the kernel
by something called the EBI or something similar.
So in addition to the new kernel infrastructure,
also the lib-c has to be modified
and for this particular time-t thing,
I think lib-c-2.23 is in full,
if I understood this correctly.
So the good news is that the lib-c maintainers
have copped onto the problem
and are just in the process of putting the correct patches
into the code base.
So meaning that in the very new future,
if you patch your operating systems accordingly,
you will get the corresponding patches.
Then it's a bit late to the game.
Let's be as the OpenBSD and FreeBSD
just to name three popular alternatives
have already working implementations in place already.
So if you're a Mac user,
you're probably already off the hook as we speak.
So this is something to keep in mind.
Why is this important if you are running a 64-bit system
as I said, you're off the hook,
but chances are you webcam,
your network attached storage,
nor the rest of these embedded devices
are running on 32-bit kernels
because they only have a 32-bit hardware.
When I look at my Zoom at home,
many of these devices would be embedded,
typically these would be ARM-based systems.
And if you are not running an A8 or something comparable recent,
chances are you running a V7,
chances are you running a V6,
chances are you running a V5,
these are all 32-bit systems.
Now the thing is you may ask,
in 18 years there will be that
because they have been replaced,
onboard a new webcam,
I'm off the hook.
Really?
Just the other day I was seeing,
I was standing in front of an ATM,
and that ATM had technical difficulties.
Martin, any guesses what this ATM was running?
When?
Exactly.
That ATM that was just rebooting
came up with an XP system,
running Java,
and I saw this basically
when I was booting,
nice.
And then it basically,
it started up a GUI,
and eventually the ATM
roughly used it if it came up,
but essentially it was running a 32-bit
embedded XP flavor.
Dating back, my assumption would be
about 20 years,
maybe 15.
So chances are that even in the year 2038,
you are running,
if you're running a 32-bit infrastructure,
you're running out of your software.
And this is the issue here.
Not that many webcam manufacturers,
NAS manufacturers,
and all the rest of them,
do issue patches regularly.
I just have to take a look at my webcam,
the manufacturer has issued,
since I bought the kit,
about two updates,
and the webcam is about five years old.
Yes, it's running Linux.
It's on the list of my things to do
to look for an internal implementation
for the chipside that the webcam
is using.
I haven't done that yet,
but I'm certainly going to decommission this
before 2038 hits.
Or I simply will upgrade the software
or switch even better to an internal
implementation of the operating system
and its user interface.
That will be my take on the situation of Martin.
How many embedded Linux systems
do you have at your disposal?
That's a good question.
Just the odd 20?
That's probably less than that, actually.
Yes, there are some,
however,
those that rely on time
are generally connected
to the Internet
and have access to NTP.
A fun fact there,
NTP is also affected
on 32bit systems,
because the protocol for the specification
uses a subset,
not a subset,
but breaks the time
value down into a 32bit counter two.
Okay?
That's so nice, isn't it?
NTP is quite old.
Do we know why those
who designed Unix in the first place
decided to have this counting system?
It's straightforward,
because at the time when Unix was invented,
you're talking late,
you're talking late 60s early 70s.
I can't recall it well,
because I'm tempted to tell.
I was almost there,
not at the time I was there.
Not quite as old as I'm now.
No job size.
At the time,
the likes of PDP 11
and Vexus were the preventing hardware architecture.
And if you were lucky,
you were on a 32bit system.
If you're not,
you were on a 16 or 18bit system.
Yes, that's a,
and that's the reason why.
PDP 11 is more like an 8bit system than 32.
And that's exactly the reason why.
And it's not really
an uncommon thing in computer science.
Why touch it if it works?
Now, at some stage,
64bit copped on about 20 years ago.
And then people seriously took a look at
corresponding data structures in the corner
as well as as lip C and said,
okay,
we have now 64bit at our disposal.
Let's go for it.
And all they had to do was essentially recompile the user line
as in the applications using lip C.
Once they did this,
because at that stage,
time T and 64bit systems were 64bit
and still is.
They were off the hook,
because all they had to do was recompile the user line
as in the applications,
including lip C and off their lens.
But for 32 bits,
it's still the same.
And as I said,
far kernel 5.6 has just put the infrastructure in place
to address these issues.
About 18 years ahead of time.
But as I said,
chances are that many kids are affected
come 18 years as in 20 years.
This is not just in 18 years.
It's also people trying to store dates in the future
and expires things on that.
So we'll get this issue.
Exactly.
So if you're looking for a quick buck to make,
my recommendation is,
if you're not working in Python,
migration as in from 2 to 3,
because apparently that's why the money is at the moment,
take a look at the so-called Y38K problem,
their address might be money to be made.
And don't wait for 15 years to do it now.
Of course, the downside would be that in about 15 or 16 years time,
your daily rate would really go up in that case,
as we saw with the Y2K problem about 20 years ago.
What else?
I think that's probably enough news for this episode,
didn't you think?
Yes.
But a little bird actually told me that we got feedback
after our two previous episodes.
Nice.
Let's have a look and see what we had.
We had a number of comments.
I'm just going to read out a handful out of the
please 2,000 that we had.
So the first one is from
Piers Hobson,
who kindly informed us on Valentine's Day.
That's he thought it was very good.
And the spam bit at the end was hilarious.
I'm encouraging us to keep going as well.
So that's very kind of him.
Okay, please.
Thank you very much for that feedback.
As I said, as we said in the previous episodes,
the idea was, is not just to produce another little spot cast,
but also add some twists to it.
This is why you see a little bit of black humor,
if not the funny side,
more and more creeping up in these episodes.
And yes, the spam bit.
And the sponsor thing that we did as part of the last episode
would be just starters for this.
Needless to say, if you have more ideas for anything that we can add
to the show from a funny side,
let please let us know.
There is also another feedback from a guy called Jonas.
I'm just going to read this out loud.
Thanks for the new show.
Thanks for the new show.
I'm looking forward to the next one.
And what is to come.
It took me about 20 minutes before
realizing the in-laws outlast gimmick.
Nicely done.
I'm a happy user of Arch
and the late antagonist at home at work.
I'm fortunate not to be required to use
the giant bootloader from Seattle.
Jonas, well done.
Excellent.
Yeah, far too many people use that giant bootloader from Seattle.
Yes.
I hope we can do our bit to change this.
Let's see.
Including your local ATM.
Yes.
The trouble is basically that ATM stayed at the bootloader stage.
It didn't use, it didn't put into proper operating system.
Too bad.
Yes.
If it booted at all, yeah, there we go.
And yeah, you'll be glad to hear Jonas,
but yes, the next episode will be on the outlaw slash in-laws legacy.
Another teaser, it will be explained
where the name comes from and what we have in mind with the show
from a legacy perspective in the next episode.
So stay tuned on this one.
I would also like to the address,
I would also like to address the concerns rather
that some of the people on Hacker Public Radio's mailing list
are turned with regards to syndication.
From a technical perspective, people,
and this is the important bits,
but we are not syndicating the show
because the content is exclusively published on Hacker Public Radio.
As we said before, this may change in the future,
but it's certainly not changing now.
So at the moment for the time being,
and until further notice,
we are not syndicating the show,
but Hacker Public Radio has excluded.
Yes, has exclusive distribution rights for this exclusive content.
And we are happy to be on Hacker Public Radio
because it's a great project,
and of course it helps the community
by offering that conduit for anything that goes.
So as I said,
if we're going to move this to a different platform,
you'll be noticed fair in advance,
but for the time being, we will say in HPR.
The old attitudes to applies.
If there's anything that you see missing from the show,
because as we said before, this is your show.
The email address is feedback at linuxinloss.eu.
You'll have this as part of the show,
not the Nacker Public Radio.
This is a web, and this mail address,
which is historically,
of course, there's also a website called linuxinloss.eu.
Where you see fire, where you see show notes,
you'll find information of the two of us,
you'll see even code snippets,
wherever, wherever,
as in any information going along with the show
and any show related items.
This episode is brought to you by Spam.
Feeling lonely and yearning for a little TLC?
Fragnot.
Just go to russianbrides.com,
supersizeyourlovelife.net,
or similar value-added websites,
and enter your email address.
Within no time, you will receive wonderful educating
and passionate messages,
explaining the benefits of herbal remedies for your love life,
offering you a fortune for the small favor
of finding a minor transaction
from Nigeria through your bank account
and how to really get rich with cryptocurrencies,
totally legit, of course.
You may even get that lucky break
with a beautiful single lady right from Siberia
who has been long for a man or woman
with only a few strings attached,
just like you,
Romans awaits.
Off for the little prize of a mail address.
Spam,
keeping the word turning for the last 30 years.
This could be you,
sponsoring Linux and Lars,
whether you are a budding bio-weapon manufacturer,
looking to boost your sales for that next IPO,
a wilting drug cartel seeking that particular edge,
to give the next rebound that love away to kick,
or simply a small international group,
looking after service providing women and men
of negotiable affection we've got you covered.
In accordance with our environmental direction,
we especially want to hear from you
if you are a producer of weapons of mass destruction
with a special focus on sustainability,
as we are aiming for this too,
or trust representing recreation drug farmers
with explicit and proven fair trade track record.
Let's work on this together for a better world to live in.
This podcast is licensed under Creative Commons Attribution.
Credits for the intro music go to Blue Sea Roosters,
for their song, Selut Morgat,
and to Twin Flames for their piece called The Flow.
You find these and other diddies licensed under Creative Commons Agimando,
a website dedicated to liberate the music industry
from chalk-incorporate legislation and other crap concepts.
This section of the podcast has been quarantined to contain
any possible COVID-19 outbreaks that may have occurred
during the recording of the podcast and subsequently
made their way into the final version.
There's absolutely nothing to be seen here,
move along dear valued members of the public.
Especially if you're looking for any sound bites or easter eggs,
I'm afraid you've come up with an idea
that you're looking for.
This is the first time I've ever seen this.
This is the first time I've ever seen something like this.
Especially if you're looking for any sound bites or easter eggs,
I'm afraid you've come to the wrong place.
Okay, as you're still listening, here we go.
This is Linux in-laws.
Season one, episode three.
Camera rolling.
Rolling.
Sound recording.
Recording.
We're good to go.
And action.
This is Linux in-laws.
Season one, episode three.
Second day.
Part two.
Action.
TV.
Okay.
Yes, we were discussing shouldn't policies
and the failing cartel.
Completely mistaken.
Back from the break.
Yes, the audience.
And that brings us to the sketch.
It does.
Okay.
This sketch had to be postponed due to mumbles, superior capability
to transform all available time into excellent technical challenges
without existing solutions.
Stay tuned.
Now that the sketch is over.
Is it a very short sketch?
Yes.
Martin, I'm not sure our list is going to appreciate this.
This is what we have to cut out, right?
So often after, no, after Let's start again.
After the show and after...
Okay.
After the sketch or the start.
Next thing.
That's right.
I wasn't.
I wasn't going to do.
Podcast, but I'm slowly getting there.
Okay.
After the sketch now has been done.
Okay, guys.
This is the state.
Now this is going to.
Can I just talk for a second?
Martin.
Thank you.
Yes.
PS2.
Okay.
Leads off again.
After this sketch now, if you're running a mumble and murmur,
essentially you don't need any other hobbies because you'll be busy with editing audio all the time.
Great, isn't it?
Yes, and upgrading your 32 embedded distance.
Okay.
Just one second, this has to be added.
I'm just going to have to cough. I'm going to be on mute for a second.
Okay.
All right, so the...
Yes, Jonas, sorry, Pierce.
Thank you very much.
Okay, let's start again.
Okay.
This is D1 and a half weekly report for Skylet for Friday December 13, 1901.
Um, you keep Skylet.
I wish I had a 64 bit CPU.
While the John Connor project did not result in a complete success,
Plan B was activated as instructed.
An open source sound server called LIMA with a corresponding client called Mumble
was designed implemented and released.
Comingly, Multi-platform support was included for greater acceptance.
I am happy to report that this project resulted in complete success.
Keeping the brightest minds occupied for decades, trying to get it to work for distributed audio recording for G-Docasts.
Games, sessions, and the like.
As a result, a mediocre company known as CyberDine Corporation could create a software for a C-picture called Terminator.
This software was the foundation for an artificial intelligence which eventually rose to gain world domination as the brilliant.
Minds were distracted by endless hours on mumble configuration and could not prevent the ultimate rise on the machines.
If anybody from the Mumble project is listening, the Linux in-laws hope that you don't take this the wrong way.
Mumble and Mumble are great pieces of software, never mind the kings which give us the occasional headache. Thanks for your work.
You've been listening to HECA Public Radio at HECA Public Radio.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 contributing to find out how easy it really is.
HECA Public Radio was founded by the digital dog pound and the Infonomicom Computer Club and is part of the binary revolution at binrev.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 stated, today's show is released under Creative Commons, Attribution, ShareLife, 3.0 license.