WEBVTT

1
00:00:00.080 --> 00:00:02.839
<v Speaker 1>Welcome to the deep dive. Today. We're going to be

2
00:00:02.879 --> 00:00:06.280
<v Speaker 1>diving into some excerpts that you sent over from The

3
00:00:06.360 --> 00:00:11.640
<v Speaker 1>Linux Programming Interface by Michael Kerrisk. It's a pretty hefty book.

4
00:00:12.199 --> 00:00:16.559
<v Speaker 1>Even just glancing at the table of contents, we see threads, sockets,

5
00:00:16.719 --> 00:00:21.399
<v Speaker 1>file io, pretty much the entire playground of system programming.

6
00:00:21.480 --> 00:00:25.839
<v Speaker 2>It's a foundational text, and for good reason. It's incredibly comprehensive.

7
00:00:26.039 --> 00:00:29.120
<v Speaker 1>It is it is. Yeah, So our mission today is

8
00:00:29.199 --> 00:00:32.600
<v Speaker 1>to really kind of extract those golden nuggets from this book,

9
00:00:33.079 --> 00:00:34.920
<v Speaker 1>the key insights that will either give you a solid

10
00:00:35.000 --> 00:00:37.320
<v Speaker 1>understanding if you're new to this, or maybe spark some

11
00:00:37.479 --> 00:00:41.439
<v Speaker 1>aha moments if you're already familiar with the territory. So

12
00:00:41.520 --> 00:00:44.479
<v Speaker 1>let's jump right in. The book starts off by laying

13
00:00:44.520 --> 00:00:48.280
<v Speaker 1>some historical groundwork talking about the connection between Linux and

14
00:00:48.320 --> 00:00:51.799
<v Speaker 1>the UNI X world. And I was struck by how

15
00:00:51.880 --> 00:00:57.399
<v Speaker 1>much the philosophy of free software really shaped Linux's development.

16
00:00:57.640 --> 00:01:01.920
<v Speaker 2>That's crucial to understand. Yea Stallman and the GNU project.

17
00:01:02.479 --> 00:01:06.599
<v Speaker 2>They had this radical idea in the eighties that software

18
00:01:06.640 --> 00:01:10.719
<v Speaker 2>should be free to use, modify, and share. And it

19
00:01:10.760 --> 00:01:13.439
<v Speaker 2>wasn't just about cost, it was about freedom. Yeah, and

20
00:01:13.480 --> 00:01:17.159
<v Speaker 2>that idea that philosophy is baked into Linux's DNA.

21
00:01:17.319 --> 00:01:20.319
<v Speaker 1>Absolutely, and it's had a huge impact on its affordability

22
00:01:20.359 --> 00:01:23.000
<v Speaker 1>and how widely it's used today. Absolutely, But with so

23
00:01:23.079 --> 00:01:26.400
<v Speaker 1>many people contributing to Linux, Yeah, how do you ensure

24
00:01:26.480 --> 00:01:29.560
<v Speaker 1>that consistency and compatibility? How do you make sure everybody's

25
00:01:29.599 --> 00:01:30.519
<v Speaker 1>kind of on the same page?

26
00:01:30.680 --> 00:01:36.159
<v Speaker 2>Standards? Yeah, Kerisk emphasizes the importance of post six and

27
00:01:36.280 --> 00:01:40.439
<v Speaker 2>the single uni X specification. These are essentially sets of

28
00:01:40.519 --> 00:01:45.959
<v Speaker 2>standards that define how UNX like systems, including Linux, should behave.

29
00:01:46.400 --> 00:01:46.680
<v Speaker 1>Yeah.

30
00:01:46.719 --> 00:01:48.879
<v Speaker 2>It's like having a common language that everyone.

31
00:01:48.560 --> 00:01:51.040
<v Speaker 1>Speaks, right, So it's not just about making sure that

32
00:01:51.200 --> 00:01:55.079
<v Speaker 1>programs run on different Linux distributions. It's about ensuring that

33
00:01:55.120 --> 00:01:58.439
<v Speaker 1>they can potentially run on any system that adheres to

34
00:01:58.519 --> 00:02:00.000
<v Speaker 1>these UNX standards.

35
00:02:00.840 --> 00:02:05.280
<v Speaker 2>Portability and consistency across a diverse ecosystem are huge wins

36
00:02:05.280 --> 00:02:05.920
<v Speaker 2>for developers.

37
00:02:05.959 --> 00:02:09.840
<v Speaker 1>Okay, let's get to the heart of it. The Linux kernel. Yes,

38
00:02:10.080 --> 00:02:14.240
<v Speaker 1>I love how Keris describes it as the central nervous

39
00:02:14.280 --> 00:02:19.759
<v Speaker 1>system of the operating system. It's managing processes, memory, hardware,

40
00:02:20.479 --> 00:02:23.520
<v Speaker 1>the whole shebang, the whole thing, the whole thing. Yeah,

41
00:02:23.560 --> 00:02:26.400
<v Speaker 1>and it's mind blowing to me the sheer scope of

42
00:02:26.439 --> 00:02:27.520
<v Speaker 1>its responsibilities.

43
00:02:27.560 --> 00:02:30.479
<v Speaker 2>Everything you do on a Linux system, from opening a

44
00:02:30.479 --> 00:02:35.199
<v Speaker 2>file to browsing the web, involves the kernel in some way.

45
00:02:35.479 --> 00:02:39.599
<v Speaker 2>It's the ultimate mediator between your software and the physical hardware.

46
00:02:39.879 --> 00:02:42.520
<v Speaker 1>So if the kernel is the brain, what are the

47
00:02:42.520 --> 00:02:44.520
<v Speaker 1>individual thoughts what's going on in there?

48
00:02:44.680 --> 00:02:49.120
<v Speaker 2>Processes? A process is essentially a program in action. Kerisk

49
00:02:49.159 --> 00:02:54.599
<v Speaker 2>breaks down the structure of a process into segments text, data, heap,

50
00:02:54.639 --> 00:02:57.479
<v Speaker 2>and stack. Okay, think of it like a house. The

51
00:02:57.520 --> 00:03:02.719
<v Speaker 2>text segment is the blueprint, the actual program instructions. Data

52
00:03:02.840 --> 00:03:05.759
<v Speaker 2>is like the built in furniture, the initial variables and.

53
00:03:05.759 --> 00:03:07.919
<v Speaker 1>Constant I'm following you. Okay, good, So the heat must

54
00:03:07.960 --> 00:03:10.520
<v Speaker 1>be like the attic or the basement, right, you got it?

55
00:03:10.800 --> 00:03:14.520
<v Speaker 1>That space where a process can dynamically store additional data

56
00:03:14.639 --> 00:03:18.199
<v Speaker 1>as needed exactly. Okay. And lastly, we have the stack,

57
00:03:18.360 --> 00:03:21.400
<v Speaker 1>the stack, which is I'm picturing like that ever growing

58
00:03:21.479 --> 00:03:24.520
<v Speaker 1>pile of papers on your desk, yes, exactly, which is

59
00:03:24.639 --> 00:03:27.319
<v Speaker 1>used for managing function calls and local variables.

60
00:03:27.400 --> 00:03:28.400
<v Speaker 2>Perfect analogy.

61
00:03:28.879 --> 00:03:31.560
<v Speaker 1>I like that. I like that really helps to visualize

62
00:03:31.560 --> 00:03:35.599
<v Speaker 1>how these segments work together. But just like homeowner needs

63
00:03:35.879 --> 00:03:39.599
<v Speaker 1>keys to access different parts of their house right. Processes

64
00:03:39.680 --> 00:03:43.319
<v Speaker 1>need specific permissions to access resources on the system.

65
00:03:43.599 --> 00:03:46.800
<v Speaker 2>Absolutely, and that's where things can get interesting, especially in

66
00:03:46.879 --> 00:03:50.520
<v Speaker 2>terms of security. Keris talks about the traditional super rouser

67
00:03:50.599 --> 00:03:54.919
<v Speaker 2>model with root access right, but also dives into the

68
00:03:55.000 --> 00:03:57.479
<v Speaker 2>more modern capability based system.

69
00:03:57.759 --> 00:04:00.919
<v Speaker 1>So you mean like having a mass y versus having

70
00:04:00.960 --> 00:04:02.840
<v Speaker 1>individual keys for specific doors.

71
00:04:02.960 --> 00:04:07.039
<v Speaker 2>Exactly. Okay, it's all about granting only the minimum privileges necessary.

72
00:04:07.759 --> 00:04:10.199
<v Speaker 2>Too much power in the wrong hands, whether it's a

73
00:04:10.240 --> 00:04:13.479
<v Speaker 2>human user or a rogue process, can spell disaster.

74
00:04:13.800 --> 00:04:16.199
<v Speaker 1>Yeah. That makes a lot of sense from a security perspective.

75
00:04:16.399 --> 00:04:18.160
<v Speaker 2>Yeah, absolutely, So how.

76
00:04:17.959 --> 00:04:22.040
<v Speaker 1>Does Linux actually control and manage all these processes? Like,

77
00:04:22.079 --> 00:04:24.480
<v Speaker 1>how does it decide who gets to go first?

78
00:04:24.720 --> 00:04:27.480
<v Speaker 2>Well, one way is through scheduling. Okay, think of it

79
00:04:27.519 --> 00:04:31.800
<v Speaker 2>as a traffic cop directing the flow of processes vuying

80
00:04:31.839 --> 00:04:37.680
<v Speaker 2>for CPU time. Kerisk explains different scheduling policies. Some prioritize

81
00:04:37.720 --> 00:04:41.959
<v Speaker 2>real time performance, while others focus on fairness and responsiveness.

82
00:04:42.319 --> 00:04:45.279
<v Speaker 1>So like a video editing program might need a higher

83
00:04:45.319 --> 00:04:47.959
<v Speaker 1>priority than a background process checking for email.

84
00:04:48.160 --> 00:04:51.519
<v Speaker 2>Exactly, got it. Now, managing processes isn't just about who

85
00:04:51.560 --> 00:04:54.000
<v Speaker 2>gets to go first, It's also about making sure they

86
00:04:54.079 --> 00:04:56.120
<v Speaker 2>play nice and share resources fairly.

87
00:04:56.279 --> 00:04:58.480
<v Speaker 1>Yeah, you don't want a single process just hogging all

88
00:04:58.519 --> 00:04:59.600
<v Speaker 1>the memory or CPU.

89
00:05:01.000 --> 00:05:05.199
<v Speaker 2>Kerisk explains how Linux uses resource limits to prevent processes

90
00:05:05.199 --> 00:05:08.720
<v Speaker 2>from consuming too many sister resources. These are like safety

91
00:05:08.759 --> 00:05:11.160
<v Speaker 2>veils that prevent a single process from bringing down the

92
00:05:11.160 --> 00:05:11.720
<v Speaker 2>whole system.

93
00:05:11.959 --> 00:05:14.480
<v Speaker 1>So these limits help with both stability and security then,

94
00:05:14.600 --> 00:05:17.480
<v Speaker 1>right by keeping those potentially greedy processes in.

95
00:05:17.480 --> 00:05:21.079
<v Speaker 2>Check exactly, And then there are demons for those silent

96
00:05:21.120 --> 00:05:24.360
<v Speaker 2>workers running in the background doing those essential tasks.

97
00:05:24.560 --> 00:05:26.600
<v Speaker 1>Oh, you mean, like the programs that handle things like

98
00:05:26.720 --> 00:05:28.519
<v Speaker 1>printing or network connections.

