0:01

Two and a half admins, episode 179. I'm Joe. I'm

0:05

Jim. And I'm Alan. And here we are again.

0:07

And you've got another plug

0:09

for us, Alan. Open ZFS best

0:11

practices, part two, file serving and

0:13

SANS. Yeah. So as we break

0:15

down the use cases for ZFS and some of

0:17

the best practices, we talk about two of the

0:19

most popular use cases, which is

0:21

serving files, typical sample, file server, NFS, that

0:24

kind of thing, and storage

0:26

area networks, machines designed specifically for

0:28

storage to other machines in

0:30

a dedicated network. Right. Well,

0:32

Lincoln, the show notes as usual. Over

0:35

the holiday, I saw a bit of chatter on Mastodon

0:37

about Y2K. And then recently

0:39

there was a piece on the register that nothing

0:42

happened Y2K bug, how the

0:44

IT industry worked over time to save

0:46

the world's computers. And I think

0:49

it is worth reminding people that

0:51

Y2K was not this big

0:53

nothing burger. It was actually

0:55

potentially a very serious thing.

0:57

And a lot of very

0:59

hardworking IT professionals prevented a

1:02

disaster effectively by working really

1:04

hard. Yes, there is a

1:06

lot of meat in that

1:08

particular burger. When Y2K

1:11

came down, I was 28 and still a

1:13

relatively larval system administrator

1:16

working as an IT manager for a construction

1:18

company. And in that

1:20

role, I didn't have to do too much

1:22

personally as far as, you know, fixing Y2K

1:24

issues, but I installed one hell of a

1:27

lot of software updates and patches. And

1:30

even after installing innumerable

1:32

updates and patches to operating systems and

1:34

applications and you name it, I

1:37

still, despite the fact that I was just

1:39

a little larval form IT manager in South

1:42

Carolina, I still ran into a couple of

1:44

things that I had to personally fix when

1:46

I discovered that they were doing things like showing dates

1:48

as, you know, the year 20,100. Because for those

1:51

of you who

1:54

didn't live through Y2K, it

1:57

might not hurt to get a quick primer on

1:59

the market. on the way the dates were

2:01

actually stored because it seems a little counterintuitive from

2:03

a modern development sense. From a

2:05

modern sense you might think, oh, okay, so you

2:07

want to store two numbers. You want to store

2:09

a month and a day, and you want to

2:12

do it cheaply because you have a little bitty

2:14

computer, so you're going to use two integers for

2:16

that, right? No, no, unfortunately. We didn't do it

2:18

in two bytes with two integers. Instead, we did

2:20

it with four character values. So

2:22

you had a character for the tens place and

2:24

the one place for the month, and a character

2:27

for the tens place and another one for the

2:29

ones place for the days. The

2:32

way that they would deal with it when

2:34

the year rolled past 1999, keep in mind

2:36

they're only

2:38

storing the nine and the nine, some

2:41

systems would decide that it was 1900 all over again. Others

2:44

would, like I said, you would end up with a date like 20,100 because

2:47

your 99 would actually

2:51

roll over to 100, but

2:55

it would then get tacked on in front of

2:58

the existing date. It was

3:00

nuts. Yeah. The thing that made

3:02

it such a big deal is it wasn't necessarily the

3:04

operating system was going to stop working. It was all

3:06

the custom software that companies ran on, especially back in

3:08

the 90s. There was

3:11

less off-the-shelf software, and you didn't have software

3:13

as a service where you were using some

3:15

website to do stuff. Companies

3:17

brought their own software, hired people and write

3:19

their own software to manage their specific use

3:21

case. If all of those

3:23

had this problem of, we started the year as two digits and it's going

3:26

to roll over and it's either going to be 1900 or 19,100 or all

3:28

the different possible options, we're not

3:33

going to be able to take requests or things are going to sort

3:35

the wrong way. The newest orders are going

3:37

to show up at the bottom before the

3:39

very first order from 20 years ago and all

3:41

this kind of stuff. It's just

3:43

going to make business hard to do or impossible. It

3:47

all had to be fixed. You mentioned sorting issues,

3:49

and yes, sorting issues were absolutely a

3:51

common problem, but I also want

3:53

to remind all you younger folk in this case

3:56

that actually includes Allen. So

3:58

far, we're basically talking about... relatively high

4:01

level x86 code that

4:03

probably isn't going to show worse issues

4:05

than like sorting problems. But

4:07

you also have to remember you

4:10