99
00:05:29.160 --> 00:05:31.920
<v Speaker 2>Got it? And Chris points out that they often run

100
00:05:31.959 --> 00:05:36.120
<v Speaker 2>with special privileges because they're essential for the system to

101
00:05:36.160 --> 00:05:37.040
<v Speaker 2>function correctly.

102
00:05:37.399 --> 00:05:41.879
<v Speaker 1>That makes sense, But running with privileges also means needing

103
00:05:42.040 --> 00:05:46.720
<v Speaker 1>robust security right absolutely, to prevent any potential misuse.

104
00:05:46.560 --> 00:05:51.959
<v Speaker 2>And Kerisk emphasizes the importance of secure coding practices, especially

105
00:05:52.040 --> 00:05:55.079
<v Speaker 2>for these types of programs. Even a small oversight can

106
00:05:55.120 --> 00:05:59.399
<v Speaker 2>create a vulnerability that could be exploited. Ice stakes for sure.

107
00:05:59.600 --> 00:06:03.360
<v Speaker 1>Yeah, speaking of security, one of the things that really

108
00:06:03.399 --> 00:06:05.279
<v Speaker 1>stayed out to me in the book was the emphasis

109
00:06:05.319 --> 00:06:06.319
<v Speaker 1>on error handling.

110
00:06:06.800 --> 00:06:07.040
<v Speaker 2>Oh.

111
00:06:07.079 --> 00:06:10.839
<v Speaker 1>Absolutely, It's like Carisk is constantly reminding us that in

112
00:06:11.000 --> 00:06:14.319
<v Speaker 1>system programming, you can't just assume everything will always go

113
00:06:14.360 --> 00:06:15.120
<v Speaker 1>according to plan.

114
00:06:15.240 --> 00:06:19.040
<v Speaker 2>He's absolutely right, right, Robust error handling is critical. It's

115
00:06:19.079 --> 00:06:23.199
<v Speaker 2>about anticipating what could go wrong, right, and having a

116
00:06:23.240 --> 00:06:24.759
<v Speaker 2>plan to deal with it gracefully.

117
00:06:24.959 --> 00:06:27.600
<v Speaker 1>And he talks a lot about checking return values from

118
00:06:27.639 --> 00:06:31.240
<v Speaker 1>system calls and using the urno variable to diagnose what

119
00:06:31.279 --> 00:06:34.600
<v Speaker 1>went wrong. Exactly, it's like having this built in troubleshooting system.

120
00:06:34.720 --> 00:06:37.800
<v Speaker 2>It is. You need those checks in place, Yeah, to

121
00:06:38.000 --> 00:06:40.920
<v Speaker 2>catch potential issues before they cascade into bigger problems.

122
00:06:40.959 --> 00:06:41.560
<v Speaker 1>Absolutely.

123
00:06:41.759 --> 00:06:42.199
<v Speaker 2>Yeah.

124
00:06:42.240 --> 00:06:48.399
<v Speaker 1>And speaking of preventing problems, Kerisk dies deep into shared libraries. Yes,

125
00:06:48.720 --> 00:06:51.800
<v Speaker 1>I was fascinated by this concept, this idea that you

126
00:06:51.839 --> 00:06:56.480
<v Speaker 1>can have this central repository of code that multiple programs

127
00:06:56.800 --> 00:06:57.279
<v Speaker 1>can use.

128
00:06:57.639 --> 00:06:59.959
<v Speaker 2>Shared libraries are all about efficiency.

129
00:07:00.360 --> 00:07:00.600
<v Speaker 1>Yeah.

130
00:07:01.160 --> 00:07:04.959
<v Speaker 2>Instead of each program including its own copy of common functions,

131
00:07:05.480 --> 00:07:07.439
<v Speaker 2>they all share a single copy and memory.

132
00:07:07.519 --> 00:07:10.839
<v Speaker 1>So it's not just about saving disk space. It also

133
00:07:11.000 --> 00:07:12.839
<v Speaker 1>means that updates are much more efficient.

134
00:07:13.120 --> 00:07:16.800
<v Speaker 2>Exactly, you update the library once and all the programs

135
00:07:16.800 --> 00:07:19.360
<v Speaker 2>that use it automatically benefit from the changes.

136
00:07:19.399 --> 00:07:21.240
<v Speaker 1>Automatically benefit That's amazing.

137
00:07:21.319 --> 00:07:24.920
<v Speaker 2>Yeah, it's a brilliant way to maintain and manage complex

138
00:07:24.959 --> 00:07:25.800
<v Speaker 2>software systems.

139
00:07:25.920 --> 00:07:28.839
<v Speaker 1>That's really cool, and this idea of efficiency it seems

140
00:07:28.839 --> 00:07:31.120
<v Speaker 1>to be a recurring theme in Linux and programming.

141
00:07:31.199 --> 00:07:34.480
<v Speaker 2>It's fundamental. Yeah, Linux was designed to squeeze the most

142
00:07:34.519 --> 00:07:40.439
<v Speaker 2>performance out of often limited hardware resources, and that philosophy

143
00:07:40.560 --> 00:07:45.160
<v Speaker 2>carries through in many aspects of the system, from how

144
00:07:45.279 --> 00:07:47.839
<v Speaker 2>processes are managed to how files are stored.

145
00:07:48.040 --> 00:07:51.160
<v Speaker 1>Speaking of processes, we just briefly touched on them earlier. Yes,

146
00:07:51.399 --> 00:07:53.759
<v Speaker 1>let's delve a bit deeper into how Linux allows a

147
00:07:53.800 --> 00:07:57.040
<v Speaker 1>single process to juggle multiple tasks concurrently.

148
00:07:57.519 --> 00:07:58.600
<v Speaker 2>You're talking about threads.

149
00:07:58.920 --> 00:07:59.439
<v Speaker 1>Threads, right.

150
00:07:59.560 --> 00:08:04.040
<v Speaker 2>Think of a chef preparing multiple dishes simultaneously. Okay, each

151
00:08:04.120 --> 00:08:07.959
<v Speaker 2>dish requires its own ingredients and steps. Yeah, Threads allow

152
00:08:08.040 --> 00:08:12.120
<v Speaker 2>a single process to handle multiple tasks concurrently, just like

153
00:08:12.160 --> 00:08:13.439
<v Speaker 2>our multitasking chef.

154
00:08:13.560 --> 00:08:16.560
<v Speaker 1>So it's like having multiple cooks in the kitchen, all

155
00:08:16.600 --> 00:08:18.800
<v Speaker 1>sharing the same space and equipment, but working on their

156
00:08:18.839 --> 00:08:22.839
<v Speaker 1>own dishes. Exact concurrency and action. It's it, right, And

157
00:08:22.879 --> 00:08:26.199
<v Speaker 1>the cool thing is creating threads is generally much faster

158
00:08:26.279 --> 00:08:27.920
<v Speaker 1>than creating separate processes.

159
00:08:28.199 --> 00:08:31.399
<v Speaker 2>It is, indeed, and it's a key technique for achieving

160
00:08:31.439 --> 00:08:34.399
<v Speaker 2>responsiveness and performance. In many applications.

161
00:08:34.639 --> 00:08:37.960
<v Speaker 1>Okay, So now for these processes, whether single threaded or

162
00:08:38.039 --> 00:08:41.639
<v Speaker 1>multi threaded, right, to interact with the kernel, they need

163
00:08:41.679 --> 00:08:45.200
<v Speaker 1>a way to communicate their requests, and that's where system

164
00:08:45.240 --> 00:08:47.159
<v Speaker 1>calls come in, right, precisely. Okay.

165
00:08:47.240 --> 00:08:51.320
<v Speaker 2>They're the interface through which programs request services from the kernel,

166
00:08:52.080 --> 00:08:55.200
<v Speaker 2>like opening a file, sending data over a network, or

167
00:08:55.240 --> 00:08:56.120
<v Speaker 2>allocating memory.

168
00:08:56.200 --> 00:08:59.039
<v Speaker 1>It's like the language that user programs use to talk

169
00:08:59.080 --> 00:09:00.360
<v Speaker 1>to the kernel exactly. Ye.

170
00:09:00.759 --> 00:09:04.519
<v Speaker 2>Kerisk uses the simple example of the open system call.

171
00:09:04.840 --> 00:09:07.200
<v Speaker 2>You ask the kernel to open this file and it

172
00:09:07.200 --> 00:09:09.519
<v Speaker 2>does the heavy lifting behind the scenes. Yeah, and just

173
00:09:09.559 --> 00:09:11.919
<v Speaker 2>like a wader might tell you we're out of that dish,

174
00:09:12.639 --> 00:09:15.240
<v Speaker 2>system calls can also fail, right, so.

175
00:09:15.159 --> 00:09:18.120
<v Speaker 1>You don't always get what you want exactly. You got

176
00:09:18.120 --> 00:09:20.639
<v Speaker 1>to have a backup plan, you do, and that's why,

177
00:09:20.720 --> 00:09:24.679
<v Speaker 1>once again, Karris emphasizes error handling right. Always check those

178
00:09:24.720 --> 00:09:28.320
<v Speaker 1>return values, make sure you're getting what you asked for exactly.

179
00:09:28.480 --> 00:09:33.879
<v Speaker 2>And fortunately Linux provides great tools for debugging. Yeah, Kris

180
00:09:34.080 --> 00:09:37.240
<v Speaker 2>mentions the strace command, which allows you to see all

181
00:09:37.279 --> 00:09:40.440
<v Speaker 2>the system calls a program is making. Oh cool, it's

182
00:09:40.480 --> 00:09:43.480
<v Speaker 2>like having a transcript of the conversation. Yeah, between a

183
00:09:43.519 --> 00:09:44.879
<v Speaker 2>program and the kernel.

184
00:09:44.720 --> 00:09:47.679
<v Speaker 1>That's really neat. Yeah, so that can be incredibly helpful

185
00:09:47.720 --> 00:09:51.399
<v Speaker 1>then for tracking down those elusive bugs absolutely. Okay, Yeah,

186
00:09:51.519 --> 00:09:55.759
<v Speaker 1>Now let's talk about feature test macros. Okay, this may

187
00:09:55.840 --> 00:09:58.399
<v Speaker 1>seem like a minor detail. Yeah, but I was surprised

188
00:09:58.399 --> 00:10:01.120
<v Speaker 1>by how important they are for writing portable code.

189
00:10:01.639 --> 00:10:04.919
<v Speaker 2>Portability is key in the Linux world. Yeah, with so

190
00:10:05.000 --> 00:10:08.320
<v Speaker 2>many different versions and distributions out there, right right, feature

191
00:10:08.320 --> 00:10:13.039
<v Speaker 2>test macros allow you to tailor your code to specific

192
00:10:13.159 --> 00:10:17.679
<v Speaker 2>versions of the Linux API, ensuring compatibility across different systems.

193
00:10:17.759 --> 00:10:20.960
<v Speaker 1>It's like having a universal adapter for your electronics when

194
00:10:21.000 --> 00:10:23.759
<v Speaker 1>you travel to different countries. Exactly, you need the right

195
00:10:23.799 --> 00:10:25.360
<v Speaker 1>plug to connect to the power.

196
00:10:25.120 --> 00:10:28.519
<v Speaker 2>Source you do. Future test macros ensure that your code

197
00:10:28.559 --> 00:10:31.960
<v Speaker 2>plugs in correctly to different Linux environments.

198
00:10:32.000 --> 00:10:33.279
<v Speaker 1>Okay, that's a good analogy.

199
00:10:33.399 --> 00:10:33.759
<v Speaker 2>Yeah.

200
00:10:33.879 --> 00:10:36.159
<v Speaker 1>Now let's move on to one of the most fundamental

201
00:10:36.159 --> 00:10:39.000
<v Speaker 1>aspects of system programming, file io.

202
00:10:39.519 --> 00:10:39.720
<v Speaker 2>Right.

203
00:10:40.279 --> 00:10:42.679
<v Speaker 1>This is where things start to get really hands on.

204
00:10:43.480 --> 00:10:47.639
<v Speaker 1>How programs actually interact with data stored on disk.

205
00:10:47.840 --> 00:10:49.320
<v Speaker 2>Yeah, the real nitty gritty.

206
00:10:49.840 --> 00:10:52.240
<v Speaker 1>I'm eager to hear what Kris has to say about it.

207
00:10:52.320 --> 00:10:55.320
<v Speaker 1>You too, So we talked about how programs interact with

208
00:10:55.360 --> 00:10:58.279
<v Speaker 1>the kernel through system calls, especially for things like file io.

209
00:10:59.000 --> 00:11:01.240
<v Speaker 1>But how do they manage the memory they need to

210
00:11:01.320 --> 00:11:02.440
<v Speaker 1>work with all that data?

211
00:11:03.039 --> 00:11:07.440
<v Speaker 2>Well, memory management is a critical aspect of system programming. Yeah,

212
00:11:07.480 --> 00:11:11.399
<v Speaker 2>and Keris explains the different ways that processes and Linux

213
00:11:11.440 --> 00:11:14.759
<v Speaker 2>can allocate and manage memory. We touched upon the heap earlier,

214
00:11:15.000 --> 00:11:19.519
<v Speaker 2>which is a dynamic space where a process can request

215
00:11:19.559 --> 00:11:21.360
<v Speaker 2>more memory as needed.

216
00:11:21.240 --> 00:11:23.720
<v Speaker 1>Right, like that attic or basement that can expand to

217
00:11:23.759 --> 00:11:26.519
<v Speaker 1>hold more stuff as you accumulate things, exactly.

218
00:11:26.679 --> 00:11:29.559
<v Speaker 2>Yeah, but there are other mechanisms as well, Okay, like

219
00:11:29.600 --> 00:11:33.320
<v Speaker 2>shared memory your memory where multiple processes can access the

220
00:11:33.360 --> 00:11:37.399
<v Speaker 2>same region of memory. Oh, imagine a collaborative workspace, yeah,

221
00:11:37.440 --> 00:11:41.159
<v Speaker 2>where multiple programs can share data and communicate directly okay,

222
00:11:41.399 --> 00:11:44.399
<v Speaker 2>without having to constantly copy information back and forth.

223
00:11:44.480 --> 00:11:48.759
<v Speaker 1>That sounds incredibly efficient. What are some of the real

224
00:11:48.799 --> 00:11:51.320
<v Speaker 1>world benefits of using shared memory.

225
00:11:51.080 --> 00:11:55.120
<v Speaker 2>Like that, We'll think about performance critical applications like databases

226
00:11:55.240 --> 00:11:59.279
<v Speaker 2>or real time systems. Right. Shared memory can dramatically reduce

227
00:11:59.320 --> 00:12:04.559
<v Speaker 2>the overhead communication between processes, okay, leading to faster response

228
00:12:04.639 --> 00:12:07.840
<v Speaker 2>times makes sense, and more efficient use of system resources.

229
00:12:07.919 --> 00:12:10.480
<v Speaker 1>So in a way, it's about optimizing for both speed

230
00:12:10.600 --> 00:12:12.480
<v Speaker 1>and resource usage.

231
00:12:12.240 --> 00:12:15.759
<v Speaker 2>Precisely, okay. But efficient memory management isn't just about performance.

232
00:12:16.000 --> 00:12:18.000
<v Speaker 2>It's also crucial for system stability.

233
00:12:18.120 --> 00:12:19.480
<v Speaker 1>Right. If something goes wrong, if a.

234
00:12:19.480 --> 00:12:22.200
<v Speaker 2>Process runs out of memory, yeah, or tries to access

235
00:12:22.240 --> 00:12:25.159
<v Speaker 2>memory it shouldn't, right, it can cause the entire system

236
00:12:25.159 --> 00:12:25.519
<v Speaker 2>to crash.

237
00:12:25.679 --> 00:12:28.480
<v Speaker 1>It's a stark reminder of how interconnected everything is at

238
00:12:28.480 --> 00:12:32.279
<v Speaker 1>the system level. Absolutely, one rogue process can bring down

239
00:12:32.320 --> 00:12:34.440
<v Speaker 1>the whole house of cards, exactly. So you got to

240
00:12:34.440 --> 00:12:35.240
<v Speaker 1>be careful.

241
00:12:35.000 --> 00:12:38.279
<v Speaker 2>You do, which is why secure coding practices, especially around

242
00:12:38.320 --> 00:12:40.480
<v Speaker 2>memory management, are so important.

243
00:12:40.759 --> 00:12:41.440
<v Speaker 1>Absolutely.

244
00:12:41.600 --> 00:12:42.159
<v Speaker 2>Yeah.

245
00:12:42.600 --> 00:12:47.240
<v Speaker 1>Speaking of things that can influence program behavior, I've found

246
00:12:47.240 --> 00:12:51.200
<v Speaker 1>the section on environment variables quite fascinating. Oh yeah, They're

247
00:12:51.240 --> 00:12:53.279
<v Speaker 1>more than just settings, aren't they They are.

248
00:12:53.480 --> 00:12:57.919
<v Speaker 2>Oh, think of environment variables as global variables that processes

249
00:12:58.039 --> 00:13:02.000
<v Speaker 2>inherit from their parent process. It's like inheriting traits from

250
00:13:02.000 --> 00:13:05.240
<v Speaker 2>your parents. Some you can modify, while others are fixed.

251
00:13:05.840 --> 00:13:09.120
<v Speaker 2>They provide a way to pass information and configuration down

252
00:13:09.639 --> 00:13:11.799
<v Speaker 2>through generations of processes, so.

253
00:13:11.759 --> 00:13:16.440
<v Speaker 1>They can affect how a program behaves without the program

254
00:13:16.440 --> 00:13:20.559
<v Speaker 1>itself explicitly setting those values exactly, Okay, I see.

255
00:13:20.600 --> 00:13:24.320
<v Speaker 2>A common example is the path environment variable, which tells

256
00:13:24.320 --> 00:13:26.759
<v Speaker 2>the shell where to look for executable programs.

257
00:13:26.919 --> 00:13:29.159
<v Speaker 1>Right, So if you want to run a program without

258
00:13:29.159 --> 00:13:32.320
<v Speaker 1>typing its full path, it needs to be in one

259
00:13:32.320 --> 00:13:33.840
<v Speaker 1>of the directories listed in.

260
00:13:33.799 --> 00:13:34.879
<v Speaker 2>Your path exactly.

261
00:13:34.919 --> 00:13:36.480
<v Speaker 1>I use that all the time, but I've never really

262
00:13:36.759 --> 00:13:38.639
<v Speaker 1>thought about how it works under the hood.

263
00:13:38.879 --> 00:13:41.440
<v Speaker 2>Yeah, it's a subtle but powerful mechanism.

264
00:13:41.720 --> 00:13:42.360
<v Speaker 1>Yeah.

265
00:13:42.399 --> 00:13:46.759
<v Speaker 2>But Keris also cautions about the security implications of relying

266
00:13:46.759 --> 00:13:51.559
<v Speaker 2>on environment variables. Okay, especially in privileged programs. A malicious

267
00:13:51.600 --> 00:13:55.799
<v Speaker 2>user could manipulate environment variables to trick a program into

268
00:13:55.840 --> 00:13:56.879
<v Speaker 2>doing something it shouldn't.

269
00:13:57.080 --> 00:13:58.600
<v Speaker 1>That's scary, Yeah, it is.

270
00:13:58.919 --> 00:14:03.720
<v Speaker 2>So it's crucial to be aware of the potential pitfalls. Yeah,

271
00:14:03.759 --> 00:14:07.360
<v Speaker 2>and sanitize any input from the environment, especially if you're

272
00:14:07.360 --> 00:14:09.480
<v Speaker 2>writing code that runs with elevated privileges.

273
00:14:09.639 --> 00:14:14.240
<v Speaker 1>It's like someone tampering with a recipe, adding an unexpected

274
00:14:14.360 --> 00:14:17.480
<v Speaker 1>ingredient that could completely change the outcome. Yeah, you got

275
00:14:17.519 --> 00:14:20.240
<v Speaker 1>to be careful about that stuff. Okay. Now for something

276
00:14:20.240 --> 00:14:23.600
<v Speaker 1>a bit more technical, Okay, Caris talks about jump targets

277
00:14:24.480 --> 00:14:29.039
<v Speaker 1>using functions called set jimp and long jimp. I have

278
00:14:29.080 --> 00:14:32.159
<v Speaker 1>to admit this one went a little over my head. Okay, sure,

279
00:14:32.360 --> 00:14:34.159
<v Speaker 1>can you break it down? In a way that even

280
00:14:34.200 --> 00:14:35.039
<v Speaker 1>I can understand.

281
00:14:35.399 --> 00:14:39.639
<v Speaker 2>Sure, Okay. Imagine you're reading a book okay, and you

282
00:14:39.679 --> 00:14:42.720
<v Speaker 2>suddenly decide you want to jump to a specific chapter

283
00:14:43.519 --> 00:14:45.440
<v Speaker 2>bypassing all the pages in between.

284
00:14:45.639 --> 00:14:46.159
<v Speaker 1>Yeah.

285
00:14:46.240 --> 00:14:49.559
<v Speaker 2>That's essentially what set jump and long jimp allow you

286
00:14:49.600 --> 00:14:50.480
<v Speaker 2>to do in your code.

287
00:14:50.519 --> 00:14:53.919
<v Speaker 1>So it's like a nonlinear way of navigating through your

288
00:14:54.159 --> 00:14:56.039
<v Speaker 1>program's execution exactly.

289
00:14:56.559 --> 00:15:00.000
<v Speaker 2>They enable non local jumps okay, which can be particularly

290
00:15:00.200 --> 00:15:01.440
<v Speaker 2>useful for error handling.

291
00:15:01.679 --> 00:15:01.960
<v Speaker 1>Okay.

292
00:15:02.159 --> 00:15:06.519
<v Speaker 2>Imagine a program encountering a fatal error deep within and

293
00:15:06.559 --> 00:15:11.200
<v Speaker 2>nested function calls. Okay, Instead of unwinding the call stack meticulously,

294
00:15:12.039 --> 00:15:14.120
<v Speaker 2>you can use long jemp to jump back to a

295
00:15:14.159 --> 00:15:17.879
<v Speaker 2>previously saved point okay and gracefully handle the error.

296
00:15:18.080 --> 00:15:21.080
<v Speaker 1>So it's like having an escape hatch in a complex maze,

297
00:15:21.159 --> 00:15:23.440
<v Speaker 1>a way to bypass a blocked path and get back

298
00:15:23.480 --> 00:15:24.279
<v Speaker 1>to a safe point.

299
00:15:24.399 --> 00:15:24.919
<v Speaker 2>Precisely.

300
00:15:25.039 --> 00:15:28.000
<v Speaker 1>I like that analogy. Now, let's shift gears a bit