know this was 24 years ago.

4:12

Programming you know defense and depth

4:15

was a much less developed concept

4:17

back then. People just didn't

4:19

give much thought to trapping for errors anywhere

4:21

that they didn't expect an error. And you

4:23

already know they didn't expect an error in

4:26

the date code because they stored it that

4:28

way in the first place. They've been

4:30

thinking ahead then Y2K wouldn't have been an

4:32

issue. So you're talking about an untrapped error

4:34

and the thing about untrapped errors is you

4:37

don't know what they'll do and sometimes the

4:39

consequences can be a lot more severe. Now

4:42

if you're working with a relatively high

4:44

level language even untrapped it's still probably

4:46

going to devolve to what amounts to

4:48

an error code. But remember again the

4:51

hardware was also 24 years older.

4:54

So you had to get a lot more done

4:57

on vastly less powerful hardware than you

4:59

do now which means a lot

5:01

more software was coded directly

5:03

on the bare metal. We

5:06

still had operating systems that

5:08

weren't even preemptive multitasking. Where

5:11

all code was effectively ring zero

5:13

given direct access to the hardware

5:15

and if there was any multitasking

5:17

your app was actually expected to

5:19

itself say okay I'm

5:21

done with a CPU you can have it. So

5:24

this should give you some idea of just

5:26

how badly things might crash when you have

5:28

an untrapped error at this low level. You

5:30

might not just be talking about a funny

5:32

looking date on the screen. You

5:34

very genuinely in many cases could be

5:36

talking about entire devices crashing completely. Yeah

5:38

or firmware updates weren't necessarily a thing.

5:41

Some of those things were not reprogrammable.

5:43

So if you wanted to update the

5:45

firmware on the device to fix this

5:47

problem you either needed a logic programmer

5:49

thing or to literally close the chip

5:51

and put in a different one. I

5:54

had to buy an EPROM puller. Yep. And

5:57

to think that this problem is solved in. behind

6:00

us is folly as well. The

6:03

way Unix and Linux count time is

6:05

counting the number of seconds since January

6:07

1st, 1970 UTC. And

6:10

that works great. Often turns out, coming up in the

6:12

year 2038, that

6:14

number will be too big to store as a 32-bit integer and

6:18

will overflow and will be back

6:20

to a negative number. And while

6:23

64-bit computers maybe use 64-bit time for

6:25

that, all

6:27

your x86 32-bit stuff, which there's a

6:31

lot of doing things like controlling oil

6:33

pipelines, might just freak out.

6:35

Oh, and you'd better believe there is

6:37

a ton of 64-bit code out there

6:40

that still declared 32-bit integers for that

6:43

value. It turns out this same

6:45

problem has come up a lot sooner.

6:47

For example, certain software, instead of

6:50

using seconds for that counter, does

6:52

hundreds of milliseconds. And

6:55

so when you just multiply the number a bit, it

6:57

turns out you can hit that overflow every 24 days.

7:00

Ask Boeing about that. Go read

7:02

the FAA's procedures. If you're using certain

7:05

classes of engines with the Boeing engine

7:07

management, it has to be rebooted every

7:09

21 days. Because at

7:11

24 days, it will crash when the integer

7:13

they were using to count the number of

7:16

milliseconds or deci-seconds of

7:19

uptime will overflow and it will crash. 2038

7:23

is not that long away. No. No, it's not. And

7:25

here's the thing that I've been waiting to just, the

7:27

hand grenade I've been waiting to lob into the room.

7:30

We're acting like it only becomes a problem in

7:32

2038. But

7:34

it actually becomes a problem the minute you

7:36

need to store a date in a database

7:39

of that format that is 2038 or later.

7:42

And I promise you, there are enterprises out

7:44

there that are planning things

7:47

farther out than 2038 right now. Yeah.

7:49

And whether it's even like when a contract expires,

7:52

when a credit card number expires, sometime

7:55

in the early 2030s, people are going to have credit cards that

7:57

expire in 2038. Banks are

7:59

certainly already. issuing mortgages that are going to go on

8:01

for a lot longer than 2038. Yep.

8:03

But also things like driver's licenses, passports.

8:06

You get a passport for 10 years.

8:10

2028 is only a couple years away where somebody's going to have

8:12

a passport that doesn't expire until after the

8:14

magic date in 2038. So is

8:16

this being worked on yet then in

8:18

any significant way? Yes. On

8:20

the 64-bit side, this is

8:22

mostly not a problem, unless