301
00:15:28.120 --> 00:15:32.679
<v Speaker 1>and talk about a fundamental concept in Linux security, User

302
00:15:32.759 --> 00:15:36.440
<v Speaker 1>and group IDs. These are like digital fingerprints that identify

303
00:15:36.519 --> 00:15:40.279
<v Speaker 1>who owns what and who's allowed to access which resources

304
00:15:40.320 --> 00:15:42.919
<v Speaker 1>on the system exactly. So it's similar to having different

305
00:15:42.960 --> 00:15:46.679
<v Speaker 1>levels of security clearance. In a building, your ID determines

306
00:15:46.720 --> 00:15:48.399
<v Speaker 1>which areas you're allowed to enter.

307
00:15:48.480 --> 00:15:52.559
<v Speaker 2>Exactly, okay. Kurisk explains how these ideas play a crucial

308
00:15:52.639 --> 00:15:58.919
<v Speaker 2>role in determining a process's permissions when accessing files, running programs,

309
00:15:59.600 --> 00:16:02.200
<v Speaker 2>interacting with other parts of the system. Right, it's a

310
00:16:02.240 --> 00:16:05.799
<v Speaker 2>foundational aspect of how Linux protects sensitive information.

311
00:16:06.399 --> 00:16:09.240
<v Speaker 1>I can see how understanding these concept is crucial for

312
00:16:09.279 --> 00:16:13.879
<v Speaker 1>system administrators and anyone concerned about security. Absolutely, okay. And

313
00:16:14.120 --> 00:16:18.480
<v Speaker 1>speaking of sensitive information, let's talk about time keeping in Linux.

314
00:16:18.840 --> 00:16:21.759
<v Speaker 1>You might think it's just about clocks and calendars, Yeah,

315
00:16:21.799 --> 00:16:24.240
<v Speaker 1>but ke Risk reveals it's much more nuanced than that.

316
00:16:24.559 --> 00:16:27.519
<v Speaker 1>It is okay, I'm intrigued. What are some of the

317
00:16:27.720 --> 00:16:32.639
<v Speaker 1>less obvious ways that Linux measures time well.

318
00:16:32.840 --> 00:16:35.919
<v Speaker 2>In addition to tracking calendar time, Linux also keeps track

319
00:16:35.960 --> 00:16:39.720
<v Speaker 2>of process time. Process time which measures how much CPU

320
00:16:39.799 --> 00:16:41.679
<v Speaker 2>time a specific process is used.

321
00:16:41.840 --> 00:16:45.480
<v Speaker 1>So it's like measuring how much electricity a particular appliance

322
00:16:45.519 --> 00:16:46.240
<v Speaker 1>has consumed.

323
00:16:46.320 --> 00:16:47.720
<v Speaker 2>That's a great analogy.

324
00:16:47.360 --> 00:16:49.240
<v Speaker 1>Versus just looking at the overall time on the.

325
00:16:49.200 --> 00:16:52.399
<v Speaker 2>Clock exactly, okay. And why is this important? Yeah, because

326
00:16:52.399 --> 00:16:57.080
<v Speaker 2>it allows system programmers to understand how efficiently their programs

327
00:16:57.080 --> 00:16:59.759
<v Speaker 2>are using resources. Okay, a program might be running for

328
00:16:59.759 --> 00:17:02.679
<v Speaker 2>a long time, but if it's mostly waiting for input

329
00:17:02.799 --> 00:17:07.839
<v Speaker 2>or iooperations, its actual CPU usage might be quite low.

330
00:17:08.160 --> 00:17:11.960
<v Speaker 1>So timekeeping isn't just about telling time. It's also about

331
00:17:12.000 --> 00:17:15.440
<v Speaker 1>profiling and understanding program behavior exactly. Ok.

332
00:17:15.599 --> 00:17:17.799
<v Speaker 2>And then there are those intriguing details that you might

333
00:17:17.839 --> 00:17:20.319
<v Speaker 2>not think about until they cause a problem, like path

334
00:17:20.400 --> 00:17:21.000
<v Speaker 2>name limits.

335
00:17:21.000 --> 00:17:22.039
<v Speaker 1>Path name limits.

336
00:17:22.160 --> 00:17:25.799
<v Speaker 2>It turns out there are restrictions on how long filenames

337
00:17:25.839 --> 00:17:28.519
<v Speaker 2>and directory paths can be in Linux.

338
00:17:28.720 --> 00:17:31.759
<v Speaker 1>Oh that's right, I've run into that before when trying

339
00:17:31.799 --> 00:17:35.880
<v Speaker 1>to create a really long filename or deeply nested directory structure.

340
00:17:36.240 --> 00:17:38.400
<v Speaker 1>It seems like such a minor detail. It does, but

341
00:17:38.480 --> 00:17:40.400
<v Speaker 1>it can definitely trip you up if you're not aware

342
00:17:40.400 --> 00:17:40.880
<v Speaker 1>of it.

343
00:17:40.880 --> 00:17:44.480
<v Speaker 2>It can. Kris points out that these limits can vary

344
00:17:44.519 --> 00:17:48.039
<v Speaker 2>depending on the specific file system you're using, and he

345
00:17:48.240 --> 00:17:53.119
<v Speaker 2>explains how to use the pathcon function to determine these limits,

346
00:17:53.680 --> 00:17:55.960
<v Speaker 2>which can be important if you're working with large file

347
00:17:56.039 --> 00:17:58.680
<v Speaker 2>systems or complex directory hierarchies.

348
00:17:58.839 --> 00:18:02.039
<v Speaker 1>It's like knowing the weight LISMD of a bridge before

349
00:18:02.079 --> 00:18:04.119
<v Speaker 1>you try to drive a truck over it. You need

350
00:18:04.160 --> 00:18:05.599
<v Speaker 1>to be aware of the constraints you.

351
00:18:05.599 --> 00:18:09.000
<v Speaker 2>Too, Now let's talk about something that often happens behind

352
00:18:09.079 --> 00:18:15.880
<v Speaker 2>the scenes, ok but can significantly impact performance io buffering.

353
00:18:16.599 --> 00:18:20.160
<v Speaker 1>Oh oh right, buffering. I've heard about buffering. Yes, could

354
00:18:20.200 --> 00:18:21.839
<v Speaker 1>you explain exactly how it works.

355
00:18:22.039 --> 00:18:25.079
<v Speaker 2>Imagine you're writing a letter, Okay, Instead of writing each

356
00:18:25.119 --> 00:18:28.000
<v Speaker 2>word directly onto the envelope, you first write it on

357
00:18:28.000 --> 00:18:30.119
<v Speaker 2>a piece of paper. Yeah, and then when the paper

358
00:18:30.160 --> 00:18:33.720
<v Speaker 2>is full, you transfer the entire page to the envelope. Okay.

359
00:18:33.799 --> 00:18:36.559
<v Speaker 2>That's essentially what buffering does for io operations.

360
00:18:36.839 --> 00:18:40.680
<v Speaker 1>So it's about accumulating data in a temporary storage area

361
00:18:41.279 --> 00:18:44.599
<v Speaker 1>and then writing it in larger chunks other than one

362
00:18:44.640 --> 00:18:45.440
<v Speaker 1>bite at a time.

363
00:18:45.680 --> 00:18:50.119
<v Speaker 2>Right. This reduces the number of system calls required, which

364
00:18:50.160 --> 00:18:53.680
<v Speaker 2>can significantly speed up read and write operations.

365
00:18:54.000 --> 00:18:55.480
<v Speaker 1>That makes a lot of sense. It's like taking a

366
00:18:55.519 --> 00:18:57.839
<v Speaker 1>bus instead of walking every time you need to go

367
00:18:57.880 --> 00:18:59.960
<v Speaker 1>somewhere more efficient and less overhead.

368
00:19:00.160 --> 00:19:00.680
<v Speaker 2>Exactly.

369
00:19:01.079 --> 00:19:04.559
<v Speaker 1>And here's an intriguing fact. Linux actually uses a two

370
00:19:04.640 --> 00:19:05.839
<v Speaker 1>level buffering system.

371
00:19:06.079 --> 00:19:06.440
<v Speaker 2>It does.

372
00:19:06.759 --> 00:19:10.039
<v Speaker 1>There's buffering in the kernel, and then there's additional buffering

373
00:19:10.160 --> 00:19:14.279
<v Speaker 1>in the studio library, which provides standard input and output

374
00:19:14.279 --> 00:19:18.559
<v Speaker 1>functions for C programs. Exactly, So data gets buffered twice. Yeah,

375
00:19:18.640 --> 00:19:19.759
<v Speaker 1>that seems like overkill.

376
00:19:19.960 --> 00:19:22.640
<v Speaker 2>It might seem that way, but it's all about optimizing

377
00:19:22.680 --> 00:19:26.640
<v Speaker 2>performance at different levels. Okay. The kernel's buffering handles the

378
00:19:26.680 --> 00:19:30.160
<v Speaker 2>low level interactions with the hardware, okay, while the studio

379
00:19:30.240 --> 00:19:33.839
<v Speaker 2>library's buffering provides a more convenient interface for.

380
00:19:33.839 --> 00:19:37.240
<v Speaker 1>Programmers, so they each have their own specific roles they do. Okay,

381
00:19:37.359 --> 00:19:40.720
<v Speaker 1>that makes sense. Now, though we've talked about how programs

382
00:19:40.799 --> 00:19:44.880
<v Speaker 1>manage memory and interact with files, Yeah, let's dive into

383
00:19:44.960 --> 00:19:48.880
<v Speaker 1>the world of filesystems themselves. Okay, how does Linux actually

384
00:19:48.920 --> 00:19:51.799
<v Speaker 1>store and organize all this data on disc?

385
00:19:52.119 --> 00:19:56.279
<v Speaker 2>Filesystem internals can be quite complex, Yeah, I bet, but

386
00:19:56.720 --> 00:19:59.799
<v Speaker 2>Kerisk does a great job of providing a high level

387
00:20:00.119 --> 00:20:01.880
<v Speaker 2>review of the key concepts.

388
00:20:01.920 --> 00:20:02.200
<v Speaker 1>Okay.

389
00:20:02.319 --> 00:20:05.680
<v Speaker 2>He talks about inodes innodes, which are like index cards

390
00:20:05.680 --> 00:20:10.160
<v Speaker 2>that contain metadata about each file, including its size, permissions,

391
00:20:10.319 --> 00:20:11.440
<v Speaker 2>and location on disc.

392
00:20:11.680 --> 00:20:14.720
<v Speaker 1>So the inode is like the file's identity cards exactly.

393
00:20:14.799 --> 00:20:16.720
<v Speaker 1>It tells the system everything it needs to know about

394
00:20:16.720 --> 00:20:17.559
<v Speaker 1>the file it does.

395
00:20:17.880 --> 00:20:21.279
<v Speaker 2>He then explains data blocks data blocks, which are the

396
00:20:21.319 --> 00:20:24.759
<v Speaker 2>actual chunks of disk space where the file's content is stored.

397
00:20:24.920 --> 00:20:28.440
<v Speaker 1>Okay, So the inode points to the data blocks where

398
00:20:28.480 --> 00:20:30.920
<v Speaker 1>the actual data resides precisely, okay.

399
00:20:31.000 --> 00:20:33.319
<v Speaker 2>And to tie everything together, there are.

400
00:20:33.240 --> 00:20:35.200
<v Speaker 1>Mount points mount points, right, which.

401
00:20:35.079 --> 00:20:39.640
<v Speaker 2>Are like directories that serve as entry points to different filesystems.

402
00:20:39.799 --> 00:20:40.079
<v Speaker 1>Okay.

403
00:20:40.319 --> 00:20:43.039
<v Speaker 2>You can think of them like different sections in a library,

404
00:20:43.079 --> 00:20:45.119
<v Speaker 2>each containing a specific collection of books.

405
00:20:45.240 --> 00:20:46.440
<v Speaker 1>That's a helpful analogy.

406
00:20:46.640 --> 00:20:46.920
<v Speaker 2>Yeah.

407
00:20:46.960 --> 00:20:49.839
<v Speaker 1>So you can have multiple filesystems, each with its own

408
00:20:49.960 --> 00:20:53.799
<v Speaker 1>organization and structure mounted under a single directory tree.

409
00:20:53.960 --> 00:20:54.200
<v Speaker 2>Right.

410
00:20:54.519 --> 00:20:58.200
<v Speaker 1>That makes sense for flexibility and managing different types of

411
00:20:58.200 --> 00:21:02.000
<v Speaker 1>storage devices, it does, right. So you might have like

412
00:21:02.160 --> 00:21:06.039
<v Speaker 1>a separate filesystem for your photos versus your documents versus

413
00:21:06.039 --> 00:21:07.240
<v Speaker 1>your music, or something like.

414
00:21:07.200 --> 00:21:10.640
<v Speaker 2>That exactly, Okay. And just like a library needs a

415
00:21:10.640 --> 00:21:15.400
<v Speaker 2>system for organizing and protecting its books, right, filesystems need

416
00:21:15.480 --> 00:21:20.319
<v Speaker 2>ways to ensure data integrity, especially in the face of

417
00:21:20.480 --> 00:21:24.759
<v Speaker 2>unexpected events like power outages or system crashes.

418
00:21:24.880 --> 00:21:26.480
<v Speaker 1>Yeah. You don't want to lose all your data if

419
00:21:26.519 --> 00:21:27.680
<v Speaker 1>something goes wrong, you.

420
00:21:27.640 --> 00:21:30.359
<v Speaker 2>Don't, right. That's where journaling file systems come in.

421
00:21:30.640 --> 00:21:31.960
<v Speaker 1>Journaling file systems.

422
00:21:32.039 --> 00:21:37.000
<v Speaker 2>Journaling filesystems act like meticulous librarians, okay, keeping a detailed

423
00:21:37.039 --> 00:21:40.079
<v Speaker 2>log of all changes made to the filesystem structure.

424
00:21:40.319 --> 00:21:40.680
<v Speaker 1>Okay.

425
00:21:40.880 --> 00:21:44.599
<v Speaker 2>If a crash occurs, the system can use this log

426
00:21:45.079 --> 00:21:48.920
<v Speaker 2>to quickly restore the filesystem to a consistent state okay,

427
00:21:49.160 --> 00:21:50.839
<v Speaker 2>minimizing data loss or corruption.

428
00:21:51.400 --> 00:21:54.279
<v Speaker 1>So it's like having an undoe button for your entire

429
00:21:54.359 --> 00:21:57.079
<v Speaker 1>file system, a way to roll back any incomplete or

430
00:21:57.119 --> 00:21:58.359
<v Speaker 1>interrupted operations.

431
00:21:58.519 --> 00:21:59.000
<v Speaker 2>Exactly.

432
00:21:59.119 --> 00:22:02.200
<v Speaker 1>That's incredibly assuring from a data integrity perspective.

433
00:22:02.279 --> 00:22:06.079
<v Speaker 2>It is, and to further protect data, file systems use

434
00:22:06.119 --> 00:22:09.759
<v Speaker 2>permissions to control who can access which files and directories.

435
00:22:09.880 --> 00:22:13.960
<v Speaker 2>Sure Mission Currisk breaks down the traditional Unix file permission model,

436
00:22:14.319 --> 00:22:17.680
<v Speaker 2>which uses a combination of bits to represent read, write,

437
00:22:17.759 --> 00:22:21.319
<v Speaker 2>and execute permissions for the owner, group and others.

438
00:22:21.599 --> 00:22:24.960
<v Speaker 1>Right, those cryptic strings of letters and dashes that you

439
00:22:25.000 --> 00:22:27.440
<v Speaker 1>see when you list files in a terminal, Exactly, I've

440
00:22:27.480 --> 00:22:31.319
<v Speaker 1>always known they represent permissions, but I've never really understood

441
00:22:31.359 --> 00:22:32.079
<v Speaker 1>the details.

442
00:22:32.480 --> 00:22:36.519
<v Speaker 2>Kerisk explains how each bit corresponds to a specific permission,

443
00:22:37.119 --> 00:22:40.519
<v Speaker 2>allowing for fine grained control over access okay. He also

444
00:22:40.559 --> 00:22:44.880
<v Speaker 2>talks about Access Control Lists or acls. ACLS, which provide

445
00:22:44.880 --> 00:22:48.680
<v Speaker 2>an even more flexible way to define permissions for individual

446
00:22:48.799 --> 00:22:49.920
<v Speaker 2>users or groups.

447
00:22:50.440 --> 00:22:53.599
<v Speaker 1>So instead of just having owner group and others, you

448
00:22:53.680 --> 00:22:56.960
<v Speaker 1>can create specific rules for who can access a file

449
00:22:57.079 --> 00:22:58.359
<v Speaker 1>or directory precisely.

450
00:22:58.920 --> 00:23:02.519
<v Speaker 2>Acls allow for much finer grain control, which can be

451
00:23:02.599 --> 00:23:06.000
<v Speaker 2>essential in environments with complex security requirements. Makes sense now.

452
00:23:06.000 --> 00:23:08.960
<v Speaker 2>Once you understand how files are organized and protected, the

453
00:23:09.000 --> 00:23:11.240
<v Speaker 2>next step is learning how to manipulate them.

454
00:23:11.400 --> 00:23:16.839
<v Speaker 1>That's where the actual file and directory operations come in. Exactly, creating, deleting, renaming,

455
00:23:17.039 --> 00:23:19.599
<v Speaker 1>moving files around the stuff we do every day, The

456
00:23:19.640 --> 00:23:22.240
<v Speaker 1>everyday stuff but probably take for granted we do.

457
00:23:22.880 --> 00:23:25.559
<v Speaker 2>Caris covers all the essential system calls for working with

458
00:23:25.640 --> 00:23:29.720
<v Speaker 2>files and directories. He explains the subtle differences between hard

459
00:23:29.759 --> 00:23:33.400
<v Speaker 2>links and symbolic links, both of which allow you to

460
00:23:33.440 --> 00:23:36.559
<v Speaker 2>create multiple names for the same file okay, but with

461
00:23:36.599 --> 00:23:38.880
<v Speaker 2>different implications for how the filesystem tracks them.

462
00:23:39.079 --> 00:23:42.720
<v Speaker 1>Oh right. Symbolic links are like shortcuts. Well, hard links

463
00:23:42.759 --> 00:23:45.519
<v Speaker 1>are more like aliases. You've got it, okay if I

464
00:23:45.519 --> 00:23:48.440
<v Speaker 1>remember correctly. He also discusses how to use the un

465
00:23:48.440 --> 00:23:54.319
<v Speaker 1>notifying mechanism, which allows programs to receive notifications when file

466
00:23:54.440 --> 00:23:59.440
<v Speaker 1>system events occur, like files being created, modified, or deleted exactly.

467
00:23:59.680 --> 00:24:04.200
<v Speaker 1>That's sounds incredibly useful for building tools that monitor file

468
00:24:04.279 --> 00:24:07.119
<v Speaker 1>systems it is, or react to specific events, like if

469
00:24:07.119 --> 00:24:10.200
<v Speaker 1>you wanted to, say, automatically back up a file whenever

470
00:24:10.240 --> 00:24:12.960
<v Speaker 1>it's changed exactly. I can imagine all sorts of interesting

471
00:24:12.960 --> 00:24:14.000
<v Speaker 1>applications for that.

472
00:24:14.279 --> 00:24:17.079
<v Speaker 2>There are, and in notify is a powerful tool in

473
00:24:17.079 --> 00:24:20.640
<v Speaker 2>the hands of a skilled system programmer. Okay, cool, Now

474
00:24:20.680 --> 00:24:24.920
<v Speaker 2>shifting gears a bit, Okay, Let's talk about signals, those

475
00:24:24.920 --> 00:24:28.960
<v Speaker 2>asynchronous events that can interrupt a program's execution at any moment.

476
00:24:29.359 --> 00:24:32.039
<v Speaker 1>They sound a bit like those unexpected phone calls that

477
00:24:32.079 --> 00:24:32.799
<v Speaker 1>you have to answer.

478
00:24:32.960 --> 00:24:34.000
<v Speaker 2>That's a great analogy.

479
00:24:34.119 --> 00:24:36.000
<v Speaker 1>Even if you're in the middle of something important, it

480
00:24:36.079 --> 00:24:36.839
<v Speaker 1>is right.

481
00:24:36.880 --> 00:24:39.440
<v Speaker 2>And just like you might have different reactions to different

482
00:24:39.599 --> 00:24:44.000
<v Speaker 2>types of phone calls. Programs can be configured to respond

483
00:24:44.000 --> 00:24:46.319
<v Speaker 2>to different signals in specific ways.

484
00:24:46.839 --> 00:24:51.400
<v Speaker 1>So some signals might cause a program to terminate gracefully, right,

485
00:24:51.839 --> 00:24:55.119
<v Speaker 1>while others might trigger a specific action or simply be

486
00:24:55.240 --> 00:24:57.200
<v Speaker 1>ignored exactly, okay.

487
00:24:57.359 --> 00:25:01.759
<v Speaker 2>Kerisk explains how signals are used for inter process communication okay,

488
00:25:01.759 --> 00:25:06.480
<v Speaker 2>handling errors and responding to various system events. He also

489
00:25:06.519 --> 00:25:11.079
<v Speaker 2>discusses how to establish signal handlers. Signal handlers which are

490
00:25:11.279 --> 00:25:14.640
<v Speaker 2>functions that are invoked when a particular signal is received.

491
00:25:14.720 --> 00:25:17.519
<v Speaker 1>So a signal handler is like a pre programmed response

492
00:25:17.559 --> 00:25:19.079
<v Speaker 1>to a particular type of phone call.

493
00:25:19.200 --> 00:25:22.640
<v Speaker 2>Precisely, Okay, I get it, but Kerisk also cautions about

494
00:25:22.640 --> 00:25:26.240
<v Speaker 2>the challenges of writing signal handlers correctly. They need to

495
00:25:26.279 --> 00:25:28.799
<v Speaker 2>be re entrant re entrant, meaning they can be interrupted

496
00:25:28.839 --> 00:25:32.279
<v Speaker 2>and resumed safely, and they need to avoid race conditions.

497
00:25:32.440 --> 00:25:35.839
<v Speaker 2>Race conditions which can occur when multiple signals arrive at

498
00:25:35.880 --> 00:25:36.559
<v Speaker 2>the same time.

499
00:25:36.720 --> 00:25:39.720
<v Speaker 1>So there's a lot of potential for subtle bugs if

500
00:25:39.799 --> 00:25:42.079
<v Speaker 1>signal handlers aren't implemented carefully.

501
00:25:42.799 --> 00:25:46.519
<v Speaker 2>There is. Yeah, that's tricky, which is why understanding the