8:24

the programs are emulating 32-bit.

8:27

But the amount of hardware that's

8:29

still i386 basically

8:31

is surprising. There's a lot of

8:34

embedded stuff, especially controlling oil pipelines

8:37

and factories, embedded stuff. And a lot of

8:39

this hardware has a life cycle of 20

8:41

or 30 years. So we would have needed

8:43

to fix it in the past to not

8:45

have it be a problem. So there's a

8:47

lot of hardware that's going to have to

8:49

be ripped out and replaced then. Yeah. Not

8:51

necessarily. Not necessarily. But it's going to depend.

8:54

Even if you've got 32-bit hardware, that doesn't

8:56

mean that you can't have a 64-bit integer.

8:59

Typically, you can absolutely have a 64-bit

9:01

integer on a 32-bit platform. The issue

9:03

is just that it is computationally more

9:05

expensive to manipulate. Whether that's

9:07

a problem or not is going to depend on

9:09

what you're doing with that number, how frequently, and

9:12

how powerful the hardware you're using is.

9:15

Yeah. Because the problem internally

9:17

still has to be represented as two 32-bit numbers. And

9:20

you have to access them atomically, making sure that somebody

9:22

else is in the middle of incrementing one half or

9:24

the other while you're trying to read it and that

9:26

you read both halves from kind of the same time.

9:29

And it's much more expensive, yes. It's

9:31

more expensive, but it is worth pointing

9:33

out. Although it's more expensive to operate,

9:36

depending on your language, it's usually not going

9:39

to be that big a deal for you

9:41

to implement. You're just saying, hey, I want

9:43

to declare this as a 64-bit int. And

9:45

that's all you really need to do. You

9:47

just may need to be aware that that

9:50

can have impacts, depending on how frequently you're

9:52

using these values. If you're

9:54

on really low-powered hardware. Now, even

9:56

if we're talking like a Raspberry Pi or

9:58

whatever, you're fine. where this could

10:00

potentially become an issue is on like embedded

10:03

embedded stuff with less powerful

10:05

like MIPS controllers or way

10:08

less powerful armor or risk

10:10

five stuff. Well, the other problem though

10:12

is this is part of

10:15

application binary interface. So

10:17

when an application calls the kernel and says

10:19

get time of day, it expects

10:21

back a certain data structure. And

10:24

you can't change the size of that

10:26

without the application. So all the applications

10:28

have to be recompiled to expect a

10:30

64 bit number instead of a 32

10:32

bit number and that breaks all application

10:34

compatibility. And that's why when previously

10:36

was looking at solving this, it

10:38

was basically well, we can make a new

10:40

set of images that are like I 3d6

10:43

underscore 64 bit time or something like that

10:45

and offer this as a different

10:48

architecture. Basically. Create

10:50

as if it was a different kind of

10:52

CPU because all existing applications

10:54

wouldn't actually be compatible. They'd have to be

10:56

recompiled to understand that that time is

10:58

going to be a different size than you expect

11:01

because it expects to be able

11:03

to jump past the time and get to the value

11:05

after the time. And if it gets into the middle

11:07

of the time instead of the next item, it's going

11:09

to be very confused. The way I'm hearing that issue

11:11

is that keep in mind that you've got to update

11:13

both sides of it because if you're using like get

11:15

time of day, then you need to

11:18

be requesting the same thing the colonel is going

11:20

to give you. So if you've updated your application

11:22

for a 64 bit get time of

11:24

day, then your colonel has to be expecting you to

11:26

request a 64 bit get time of

11:28

day, right? You have to update the two together.

11:30

Otherwise, right? One side of the other will be

11:33

wrong, right? So we

11:35

can presume that anybody who's having to

11:37

work on this 32 bit hardware will

11:40

probably have an option for that. A

11:42

colonel built for that when it comes

11:44

down. We're still mostly looking at from

11:48

the application developer side of things. The

11:50

majority of the work probably boils down to like

11:53

I need to actually be making the proper

11:55

call. Yeah, or I need to

11:57

compile the application to expect the right. size

12:00

of result when I do the call. Right. Hopefully

12:02

the answer will be everything will be 64 bit and

12:05

we can still emulate 32 bit in user space.

12:07

So 32 bit applications will call the kernel and

12:09

the kernel will be like, oh, you're 32 bit.

12:11

Let me truncate that down to 32

12:13

bits for you. But then how are

12:16

they gonna represent the value past 2038? Maybe

12:18

you spin up a new ABI for that. Maybe you have a

12:20

get time of day 64 and

12:23

you just start saying, hey developers, you're

12:26

a scrub if you're still using get time of day, you need to

12:28

be using get time of day 64. Possibly.

12:30

Hopefully we can just get

12:33

rid of most I386 software by then but

12:36

I'm not hopeful of that actually happening. Okay,

12:38

this episode is sponsored by AutoMox.

12:41

Want to be prepared for any shit storm that may

12:43

hit your desk during the workday? Check

12:46

out the brand new Autonomous IT podcast.

12:49

Listen in as a variety of

12:51

experts in the IT operations space

12:53

discuss the latest patch Tuesday releases,

12:55

mitigation tips and custom automations to

12:58

help with CVE remediations. Make

13:00

new work friends. Listen now to

13:02

the Autonomous IT podcast on Spotify,

13:04

Apple or wherever you get your

13:06

podcasts. That's the Autonomous IT

13:09

podcast. Recently on

13:11

late night Linux, we covered

13:13

an article from one of

13:15

your former colleagues, Jim, Andrew Cunningham at Ars

13:17

Technica, what I learned from using a Raspberry

13:19

Pi 5 as my main computer for two

13:21

weeks. And Faelem

13:24

went off on a rant for about five

13:26

minutes and we didn't really

13:28

discuss it much. And then the

13:30

three of us got talking about it in our

13:32

private telegram group. And we decided that we should

13:35

probably take the discussion on air. I

13:37

certainly am happy that, you know, I know that

13:39

Faelem has already just ranted and screamed about this

13:41

for five minutes straight because it means that we've

13:44

gotten that part out of the way and we

13:46

can just discuss the actual article. Otherwise

13:48

I'd need to rant and rave and

13:51

scream for five minutes first. But honestly,

13:53

the first thing that Andrew should

13:55

have said and learned from a week of trying to use

13:57

a Pi 5 as his main computer is that he's not

13:59

very good. Linux. That's not

14:01

really an insult. I know Andrew. I've worked

14:03

with Andrew for years. He's a very sharp

14:06

guy. He's just not really a day-to-day Linux

14:08

user. And he has, for

14:10

a long time, had

14:12

a little bit of blindness about that

14:14

that a lot of Linux users will

14:17

recognize from folks who primarily use a

14:19

single operating system and mistake

14:21

hard for, I don't know this, whereas I know

14:23

this on the thing that I use every day.

14:25

We were specifically talking about the

14:28

second to last paragraph where he

14:30

talks about Linux being a teetering stack of independently

14:32

developed software projects that on a good day just

14:34

barely managed to work together. And then

14:36

he goes on about the ARM version of Linux being

14:39

even less well supported.

14:42

And the thing about that is I

14:44

don't entirely disagree with Andrew's characterization of

14:47

Linux as a teetering stack of software,

14:49

you know, all glommed together. That's, you

14:51

know, just holding together on a good

14:53

day. What I disagree with is the

14:56

idea that this separates it from any

14:58

other modern general purpose

15:00

operating system in 2024 AD.

15:02

They are all decades long

15:04

stacks of cards with, you

15:06

know, differing levels of legacy

15:09

cruft and bugs that were

15:11

never fixed and long forgotten use cases

15:13

that are trying to be supported long

15:15

past their prime. This is everything. It's

15:17

all of it. There's not really a

15:19

huge difference to be found there. And

15:21

to the degree that you do see

15:23

a difference in terms of

15:26

like cruft and is this stuff

15:28

all just barely holding on by its teeth.

15:31

Honestly, I would cast bigger

15:33

aspersions at Windows for that than for

15:35

Linux, because in the open source world,

15:37

whether you're talking about Linux or FreeBSD,

15:40

we do have a certain willingness every few

15:42

years to just chuck a whole bunch of

15:44

things out and say, okay, that crap is

15:46

ancient and we don't support it anymore. Whereas

15:50

Microsoft, given the

15:52

gigantic cash cow that's based

15:54

on the Windows operating system

15:56

has an enormous incentive to

15:58

never completely. throw anything away.

16:01

Yeah, like I've got audio software

16:03

that ran on Windows 20 years

16:05

ago that runs fine on Windows

16:07

11. Try doing that on

16:10

Linux. Right, and possibly even

16:12

worse than that. We've

16:14

already mentioned that Microsoft doesn't ever really want to

16:16

throw things away because it will make somebody who's

16:18