502
00:25:46.599 --> 00:25:49.920
<v Speaker 2>nuances of signal handling is crucial for writing robust and

503
00:25:50.000 --> 00:25:51.799
<v Speaker 2>reliable system programs.

504
00:25:51.960 --> 00:25:52.640
<v Speaker 1>Absolutely.

505
00:25:52.799 --> 00:25:54.839
<v Speaker 2>Now let's zoom out a bit, okay and talk about

506
00:25:54.920 --> 00:25:58.440
<v Speaker 2>job control. Job control those mechanisms that allow you to

507
00:25:58.480 --> 00:26:02.119
<v Speaker 2>manage multiple processes running in the foreground and background.

508
00:26:02.279 --> 00:26:04.119
<v Speaker 1>This is one of those things that feels like magic

509
00:26:04.240 --> 00:26:05.400
<v Speaker 1>when you use the shell.

510
00:26:05.640 --> 00:26:06.680
<v Speaker 2>It does, but I'm.

511
00:26:06.559 --> 00:26:09.640
<v Speaker 1>Curious to hear how it actually works under the hood.

512
00:26:10.160 --> 00:26:14.279
<v Speaker 2>Carisk explains how shells use process groups and sessions to

513
00:26:14.400 --> 00:26:17.839
<v Speaker 2>manage interactive programs. Okay, when you hit kreele plu z

514
00:26:18.240 --> 00:26:22.079
<v Speaker 2>to suspend a program or type being to send into

515
00:26:22.119 --> 00:26:26.039
<v Speaker 2>the background, the shell is actually manipulating these process groups

516
00:26:26.079 --> 00:26:27.160
<v Speaker 2>behind the scenes.

517
00:26:26.960 --> 00:26:29.759
<v Speaker 1>So it's not just about the commands you type. There's

518
00:26:29.799 --> 00:26:33.680
<v Speaker 1>a whole system for organizing and controlling processes at play exactly.

519
00:26:33.799 --> 00:26:36.160
<v Speaker 2>And then there's the concept of controlling terminals.

520
00:26:36.279 --> 00:26:37.799
<v Speaker 1>Controlling terminals, which.

521
00:26:37.559 --> 00:26:40.519
<v Speaker 2>Can get a bit tricky. Yeah, I bet ca risk

522
00:26:40.599 --> 00:26:43.839
<v Speaker 2>explains how a controlling terminal acts like a conduit for

523
00:26:43.960 --> 00:26:47.640
<v Speaker 2>input and output, okay, and how signals like sycop and

524
00:26:47.720 --> 00:26:51.440
<v Speaker 2>sitcon come into play when processes compete for control of

525
00:26:51.440 --> 00:26:52.000
<v Speaker 2>the terminal.

526
00:26:52.359 --> 00:26:55.559
<v Speaker 1>It's amazing to think about all this complexity happening behind

527
00:26:55.599 --> 00:26:58.640
<v Speaker 1>the scenes. It is every time I interact with my shell.

528
00:26:58.759 --> 00:27:01.240
<v Speaker 2>Yeah, and it's all designed to give you, the user,

529
00:27:01.680 --> 00:27:04.559
<v Speaker 2>a seamless and powerful way to manage your programs.

530
00:27:04.680 --> 00:27:07.319
<v Speaker 1>That's really cool. Now, let's talk about something that can

531
00:27:07.319 --> 00:27:10.680
<v Speaker 1>make a big difference in performance. Okay, process priorities.

532
00:27:10.720 --> 00:27:11.559
<v Speaker 2>Process priorities.

533
00:27:11.599 --> 00:27:14.519
<v Speaker 1>Right, I've heard about process priorities, but can you explain

534
00:27:14.559 --> 00:27:15.839
<v Speaker 1>how they work in practice?

535
00:27:15.920 --> 00:27:16.240
<v Speaker 2>Sure?

536
00:27:16.440 --> 00:27:16.680
<v Speaker 1>Okay.

537
00:27:16.920 --> 00:27:21.359
<v Speaker 2>Linux uses a priority system to determine which process gets

538
00:27:21.440 --> 00:27:23.200
<v Speaker 2>to use the CPU next.

539
00:27:23.440 --> 00:27:23.680
<v Speaker 1>Okay.

540
00:27:24.119 --> 00:27:27.839
<v Speaker 2>Processes with higher priority get preferential treatment okay, while lower

541
00:27:27.839 --> 00:27:30.000
<v Speaker 2>priority processes might have to wait their turn.

542
00:27:30.079 --> 00:27:32.480
<v Speaker 1>So if I have a CPU intensive task that I

543
00:27:32.519 --> 00:27:35.319
<v Speaker 1>want to finish quickly, I can bump up its priority.

544
00:27:35.039 --> 00:27:39.799
<v Speaker 2>In theory, yes, okay, But Keris cautions against messing with

545
00:27:39.880 --> 00:27:44.039
<v Speaker 2>process priorities unless you really know what you're doing, okay.

546
00:27:44.119 --> 00:27:45.400
<v Speaker 1>Why is that It.

547
00:27:45.279 --> 00:27:49.960
<v Speaker 2>Can have unintended consequences Okay, like starving other processes of

548
00:27:50.000 --> 00:27:53.519
<v Speaker 2>CPU time and making the system less responsive overall.

549
00:27:53.720 --> 00:27:56.240
<v Speaker 1>Right, it's like cutting in line exactly. You might get

550
00:27:56.279 --> 00:27:58.440
<v Speaker 1>to the front faster, but you could also annoy everyone

551
00:27:58.440 --> 00:28:01.119
<v Speaker 1>else who's been waiting patiently, exactly, So it's best to

552
00:28:01.160 --> 00:28:01.680
<v Speaker 1>leave it to the.

553
00:28:01.640 --> 00:28:04.240
<v Speaker 2>Experts unless you really know what you're doing, right, Unless.

554
00:28:03.960 --> 00:28:06.519
<v Speaker 1>You really know what you're doing. Yeah, speaking of keeping

555
00:28:06.559 --> 00:28:10.319
<v Speaker 1>processes in check, let's talk about resource limits.

556
00:28:10.359 --> 00:28:11.440
<v Speaker 2>Resource limits, correct.

557
00:28:11.480 --> 00:28:15.359
<v Speaker 1>These are like guardrails that prevent processes from consuming too

558
00:28:15.480 --> 00:28:19.680
<v Speaker 1>much of the system's resources, right, like memory, CPU time,

559
00:28:20.319 --> 00:28:22.759
<v Speaker 1>or the number of files they can open, exactly. So

560
00:28:22.799 --> 00:28:26.640
<v Speaker 1>they're like safety mechanisms to prevent one rogue process from

561
00:28:26.720 --> 00:28:29.200
<v Speaker 1>hugging all the resources and bringing down the entire.

562
00:28:29.039 --> 00:28:33.039
<v Speaker 2>System precisely, okay. Kerisk explains how resource limits are used

563
00:28:33.039 --> 00:28:36.960
<v Speaker 2>to ensure system stability and prevent denial of service attacks.

564
00:28:37.000 --> 00:28:38.359
<v Speaker 1>Denial of service attack.

565
00:28:38.160 --> 00:28:41.039
<v Speaker 2>Where a malicious program tries to overload the system and

566
00:28:41.079 --> 00:28:41.960
<v Speaker 2>make it unusable.

567
00:28:42.400 --> 00:28:44.880
<v Speaker 1>So these limits are really important, then they are for

568
00:28:44.960 --> 00:28:46.400
<v Speaker 1>protecting the system as a whole.

569
00:28:46.640 --> 00:28:47.920
<v Speaker 2>Absolutely, Yeah.

570
00:28:48.000 --> 00:28:52.200
<v Speaker 1>It seems like finding the right balance between giving processes

571
00:28:52.240 --> 00:28:56.119
<v Speaker 1>the resources they need to function while also protecting the

572
00:28:56.160 --> 00:29:00.359
<v Speaker 1>system as a whole is a constant challenge and system program.

573
00:29:00.240 --> 00:29:02.319
<v Speaker 2>It is, and resource limits are one of the key

574
00:29:02.400 --> 00:29:05.160
<v Speaker 2>tools that Linux provides to help maintain that balance.

575
00:29:05.440 --> 00:29:08.480
<v Speaker 1>Okay. Now, circling back to our discussion of demons, ke

576
00:29:08.599 --> 00:29:10.920
<v Speaker 1>Risk highlights an important aspect of how they.

577
00:29:10.799 --> 00:29:14.079
<v Speaker 2>Operate okay, logging logging m HM.

578
00:29:14.599 --> 00:29:17.960
<v Speaker 1>Right. Since demons typically run in the background without direct

579
00:29:18.160 --> 00:29:21.839
<v Speaker 1>user interaction, they need a way to record what they're

580
00:29:21.839 --> 00:29:25.839
<v Speaker 1>doing and report any errors or events exactly right.

581
00:29:26.200 --> 00:29:31.640
<v Speaker 2>Kerisk explains how system logging allows processes, especially demons, to

582
00:29:31.680 --> 00:29:35.880
<v Speaker 2>write messages to a centralized log file okay, providing valuable

583
00:29:35.920 --> 00:29:40.400
<v Speaker 2>insights into the system's behavior okay, and helping diagnose problems.

584
00:29:40.480 --> 00:29:42.880
<v Speaker 1>So it's like having a black box recorder for your system,

585
00:29:43.000 --> 00:29:45.759
<v Speaker 1>capturing all the crucial events so you can analyze them.

586
00:29:45.680 --> 00:29:49.400
<v Speaker 2>Later precisely okay. And since demons often run with elevated

587
00:29:49.440 --> 00:29:53.839
<v Speaker 2>privileges HM, it's crucial to follow secure programming practices to

588
00:29:53.880 --> 00:29:56.319
<v Speaker 2>prevent potential vulnerabilities.

589
00:29:56.119 --> 00:29:59.279
<v Speaker 1>Right, because even a small error in a privileged program

590
00:29:59.319 --> 00:30:03.039
<v Speaker 1>could have signs magnificant security implications exactly, So you got

591
00:30:03.079 --> 00:30:05.960
<v Speaker 1>to be extra careful when you're working with demons, you.

592
00:30:05.880 --> 00:30:11.200
<v Speaker 2>Do, okay. Cares dedicates a whole section to secure programming okay,

593
00:30:11.240 --> 00:30:14.440
<v Speaker 2>emphasizing the need to minimize the amount of code that

594
00:30:14.559 --> 00:30:19.440
<v Speaker 2>runs with root privileges, validate all input carefully, and follow

595
00:30:19.480 --> 00:30:22.000
<v Speaker 2>best practices for handling sensitive data.

596
00:30:22.559 --> 00:30:25.160
<v Speaker 1>It sounds like secure coding is an essential skill for

597
00:30:25.200 --> 00:30:28.720
<v Speaker 1>anyone working with system level programs. It is, especially those

598
00:30:28.720 --> 00:30:30.559
<v Speaker 1>that operate with elevated permissions.

599
00:30:30.640 --> 00:30:33.400
<v Speaker 2>Absolutely, and it's something that every system programming needs to

600
00:30:33.440 --> 00:30:34.559
<v Speaker 2>be constantly mindful of.

601
00:30:34.839 --> 00:30:36.359
<v Speaker 1>Yeah, vigilance is key.

602
00:30:36.480 --> 00:30:37.319
<v Speaker 2>Vigilance is key.

603
00:30:37.519 --> 00:30:40.480
<v Speaker 1>Now, speaking of managing privileges, I was intrigued by the