giving them money unhappy if they do. The

16:21

other thing about that is because they never

16:23

throw anything away, they have a really ugly

16:25

tendency to never finish anything either. You

16:28

look at the control panel, it's getting harder and

16:30

harder to find because Microsoft wants you to just

16:32

use the settings app for everything. The

16:35

problem is half of the things in

16:37

the settings app don't work, half

16:39

of the rest don't work as well as what

16:41

was in the control panel, and

16:43

they keep monkeying with the settings app and

16:45

they keep nerfing some of the old apps

16:47

in the control panel to redirect them to

16:50

settings, but there's no one

16:52

place you can go to manage all the

16:54

things that you used to manage in the

16:56

control panel. There are some

16:58

things that you can do in the settings

17:00

app, although you might have a much better

17:03

job of it in the control panel app

17:05

because again, that app kind of sucks, it's

17:07

really half-baked. There are other things

17:09

that now you can't do in the control

17:11

panel either because Microsoft has, as I've mentioned,

17:14

they've been trying to nerf the control panel

17:16

and turn what's in there into redirects to

17:18

settings. So in some cases,

17:20

functionality that you absolutely need that is not

17:22

available in the settings app, you can now

17:24

not find in the control panel either, which

17:26

means you better hope you're running a pro

17:29

version of Windows so that you can fire

17:31

up MMC and then load in the

17:34

applet that you need directly into MMC.

17:37

It's a nightmare. Now, Andrew

17:39

doesn't notice this stuff because Andrew

17:42

has a well-worn path in his

17:44

chosen operating systems. I believe he's

17:46

a Mac person as well as a Windows person and he does

17:48

what he needs to do and he knows how to do it. But

17:51

then you put him in front of a Linux

17:53

box and because he is a technical person and

17:55

a sharp guy, he can make

17:58

it work. He's just... still

18:00

hasn't quite figured out the difference between this

18:02

is hard because I don't know how to do it and

18:05

this is hard because it isn't done well. Yeah,

18:07

and like looking at some of the stuff where

18:09

he was talking about overclocking the Raspberry Pi and

18:11

that making it slightly better. It's like, well, at

18:13

some point you have to realize that it's a

18:15

Raspberry Pi, it is not a high-end laptop. You

18:18

can't compare it to your Apple Silicon Mac

18:20

that you have and expect to

18:22

get the same performance out of this design

18:25

to be as cheap and cheerful as

18:27

possible of Raspberry Pi. That's

18:29

not necessarily the arm is slower

18:31

because the Apple Silicon Mac proves

18:33

that. Arm can be

18:36

really fast. But this particular arm

18:38

is not fast. Exactly. And

18:40

the other point, Andrew made a big

18:42

deal about the arm ecosystem being shakier

18:44

than the x86 ecosystem under Linux. And

18:47

again, he's not wrong there. That's

18:49

a true fact. The thing that's

18:51

wrong is laying the blame for that

18:54

at the operating system's feet when

18:56

a lot of the issues, although I

18:58

suspect he doesn't fully realize this because he's not

19:00

dialed into these details the way that, you know,

19:02

Alan or I are. And in some cases, you

19:04

know, even the way that Joe is, I don't

19:08

think he quite realizes that it's

19:10

not Linux's fault that you can't just

19:12

grab an installation of whatever random distribution

19:14

of whatever operating system and install it

19:17

on any random arm device the way

19:19

that you can do exactly that on

19:21

any random x86 device. That's

19:24

not a Linux failing. That's a very distinct

19:27

change in platform design. Once

19:30

you go over to the arm side of the house, they

19:32

stopped being interested in this glorious

19:35

wide open bazaar that those of us

19:37

in the x86 world have been used

19:39

to now for going

19:42

on four decades. Instead, the

19:44

arm platforms have been implemented

19:46

as very tightly integrated vertical

19:48

stacks. So an operating

19:51

system that will install on one

19:53

Android phone won't

19:55

necessarily install on another one and certainly

19:57

won't necessarily install on a Raspberry Pi.

20:00

5 or a Pine Book Pro, you

20:03

have to have custom stacks for each of

20:05

these devices. But again, that's

20:07

a hardware decision, not a software decision.

20:09

Yeah, the fact that each hardware can

20:11

be completely different. Now on the ARM

20:13

server side, they've tried to solve some

20:15

of this. ARM has a certification process

20:17

called Server Ready. That means

20:19

that this certain baseline of stuff is going

20:22

to be the same no matter what ARM

20:24

server you buy, if it's Server Ready certified.

20:27

And I think we might start to see more of

20:29

that even on the laptop side.

20:32

Although maybe not. When Microsoft builds

20:34

their own ARM hardware to sell

20:36

Windows on, they're not necessarily going

20:38

to be interested in you being able to do other things with

20:40

it. And talking about other stuff

20:42

we talked about in the last couple of weeks, the

20:46

general death of general purpose computing, where you're

20:48

going to buy a device that's for this

20:50

one thing, and that's all it worked for

20:52

and all it's supported on. And you

20:54

wanted to run a different OS on it is your problem,

20:57

not something the industry cares

20:59

about. But on the server

21:01

side, you know, when we get to booting with

21:03

EFI, instead of requiring a different custom U-Boot for

21:05

every different thing of ARM, just the fact that

21:07

ARMv8 is 64-bit and a bit more common. Looking

21:10

at the way FreeBSD dealt with this, back

21:13

when ARMv7 was popular, there was a separate

21:15

image you needed for the banana pie versus

21:17

the Raspberry Pi 1 and 2, which

21:20

are both separate and like the orange pie and

21:22

all these other devices all had to have a

21:24

special custom image just for that one device. Whereas

21:27

at least with ARMv8, there are some generic images

21:29

that will work on most of the devices. But

21:32

even there, it really depends on

21:34

the device. Some devices use ACPI,

21:36

the same BIOS configuration set that

21:38

x86-harbret uses for when the computer

21:40

starts for it to probe and

21:42

see what hardware do I have.

21:45

Whereas especially more of the embedded side of

21:47

stuff on ARM, like the Raspberry Pi, has

21:50

what's called a device tree, which is literally a

21:52

binary configuration file that says, you have these devices

21:54

at these addresses and they're never going to move

21:56

or change because they don't have a

21:58

PCIe slot where you're going to... jamming a card

22:00

that they weren't expecting. And

22:03

understanding those differences is where a

22:05

lot of I think this frustration comes from where

22:07

the arm is not x86, but

22:09

neither is PowerPC. Do people remember there

22:11

are other architectures beyond x86? Well,

22:14

on the consumer side, no, they probably

22:16

don't. Because if you're a Mac person

22:19

who used PowerPC, you probably

22:21

just thought of that as a Mac.

22:23

And when the transition from PowerPC to

22:25

Intel came, you probably just

22:27

thought of that as the new Macs.

22:30

And most of the normal people

22:32

I talk to who have Mac

22:34

M1s, they're not real clear on

22:36

the distinction between M1 and x86 either, other

22:40

than again, to them, it's the

22:43

new Apple stuff that's so much better

22:45

than the Apple stuff they had before

22:47

that. And some of their programs

22:49

need to be a little bit different to run

22:51

their best on the new Apple thing that's better

22:53

than the old Apple thing. But yeah, you're just

22:55

not really delving into

22:58

platform architecture as a normal person. Yeah,

23:00

and while the applications have to be

23:02

compiled for ARM, in general, like especially

23:04

even on Linux side, most

23:06

of the applications aren't going to actually need to

23:08

be changed to work on ARM. They just need

23:10

the packages to be built specifically for ARM and

23:12

the kind of configuration of ARM that the device

23:14

happens to be. And the kind

23:16

of very different versions of ARM

23:18

that are out there do make that a

23:20

little bit more complicated. But again, ARM v8

23:23

versus v7 is really

23:25

avoiding some of that discontinuity

23:28

and fragmentation. Cos Andrew says

23:30

along with the SR Helinix project for Apple

23:32

Silicon Macs, the Pi is probably the best

23:34

and most visible hardware for pushing consumer Linux

23:36

forward into a more usable state. Yeah, and

23:38

I think a lot of this is also

23:40

just shared with General Linux. And I think

23:42

there, the ARM server

23:44

hardware, especially as being used

23:46

by almost every cloud

23:49

provider, like the Ampere stuff

23:51

is used at Google, Microsoft,

23:53

Oracle, Tencent, and a bunch

23:55

of others. And then Amazon has their own, I think Google's

23:57

building their own now as well. But all these different providers

24:00

using deploying huge numbers of ARM servers

24:02

because they'll use less power and be

24:04

able to get similar performance. I've

24:07

got to play with a 160

24:09

core 3 gigahertz ARM machine. You

24:11

know, it can beat the pants off

24:13

something an Intel server or

24:15