604
00:30:40.519 --> 00:30:44.079
<v Speaker 1>concept of capabilities, which you briefly mentioned earlier. Can you

605
00:30:44.119 --> 00:30:47.960
<v Speaker 1>elaborate on how they provide a more fine grained approach

606
00:30:48.079 --> 00:30:51.200
<v Speaker 1>to security than the traditional super rouser model.

607
00:30:51.519 --> 00:30:55.920
<v Speaker 2>Sure capabilities are like splitting up the master key into

608
00:30:55.960 --> 00:30:59.400
<v Speaker 2>a set of smaller keys, each granting access to a

609
00:30:59.440 --> 00:31:03.160
<v Speaker 2>specific set of privileges. Instead of giving a program full

610
00:31:03.240 --> 00:31:06.680
<v Speaker 2>root access you can give it only the specific capabilities

611
00:31:06.680 --> 00:31:08.240
<v Speaker 2>it needs to perform its tasks.

612
00:31:08.759 --> 00:31:12.000
<v Speaker 1>So a program that only needs to access network resources

613
00:31:12.160 --> 00:31:17.680
<v Speaker 1>would receive the networking capability exactly, but not the capability

614
00:31:17.759 --> 00:31:21.400
<v Speaker 1>to modify the file system or manage users, for example, exactly.

615
00:31:21.519 --> 00:31:24.720
<v Speaker 2>Ok This limits the potential damage that a compromised program

616
00:31:24.720 --> 00:31:27.759
<v Speaker 2>could inflict, even if it's running with elevated privileges.

617
00:31:27.960 --> 00:31:31.319
<v Speaker 1>That's a really elegant way to mitigate risk, it is, Okay,

618
00:31:31.359 --> 00:31:31.799
<v Speaker 1>I like that.

619
00:31:31.920 --> 00:31:34.440
<v Speaker 2>Now, for those times when you need to track user activity,

620
00:31:35.000 --> 00:31:38.279
<v Speaker 2>kerisk mentions, log in accounting log in accounting. Log in

621
00:31:38.279 --> 00:31:41.519
<v Speaker 2>accounting is a system for recording user log in and

622
00:31:41.599 --> 00:31:44.680
<v Speaker 2>log add events, providing a history of who access the

623
00:31:44.720 --> 00:31:45.440
<v Speaker 2>system and when.

624
00:31:45.640 --> 00:31:48.319
<v Speaker 1>Okay. So it's like having a logbook at the entrance

625
00:31:48.359 --> 00:31:51.640
<v Speaker 1>to your house, recording who comes and goes precisely. Okay.

626
00:31:52.359 --> 00:31:55.359
<v Speaker 2>Now, let's circle back to our discussion of libraries libraries

627
00:31:55.440 --> 00:32:00.559
<v Speaker 2>right and explore the fascinating world of dynamic linking dynamically linking. Okay.

628
00:32:00.599 --> 00:32:03.680
<v Speaker 2>Dynamic linking is one of the most powerful and flexible

629
00:32:03.720 --> 00:32:04.599
<v Speaker 2>features of Linux.

630
00:32:04.680 --> 00:32:05.039
<v Speaker 1>Okay.

631
00:32:05.240 --> 00:32:08.519
<v Speaker 2>Instead of statically linking all the necessary libraries into a

632
00:32:08.599 --> 00:32:13.720
<v Speaker 2>program's executable file, at compile time. Dynamic linking allows programs

633
00:32:13.880 --> 00:32:17.240
<v Speaker 2>to load shared libraries on demand as they're needed.

634
00:32:17.359 --> 00:32:20.039
<v Speaker 1>So it's like having a just in time delivery system

635
00:32:20.119 --> 00:32:21.599
<v Speaker 1>for code modules exactly.

636
00:32:22.119 --> 00:32:25.920
<v Speaker 2>This has several advantages okay, like what it promotes code reuse,

637
00:32:26.519 --> 00:32:31.440
<v Speaker 2>reduces program sizes, and simplifies the process of updating libraries. Right.

638
00:32:31.880 --> 00:32:34.359
<v Speaker 2>If you need to fix a bug in a shared library, yeah,

639
00:32:34.559 --> 00:32:37.720
<v Speaker 2>you only have to update the library itself and all

640
00:32:37.759 --> 00:32:40.319
<v Speaker 2>the programs that use it will automatically benefit from the fix.

641
00:32:40.519 --> 00:32:43.359
<v Speaker 1>That makes a lot of sense from a maintainability perspective.

642
00:32:43.440 --> 00:32:43.799
<v Speaker 2>It does.

643
00:32:43.839 --> 00:32:46.519
<v Speaker 1>But wouldn't this create problems with compatibility?

644
00:32:46.680 --> 00:32:46.880
<v Speaker 2>Right?

645
00:32:47.319 --> 00:32:50.440
<v Speaker 1>What if a program depends on a specific version of

646
00:32:50.440 --> 00:32:53.599
<v Speaker 1>a library and that library is updated.

647
00:32:53.920 --> 00:32:56.839
<v Speaker 2>That's a valid concern. Yeah, and that's where shared library

648
00:32:56.960 --> 00:33:01.680
<v Speaker 2>versioning comes in. Shared library versioning explains how Linux uses

649
00:33:01.720 --> 00:33:05.799
<v Speaker 2>systems like sun names to manage library dependencies okay, and

650
00:33:05.920 --> 00:33:09.519
<v Speaker 2>ensure that programs load the correct versions of the libraries

651
00:33:09.559 --> 00:33:09.960
<v Speaker 2>they need.

652
00:33:10.119 --> 00:33:13.720
<v Speaker 1>So it's like having a system for tracking different vintages.

653
00:33:13.240 --> 00:33:15.880
<v Speaker 2>Of wine, a perfect analogy.

654
00:33:15.440 --> 00:33:18.200
<v Speaker 1>Ensuring that you get the specific year you're looking for. Yes,

655
00:33:18.240 --> 00:33:21.440
<v Speaker 1>even if the winery has released newer versions exactly, you

656
00:33:21.480 --> 00:33:24.720
<v Speaker 1>gotta have that ninety eight cabernet you do now. While

657
00:33:24.799 --> 00:33:28.920
<v Speaker 1>dynamic linking is the preferred approach in most cases, Kerisk

658
00:33:29.079 --> 00:33:33.119
<v Speaker 1>also mentions static linking as an alternative. He does, right,

659
00:33:33.160 --> 00:33:35.920
<v Speaker 1>that's where all the necessary libraries are bundled together into

660
00:33:35.960 --> 00:33:39.119
<v Speaker 1>a single executable file. Exactly. Okay, So what are the

661
00:33:39.240 --> 00:33:42.119
<v Speaker 1>trade off involved in choosing one approach over the other.

662
00:33:42.920 --> 00:33:45.640
<v Speaker 2>Static linking has the advantage of simplicity. You have a

663
00:33:45.680 --> 00:33:49.640
<v Speaker 2>single executable file that contains everything it needs to run, right,

664
00:33:50.559 --> 00:33:53.319
<v Speaker 2>But it comes at the cost of increased file size okay,

665
00:33:53.400 --> 00:33:54.680
<v Speaker 2>and reduce flexibility.

666
00:33:54.759 --> 00:33:55.119
<v Speaker 1>Okay.

667
00:33:55.759 --> 00:33:59.359
<v Speaker 2>With dynamic linking, you can update to replace libraries without

668
00:33:59.359 --> 00:34:01.319
<v Speaker 2>having to rec pile the entire program.

669
00:34:01.480 --> 00:34:04.640
<v Speaker 1>So static linking is like packing everything you need for

670
00:34:04.720 --> 00:34:08.119
<v Speaker 1>a trip into your suitcase, while dynamic linking is like

671
00:34:08.280 --> 00:34:10.920
<v Speaker 1>relying on finding amenities at your destination.

672
00:34:11.320 --> 00:34:11.760
<v Speaker 2>Exactly.

673
00:34:11.840 --> 00:34:12.679
<v Speaker 1>Okay, I like that.

674
00:34:13.039 --> 00:34:15.000
<v Speaker 2>Now round out our discussion of libraries.

675
00:34:15.079 --> 00:34:15.400
<v Speaker 1>Okay.

676
00:34:15.599 --> 00:34:21.440
<v Speaker 2>Kerisk introduces a more advanced technique, dynamically loading libraries on demand.

677
00:34:21.599 --> 00:34:25.000
<v Speaker 1>Oh so this is like taking linking a step further,

678
00:34:25.920 --> 00:34:29.239
<v Speaker 1>allowing programs to load libraries at run time based on

679
00:34:29.280 --> 00:34:31.199
<v Speaker 1>specific conditions or user requests.

680
00:34:31.239 --> 00:34:31.800
<v Speaker 2>Precisely.

681
00:34:31.960 --> 00:34:32.360
<v Speaker 1>Okay.

682
00:34:32.440 --> 00:34:36.239
<v Speaker 2>This is incredibly powerful for building extensible applications where you

683
00:34:36.239 --> 00:34:39.840
<v Speaker 2>can add new features or functionality without having to modify

684
00:34:39.880 --> 00:34:40.679
<v Speaker 2>the core program.

685
00:34:40.800 --> 00:34:43.679
<v Speaker 1>So it's like having a toolbox with specialized tools that

686
00:34:43.719 --> 00:34:46.079
<v Speaker 1>you can grab only when you need them, instead of

687
00:34:46.119 --> 00:34:48.800
<v Speaker 1>carrying around a giant tool chest with everything in it

688
00:34:48.840 --> 00:34:49.360
<v Speaker 1>all the time.

689
00:34:49.559 --> 00:34:50.039
<v Speaker 2>Exactly.

690
00:34:50.119 --> 00:34:50.400
<v Speaker 1>Okay.

691
00:34:50.639 --> 00:34:53.519
<v Speaker 2>Now, up to this point, yeah, we've mostly focused on

692
00:34:53.920 --> 00:34:57.559
<v Speaker 2>processes acting in isolation, right, But in the real world, Yeah,

693
00:34:57.719 --> 00:35:00.800
<v Speaker 2>processes often need to communicate and collaborate with the each other, right,

694
00:35:00.880 --> 00:35:03.880
<v Speaker 2>like different parts of a complex system working together to

695
00:35:04.000 --> 00:35:05.719
<v Speaker 2>achieve a common goal. Exactly.

696
00:35:05.800 --> 00:35:08.840
<v Speaker 1>That's where interprocess communication or IPC.

697
00:35:08.639 --> 00:35:13.239
<v Speaker 2>Comes in IPC. Yes, k Risk provides a high level

698
00:35:13.280 --> 00:35:18.039
<v Speaker 2>overview of the various IPC mechanisms available in Linux, ranging

699
00:35:18.039 --> 00:35:23.199
<v Speaker 2>from simple pipes pipes to more sophisticated techniques like message

700
00:35:23.239 --> 00:35:24.519
<v Speaker 2>queues and shared memory.

701
00:35:24.800 --> 00:35:28.000
<v Speaker 1>So it's like having different ways for processes to talk

702
00:35:28.039 --> 00:35:31.039
<v Speaker 1>to each other, from shouting across the room to sending

703
00:35:31.119 --> 00:35:33.079
<v Speaker 1>secret messages and coded envelopes.

704
00:35:33.159 --> 00:35:35.639
<v Speaker 2>Exactly. Okay, I like that, and just like in real