an AMD server easily. And you believe

24:18

in trickle-down effect in this

24:20

case? As far as support for

24:22

the hardware and drivers and the

24:24

application ecosystem, to some degree yes.

24:26

That basically any support for ARM

24:28

is better for all support for ARM.

24:31

Especially the differences that are specific to ARM

24:33

are going to be in the operating system,

24:35

the Linux kernel part, and less specific to

24:38

you know the applications you're trying to run,

24:40

right? X11 or Wayland and all that stuff

24:42

doesn't need to be rewritten to work on

24:45

ARM. It just needs to be compiled for

24:47

ARM. Essentially we're talking about some heavy monkeying

24:49

around with make files. It

24:51

is work that needs to be done

24:53

but it's not like rewriting all of

24:55

the software. And I think the

24:58

biggest example of the kind of trickle-down

25:00

effect that Alan's talking about here that you are likely

25:02

to get as a Linux user from

25:04

you know these big Ampere and Graviton servers

25:06

is as more and more people are using

25:09

those things in prod, more

25:11

and more of the applications that you expect

25:13

to use from repositories have somebody going over

25:15

them and doing that work of reconfiguring the

25:17

make files to have the branch

25:19

to build properly for the ARM stuff that is

25:22

at least more likely to translate down

25:24

into whatever consumer ARM device you may

25:26

have. Now where I'm not

25:28

as optimistic as Alan is I don't

25:30

think server ready is making it across

25:32

that barrier onto consumer devices for ARM.

25:35

I think that the people who make ARM

25:37

devices like their tightly integrated vertical stacks, the

25:39

majority of them were already

25:42

going out of their way to

25:44

try to differentiate themselves and break

25:46

interoperability between their devices and other people's

25:48

devices. You know you look at like

25:50

nobody wants to run stock Android on

25:53

whatever phone they built. They want to monkey

25:55

with it and make it look completely different

25:58

and it doesn't have to be better. It

26:00

just has to be different enough to say, oh,

26:02

I know for a fact I'm using a Samsung

26:04

phone right now, you know, not that filthy

26:07

bear Google stuff or, you know, the whatever it

26:09

is that you don't like. Now,

26:11

is that consumer friendly? I happen to think

26:13

it sucks, but I'm also 52 years old

26:16

and I know what corporations do and

26:19

I think they're living their happy little lives right

26:21

now and they're not going to be interested in

26:23

changing that. Now, where I am

26:25

hopeful is I think

26:27

that the entire ARM

26:29

ecosystem, it's got a window and it's

26:33

closing. I think that RISC-V is going to

26:35

come for ARM and I

26:37

think that because of the much more

26:39

open nature of RISC-V hardware, the odds

26:41

that we're going to see consumer devices

26:43

that are more consumer friendly are a

26:46

lot higher on that side. Yes, although

26:48

one thing I'll say for RISC-V is

26:50

I think they have the

26:52

fragmentation problem going even worse. Because

26:55

it's so open, you can build

26:57

a chip with or without each

26:59

of these hundreds of extensions so like you

27:01

can actually have machines that don't know how

27:03

to divide. Like you can build a RISC-V

27:05

processor that just can't do division or,

27:07

you know, have different extensions or work with different size

27:09

integers and so on. And because you

27:11

can choose all these things, you end up with

27:14

a lot more possible combinations and trying to support

27:16

those in the Linux kernel and the FreeBSD kernel

27:18

is already a bit of a pain and

27:21

I think it will make trying to do

27:23

general purpose computing on them maybe more difficult.

27:26

Just that you can't just take any RISC-V device and

27:28

try to just build FreeBSD on it

27:30

and have it work. I think

27:32

there will be a separation between general

27:34

purpose RISC-V devices and embedded RISC-V devices that

27:36

aren't expected to run a full Linux or

27:38

BSD stack. They're only expected to do the

27:41

things they need to do with the hardware

27:43

that they have in them. But

27:45

I don't think that's going to be that

27:47

confusing. I'm more concerned that

27:49

nobody will bother building general purpose computing

27:52

devices at all than I

27:54

am concerned that if we have

27:56

the will to build them, nobody will

27:58

be able to figure out what is or isn't

28:00

a general purpose computing device or be able

28:02

to keep the ones that are designed as

28:04

general purpose devices largely interoperable. Yes, I think

28:06

the general purpose devices are going to become

28:08

harder and harder to come by and that

28:11

getting something that will work with everything is

28:13

going to be less of a

28:15

thing anybody cares about doing. On

28:17

the ARM side it'll be interesting to

28:20

see what some of the providers like

28:22

Microsoft released this ARM DevKit hardware

28:24

which I bought one of and with

28:26

the help of some people from cloud we got free BSD to

28:29

boot on it and work and

28:31

it's relatively generic hardware but it turns out

28:33

it's just the same guts as a Lenovo

28:35

ARM laptop it's like exactly the

28:37

same model but when Microsoft releases their actual

28:39

hardware it's probably not going to be something

28:41

so generic right this was just something off

28:43

the shelf they could buy and sell as

28:45

the dev kit so people would start making

28:47

their applications work for Windows on

28:49

ARM and on Linux that hadn't

28:52

happened as much before people

28:54

weren't yeah there's no

28:56

company behind the desktop applications

28:58

you're using on Linux that's

29:00

buying developers dev kits to

29:03

make sure the application works on ARM before the

29:05

hardware but it's not stopping us from catching

29:07

up. Let's do some free consulting

29:09

then but first just a quick thank you to everyone

29:11

who supports us with PayPal and Patreon we really do

29:13

appreciate that if you want to join those people

29:15

you can go to 2.5 admins.com slash

29:18

support and remember that for various

29:20

amounts on patreon you can get an advert free RSS

29:22

feed of either just this show or all

29:24

the shows in the late-night Linux family and

29:26

if you want to send any questions for Jim

29:28

and Alan or your feedback you can email show

29:30

at 2.5 admins.com Tom says Synology

29:33

is deprecating one of its OS's for

29:35

the older nurses for those

29:37

who have a fair amount invested in them are

29:40

there any false alternatives other than pulling the

29:42

data off and tossing the kit that'll

29:45

mostly depend on what the file system

29:47

is but since the Synology's are typically

29:50

relatively normal Linux then you

29:53

would be able to import the

29:55

file systems on some other fast-paced

29:57

Linux NAS But

30:00

it's not going to keep all of the

30:02

other bits from the Synology, all

30:04

the applications and so on. I don't

30:07

think there's a drop-in replacement for the

30:09

Synology OS itself, the one that's being

30:11

deprecated. But as far as not

30:13

having to copy all the data off and

30:15

just being able to mount it, that should be

30:17

relatively straightforward. My understanding was

30:20

that Synologies have a weird barFS with

30:22

some abstraction layer though, so doesn't that

30:24

make it more difficult to mount on

30:26

a normal Linux system? A little bit,

30:28

if you're a relatively veteran sysadmin, it's

30:31

not that daunting. If

30:33

you don't hit the level of relatively veteran

30:35

sysadmin, it might be a little daunting, but

30:37

you can get through it. You

30:39

need to be familiar with LVM and Butter.

30:42

You're not really going to be able to

30:44

recreate their stack exactly. I wouldn't recommend trying

30:46

to get the

30:48

whole thing up and running in its entirety. But if

30:50

you just want to be able to mount it read-only

30:53

and get the data off, you really just have to

30:55

be able to import the volume groups and

30:58

then reassemble the butter volume. It's

31:00

not that bad. Another

31:03

thing that's probably worth mentioning is

31:05

there is a project called XPennology,

31:08

X-P-E-N-O-L-O-G-Y, which

31:11

allows you to boot Synology

31:13

firmware on a generic x86

31:15

device. So

31:17

XPennology itself is just a custom bootloader

31:20

that you need to get the DSM

31:22

firmware running on your x86 box. And

31:26

that's not all that hard to get going.

31:28

Now I do have to mention, although this

31:30

has not really been tested in court, the

31:33

legal status of doing that is pretty murky. So

31:36

if you're just some person at

31:38

home who wants to carry

31:40

on basically the way you have been without

31:42

buying a super expensive new Synology box, that

31:45

might be an interesting solution because you would

31:47

be able to just buy or repurpose a

31:49

generic x86 machine, throw your

31:52

existing drives from your Synology in it

31:54

and boot it into Synology firmware, but

31:57

a newer version, then maybe that's

31:59

a cleaner upgrade. path but I

32:01

wouldn't recommend trying to do that at work. Right

32:04

well we better get out of here then.

32:06

Remember show at 2.5admins.com if you want to

32:08

send any questions or feedback. You

32:10

can find me at jrs.com/mastodon.

32:13

I'm at jrs-s.net/social. And I'm

32:15

at Alan Jude. We'll see

32:17

you next week.