705
00:35:35.639 --> 00:35:39.320
<v Speaker 2>life communication. Yeah, the choice of which IPC mechanism to

706
00:35:39.440 --> 00:35:42.360
<v Speaker 2>use depends on the specific needs of the application.

707
00:35:42.800 --> 00:35:45.880
<v Speaker 1>Do some mechanisms work better for certain types of data

708
00:35:45.960 --> 00:35:47.519
<v Speaker 1>or communication patterns?

709
00:35:47.679 --> 00:35:53.960
<v Speaker 2>Absolutely. Let's start with one of the classic communication channels, pipes. Okay,

710
00:35:54.239 --> 00:35:58.440
<v Speaker 2>imagine a water pipe connecting two houses. Okay, water flows

711
00:35:58.480 --> 00:36:01.559
<v Speaker 2>in one direction only, right from the source to the destination.

712
00:36:02.079 --> 00:36:06.760
<v Speaker 2>Pipes in Linux works similarly, allowing processes to send data

713
00:36:06.920 --> 00:36:09.119
<v Speaker 2>back and forth in a sequential stream.

714
00:36:09.360 --> 00:36:11.880
<v Speaker 1>So if I want to send data from process A

715
00:36:12.039 --> 00:36:16.199
<v Speaker 1>to process B, I would create a pipe, and then

716
00:36:16.360 --> 00:36:20.599
<v Speaker 1>process A would write to the pipes output we process

717
00:36:20.639 --> 00:36:24.000
<v Speaker 1>B would read from the pipe's input exactly.

718
00:36:24.440 --> 00:36:27.719
<v Speaker 2>It's a simple and efficient way for related processes like

719
00:36:27.760 --> 00:36:30.280
<v Speaker 2>a parent and child, to communicate directly.

720
00:36:30.360 --> 00:36:32.119
<v Speaker 1>But what if you need two way communication?

721
00:36:32.639 --> 00:36:35.599
<v Speaker 2>You'd simply create two pipes, two pipes on for each direction.

722
00:36:36.159 --> 00:36:39.599
<v Speaker 1>That makes sense now. Now, while pipes are great for

723
00:36:39.679 --> 00:36:43.800
<v Speaker 1>those direct connections, what if the processes aren't directly related.

724
00:36:44.440 --> 00:36:47.559
<v Speaker 1>What if you need to communicate between processes running on

725
00:36:47.840 --> 00:36:50.760
<v Speaker 1>different parts of the system, or even on different machines.

726
00:36:50.840 --> 00:36:54.599
<v Speaker 2>That's where FIFOs come in. FIFOs or name pipes. They're

727
00:36:54.639 --> 00:36:57.679
<v Speaker 2>like pipes with an address, allowing any process that knows

728
00:36:57.679 --> 00:36:59.719
<v Speaker 2>the name to connect and communicate.

729
00:36:59.760 --> 00:37:02.920
<v Speaker 1>So It's like having a public mailbox where anyone who

730
00:37:02.960 --> 00:37:06.480
<v Speaker 1>knows the address can drop off or pick up messages precisely, okay.

731
00:37:06.639 --> 00:37:10.400
<v Speaker 2>FIFOs can be incredibly useful for building client server applications

732
00:37:11.000 --> 00:37:14.199
<v Speaker 2>or for communication between processes running on different systems.

733
00:37:14.239 --> 00:37:18.000
<v Speaker 1>Now, both pipes and FIFOs they treat data as a

734
00:37:18.079 --> 00:37:21.400
<v Speaker 1>continuous stream of bytes. What if you need to send

735
00:37:21.639 --> 00:37:27.519
<v Speaker 1>structured data like records or messages with headers and payloads.

736
00:37:27.679 --> 00:37:29.119
<v Speaker 2>That's where message queues come in.

737
00:37:29.239 --> 00:37:30.320
<v Speaker 1>Message cues think of.

738
00:37:30.280 --> 00:37:33.599
<v Speaker 2>Them like sending postcards, oh, instead of just stuffing notes

739
00:37:33.639 --> 00:37:34.360
<v Speaker 2>into a tube.

740
00:37:34.559 --> 00:37:37.480
<v Speaker 1>So each message is a self contained unit of information

741
00:37:37.559 --> 00:37:39.119
<v Speaker 1>with a specific structure.

742
00:37:39.239 --> 00:37:43.400
<v Speaker 2>Exactly. Message ques allow processes to exchange structured data in

743
00:37:43.480 --> 00:37:46.840
<v Speaker 2>a reliable and ordered way, okay, ensuring that messages are

744
00:37:46.880 --> 00:37:49.320
<v Speaker 2>delivered in the order they were sent, even if there

745
00:37:49.320 --> 00:37:50.760
<v Speaker 2>are delays or interruptions.

746
00:37:51.199 --> 00:37:54.400
<v Speaker 1>That sounds perfect for applications where message order is critical,

747
00:37:54.880 --> 00:37:57.440
<v Speaker 1>like financial transactions or distributed systems.

748
00:37:57.559 --> 00:37:58.000
<v Speaker 2>Exactly.

749
00:37:58.159 --> 00:38:01.719
<v Speaker 1>Now, both pipes and FIFOs they rely on the kernel

750
00:38:01.840 --> 00:38:03.280
<v Speaker 1>to manage the data transfer.

751
00:38:03.599 --> 00:38:03.719
<v Speaker 2>Right.

752
00:38:04.039 --> 00:38:06.199
<v Speaker 1>What if you need a way for processes to share

753
00:38:06.280 --> 00:38:10.760
<v Speaker 1>data directly, okay, without involving the kernel in every transaction, Right?

754
00:38:10.840 --> 00:38:12.599
<v Speaker 1>That sounds like it would be much more efficient.

755
00:38:12.760 --> 00:38:13.239
<v Speaker 2>It would be.

756
00:38:13.400 --> 00:38:15.239
<v Speaker 1>Is there a way to achieve that? In Linux?

757
00:38:15.599 --> 00:38:17.079
<v Speaker 2>There is. It's called shared.

758
00:38:16.800 --> 00:38:18.920
<v Speaker 1>Memory shared memory, okay, and it's one.

759
00:38:18.840 --> 00:38:22.400
<v Speaker 2>Of the fastest and most efficient ways for processes to

760
00:38:22.519 --> 00:38:24.519
<v Speaker 2>exchange large amounts of data.

761
00:38:24.599 --> 00:38:24.920
<v Speaker 1>Okay.

762
00:38:25.119 --> 00:38:28.800
<v Speaker 2>Imagine a bulletin board that multiple processes can read and

763
00:38:28.840 --> 00:38:30.360
<v Speaker 2>write to directly.

764
00:38:30.039 --> 00:38:33.280
<v Speaker 1>So instead of sending messages back and forth, processes can

765
00:38:33.280 --> 00:38:36.679
<v Speaker 1>simply modify the shared memory region, right, and all the

766
00:38:36.719 --> 00:38:39.480
<v Speaker 1>other processes that have access to that region will see

767
00:38:39.480 --> 00:38:40.639
<v Speaker 1>the changes immediately.

768
00:38:40.840 --> 00:38:41.320
<v Speaker 2>Exactly.

769
00:38:41.599 --> 00:38:45.159
<v Speaker 1>Wow, that's powerful, it is, But wouldn't this create problems

770
00:38:45.199 --> 00:38:46.119
<v Speaker 1>with synchronization?

771
00:38:46.599 --> 00:38:47.039
<v Speaker 2>It could.

772
00:38:47.199 --> 00:38:50.760
<v Speaker 1>What if multiple processes try to modify the same data

773
00:38:50.960 --> 00:38:52.800
<v Speaker 1>in shared memory at the same time.

774
00:38:53.239 --> 00:38:57.400
<v Speaker 2>That's a valid concern, and it's why synchronization mechanisms are

775
00:38:57.480 --> 00:38:59.199
<v Speaker 2>essential when working with shared memory.

776
00:38:59.400 --> 00:38:59.840
<v Speaker 1>Okay.

777
00:39:00.320 --> 00:39:04.559
<v Speaker 2>Krisk explains how Linux provides tools like semaphores and mutexes

778
00:39:05.320 --> 00:39:08.599
<v Speaker 2>to control access to shared resources and prevent data corruption

779
00:39:08.800 --> 00:39:09.800
<v Speaker 2>or raise conditions.

780
00:39:09.960 --> 00:39:12.599
<v Speaker 1>So it's like having a lock on the door to

781
00:39:12.679 --> 00:39:16.599
<v Speaker 1>the bulletin board, ensuring that only one process can write

782
00:39:16.599 --> 00:39:18.639
<v Speaker 1>to it at a time precisely. Okay.

783
00:39:18.800 --> 00:39:23.440
<v Speaker 2>Synchronization is crucial for ensuring data integrity when multiple processes

784
00:39:23.559 --> 00:39:25.199
<v Speaker 2>are accessing shared resources.

785
00:39:25.440 --> 00:39:28.519
<v Speaker 1>Now we've journeyed deep into the world of Linux system programming,

786
00:39:29.079 --> 00:39:33.960
<v Speaker 1>exploring everything from processes and memory, to file systems, and

787
00:39:34.039 --> 00:39:37.000
<v Speaker 1>even these critical interprocess communication methods.

788
00:39:37.079 --> 00:39:38.079
<v Speaker 2>It's been quite a journey.

789
00:39:38.119 --> 00:39:40.199
<v Speaker 1>It really has I feel like I've gained a whole

790
00:39:40.239 --> 00:39:43.920
<v Speaker 1>new appreciation for the intricate world of Linux system programming.

791
00:39:44.000 --> 00:39:46.559
<v Speaker 2>It's a fascinating world it is. It is full of

792
00:39:46.559 --> 00:39:47.400
<v Speaker 2>intricate detail.

793
00:39:47.519 --> 00:39:50.360
<v Speaker 1>In Karrisk's book is a great guide to navigating that

794
00:39:50.400 --> 00:39:51.159
<v Speaker 1>world it is.

795
00:39:51.280 --> 00:39:53.880
<v Speaker 2>It's a valuable resource for anyone who wants to master

796
00:39:53.960 --> 00:39:59.039
<v Speaker 2>this craft. It's packed with insights, examples, and practical advice

797
00:39:59.559 --> 00:40:02.480
<v Speaker 2>that can really help elevate your skills as a Linux developer.

798
00:40:02.760 --> 00:40:05.639
<v Speaker 1>For our listeners, if you're intrigued by the power and

799
00:40:05.760 --> 00:40:10.519
<v Speaker 1>flexibility of Linux and want to delve deeper into system programming,

800
00:40:10.599 --> 00:40:12.440
<v Speaker 1>I highly recommend checking out this book.

801
00:40:12.559 --> 00:40:14.239
<v Speaker 2>It's a must read. Yeah, for sure.

802
00:40:14.679 --> 00:40:17.480
<v Speaker 1>This deep dive has been an incredible journey. It has

803
00:40:17.639 --> 00:40:20.159
<v Speaker 1>I feel like we've learned so much. Me too, and

804
00:40:20.199 --> 00:40:22.320
<v Speaker 1>we've only just scratched the surface we have.

805
00:40:22.519 --> 00:40:25.280
<v Speaker 2>But that's the beauty of it. There's always more to explore.

806
00:40:25.440 --> 00:40:29.320
<v Speaker 1>That's true. That's the beauty of Linux exactly. That's a

807
00:40:29.320 --> 00:40:33.320
<v Speaker 1>wrap for this deep dive. Until next time, happy coding,