1
00:00:00,000 --> 00:00:02,720
 Boom, boom, boom, boom, boom, boom,

2
00:00:02,720 --> 00:00:05,280
 Linux Prepper.

3
00:00:05,280 --> 00:00:08,000
 Welcome back to Linux Prepper.

4
00:00:08,000 --> 00:00:11,200
 A self-hosted show on using free and open source technology

5
00:00:11,199 --> 00:00:14,839
 to DIY everything myself while still enjoying life.

6
00:00:14,839 --> 00:00:18,600
 Shows inspired by Linux, BSD, open source, and FOS.

7
00:00:18,600 --> 00:00:21,760
 It's part of James.Network and Living Cartoon Company.

8
00:00:21,760 --> 00:00:23,240
 If you're interested in the episode

9
00:00:23,239 --> 00:00:24,080
 and want to send me thoughts,

10
00:00:24,079 --> 00:00:26,440
 you can email podcast@james.network.

11
00:00:26,440 --> 00:00:28,719
 There is also a matrix chat you are welcome to join

12
00:00:28,719 --> 00:00:31,800
 and a forum at discuss.james.network.

13
00:00:31,800 --> 00:00:33,159
 Note the show is subject to change,

14
00:00:33,159 --> 00:00:34,200
 depending on how it's received.

15
00:00:34,200 --> 00:00:37,579
 There's no hard commitments, just frustration and fun.

16
00:00:38,520 --> 00:00:41,760
 So people have requested a more concise version of the show,

17
00:00:41,759 --> 00:00:43,840
 which I'm actually giving you today,

18
00:00:43,840 --> 00:00:45,679
 plus a massive interview

19
00:00:45,679 --> 00:00:48,519
 that's world premiering NextCloud Atomic

20
00:00:48,520 --> 00:00:51,519
 by discussing it at length with the developer Tobias

21
00:00:51,520 --> 00:00:54,519
 who's known for NextCloud Pie and NextCloud Secrets.

22
00:00:54,520 --> 00:00:56,399
 We'll also be joined by Marcel,

23
00:00:56,399 --> 00:00:58,719
 another NextCloud developer you might remember

24
00:00:58,719 --> 00:01:02,960
 from the NextCloud Recognize AI interview we did

25
00:01:02,960 --> 00:01:07,200
 on the use of AI and machine learning in NextCloud as an open source

26
00:01:07,200 --> 00:01:13,519
 project. So Marcel is also known as the developer of NextCloud Bookmarks and Flockus. And despite

27
00:01:13,519 --> 00:01:19,599
 me barely talking in it, the interview actually ran two hours 30 minutes plus making it the longest

28
00:01:19,599 --> 00:01:26,200
 NextCloud interview I'm aware of in existence. So I hope you enjoy it. Do let me know your thoughts

29
00:01:26,200 --> 00:01:28,079
 and note some portions of the interview

30
00:01:28,079 --> 00:01:31,480
 have been pulled for release in the future

31
00:01:31,480 --> 00:01:33,120
 just because this is already so long.

32
00:01:33,120 --> 00:01:36,200
 But your feedback is much appreciated.

33
00:01:36,200 --> 00:01:37,960
 Let's go, let's give a little context.

34
00:01:37,959 --> 00:01:42,240
 The next cloud conference is about to start in Berlin, Germany.

35
00:01:42,239 --> 00:01:45,959
 That is from September 27th to the 28th. You can attend

36
00:01:45,959 --> 00:01:51,200
 in person if you were in Berlin for free or watch online as it live streams. Note that

37
00:01:51,200 --> 00:01:57,120
 this is nine hours solidly ahead of America. So you'll probably be asleep when it happens

38
00:01:57,120 --> 00:02:01,120
 if you're in the US, where you'll be staying up all night. And recordings will be made

39
00:02:01,120 --> 00:02:05,159
 available both in full and in sections on YouTube over the coming days.

40
00:02:05,159 --> 00:02:08,199
 Tobias will be presenting a lightning talk

41
00:02:08,199 --> 00:02:10,439
 about the development of next cloud atomic.

42
00:02:10,439 --> 00:02:12,000
 I don't know exactly what he'll talking about,

43
00:02:12,000 --> 00:02:13,919
 but we can tune in.

44
00:02:13,919 --> 00:02:16,280
 It'll be the condensed version seven minutes.

45
00:02:17,199 --> 00:02:18,879
 Also, just wanna make a quick note

46
00:02:18,879 --> 00:02:22,680
 that Seagull Conference is coming up November 7th to 8th

47
00:02:22,680 --> 00:02:25,520
 in Seattle, I will be tabling and presenting there.

48
00:02:25,520 --> 00:02:29,240
 The schedule for that should be available on October 1st.

49
00:02:29,240 --> 00:02:31,039
 Link to that in the show notes.

50
00:02:31,039 --> 00:02:34,719
 I'd also like to take this moment to thank our sponsor.

51
00:02:34,719 --> 00:02:39,280
 That would be Ameradroid, the United States-based distributor of single board computers and home

52
00:02:39,280 --> 00:02:40,599
 automation products.

53
00:02:40,599 --> 00:02:49,000
 They offer comprehensive, inexpensive shipping solutions globally, have excellent customer service, and are a lot easier to deal with than ordering directly overseas with

54
00:02:49,000 --> 00:02:52,319
 the longer lead times, fewer shipping options, and tariffs.

55
00:02:52,319 --> 00:02:54,479
 And I've been a happy customer with them for years.

56
00:02:54,479 --> 00:02:59,759
 I'll leave referral links in the show notes, or you can use Linux Prepper at checkout to

57
00:02:59,759 --> 00:03:00,920
 support the show.

58
00:03:00,919 --> 00:03:03,000
 I do have a device I'd recommend from them.

59
00:03:03,000 --> 00:03:10,800
 If you're curious, it's called the O-Droid H4 series. There's the H4+, and Ultra. These are X86 boards. They're not

60
00:03:10,800 --> 00:03:17,120
 ARM. So it's just full X86. They do not include RAM or a case, but they do include

61
00:03:17,120 --> 00:03:23,280
 SATA ports and M2 slot for NVM expansion. This means you get to add up to 48GB of RAM, and

62
00:03:23,280 --> 00:03:25,000
 the M2 slot can be used for networking expansion.

63
00:03:25,000 --> 00:03:33,000
 I've asked around and confirmed that the ODRED H4 works just fine for basic TrueNAS Scalebox or backup server,

64
00:03:33,000 --> 00:03:47,680
 runs Proxmox, Open Media Vault, NextCloud, great tool, check it out, I'll leave a link in the show notes. All right, skipping ahead, let's go over a quick overview and review of Next Cloud itself and the related tooling,

65
00:03:47,680 --> 00:03:49,719
 which is being discussed in the interview.

66
00:03:51,039 --> 00:03:53,879
 Feel free to use the timestamps to skip ahead

67
00:03:53,879 --> 00:03:55,520
 to the interview.

68
00:03:55,520 --> 00:03:57,360
 So Next Cloud, let's talk Next Cloud.

69
00:03:57,360 --> 00:03:59,960
 Next Cloud is the most popular open source content

70
00:03:59,960 --> 00:04:02,560
 collaboration platform in the world.

71
00:04:02,560 --> 00:04:04,759
 It started as a Dropbox alternative.

72
00:04:04,759 --> 00:04:07,560
 It's grown to be rebranded as NextCloud Hub

73
00:04:07,560 --> 00:04:10,000
 because it's more of a Google Suite alternative.

74
00:04:10,000 --> 00:04:13,319
 Now, for enterprise clients with millions of users,

75
00:04:13,319 --> 00:04:16,819
 in addition to home enthusiasts with one or more users.

76
00:04:16,819 --> 00:04:20,680
 So it can be expanded with hundreds of apps and integrations

77
00:04:20,680 --> 00:04:24,360
 for things like Office tooling, bookmarks, you name it.

78
00:04:24,360 --> 00:04:30,399
 So NextCloud the company offers paid enterprise subscriptions for hundred plus user instances

79
00:04:30,399 --> 00:04:33,899
 They're paying per person right that is not our interest in this show

80
00:04:34,519 --> 00:04:41,199
 But their software is fully open source a GPL license and it has basic community support

81
00:04:42,439 --> 00:04:46,079
 Though keep in mind this is a modular system,

82
00:04:46,079 --> 00:04:49,399
 which means that it is built on a standard web stack, right?

83
00:04:49,399 --> 00:04:52,199
 You have a web server, you have a database,

84
00:04:52,199 --> 00:04:54,879
 you might have caching from something like Redis,

85
00:04:54,879 --> 00:04:57,600
 you choose how the system is made,

86
00:04:57,600 --> 00:05:00,439
 much like WordPress, probably the most common way

87
00:05:00,439 --> 00:05:04,279
 to use a website, run a website in the world.

88
00:05:04,279 --> 00:05:06,240
 You'll notice that there's a lot of providers

89
00:05:06,240 --> 00:05:11,759
 of WordPress, just like there's a lot of providers of NextCloud because anyone can run it, which

90
00:05:11,759 --> 00:05:17,360
 includes companies reselling, right? So companies might do this. I think this is also one of the

91
00:05:17,360 --> 00:05:25,000
 biggest negatives of NextCloud is that a lot of the people that are reselling it to you are trash.

92
00:05:26,779 --> 00:05:29,620
 I'll give a shout out to a company that's great.

93
00:05:29,620 --> 00:05:30,560
 It's called Hetsner.

94
00:05:30,560 --> 00:05:33,879
 Hetsner in Germany, I have seen NextCloud themselves

95
00:05:33,879 --> 00:05:37,899
 using Hetsner to host things for them for their conferences

96
00:05:37,899 --> 00:05:40,720
 when I attended and I can recommend Hetsner.

97
00:05:40,720 --> 00:05:42,860
 I don't know anyone that really has a problem with them.

98
00:05:42,860 --> 00:05:44,120
 They were great.

99
00:05:44,120 --> 00:05:49,639
 They offer very inexpensive terabyte plus options with the limited users of NextCloud.

100
00:05:49,639 --> 00:05:51,600
 So I would use Hetsner.

101
00:05:51,600 --> 00:05:57,079
 And basically everyone else offering NextCloud personally, I would not recommend.

102
00:05:57,079 --> 00:06:01,699
 So I have a history with NextCloud as far as being an form admin over a number of years

103
00:06:01,699 --> 00:06:02,959
 with them.

104
00:06:02,959 --> 00:06:06,579
 And as terms of all the resellers offering NextCloud,

105
00:06:06,579 --> 00:06:08,899
 I would not use any of them.

106
00:06:08,899 --> 00:06:11,220
 I would of course recommend running it yourself

107
00:06:11,220 --> 00:06:13,819
 or running it on something like a VPS

108
00:06:13,819 --> 00:06:16,139
 where you still have some level of control.

109
00:06:16,139 --> 00:06:18,620
 You never know when someone's just gonna go away

110
00:06:18,620 --> 00:06:20,620
 with a plan or with support.

111
00:06:20,620 --> 00:06:24,300
 And that's a thing that can happen on any system

112
00:06:24,300 --> 00:06:25,819
 and that includes NextCloud.

113
00:06:25,819 --> 00:06:28,860
 So I personally have been a volunteer with NextCloud

114
00:06:28,860 --> 00:06:29,779
 over a number of years.

115
00:06:29,779 --> 00:06:31,860
 Volunteer is an admin for their help forum,

116
00:06:31,860 --> 00:06:34,740
 and I participated as a speaker at their conference

117
00:06:34,740 --> 00:06:36,139
 three times.

118
00:06:36,139 --> 00:06:38,100
 I've not mentioned it so much on the show,

119
00:06:38,100 --> 00:06:40,939
 but I wanted to give a moment just to give you

120
00:06:40,939 --> 00:06:42,860
 some clarification about this.

121
00:06:42,860 --> 00:06:44,819
 I'm really pleased to have this opportunity,

122
00:06:44,819 --> 00:06:46,459
 and I hope you enjoy the interview.

123
00:06:46,459 --> 00:06:48,120
 It does run really long,

124
00:06:48,120 --> 00:06:52,019
 which is why I'm gonna split it up across at least two episodes.

125
00:06:52,019 --> 00:06:53,959
 Right now the main goal is to talk about

126
00:06:53,959 --> 00:06:57,779
 next cloud atomic as the successor to next cloud pi

127
00:06:57,779 --> 00:06:59,540
 because that's gonna be discussed also

128
00:06:59,540 --> 00:07:01,819
 at the upcoming conference.

129
00:07:01,819 --> 00:07:04,620
 Let's take a moment to do some self-hosted

130
00:07:04,620 --> 00:07:06,079
 relating spotlights. Of course these will some self-hosted relating spotlights.

131
00:07:06,079 --> 00:07:10,000
 Of course, these will be self-hosted options for NextCloud.

132
00:07:10,000 --> 00:07:12,000
 So what is NextCloud Pie?

133
00:07:12,000 --> 00:07:15,240
 Well, just like I was talking about the modular nature

134
00:07:15,240 --> 00:07:18,759
 of NextCloud, NextCloud Pie is a ready-to-use image

135
00:07:18,759 --> 00:07:23,120
 of NextCloud for x86, but also ARM and Debian systems

136
00:07:23,120 --> 00:07:24,279
 in general.

137
00:07:24,279 --> 00:07:28,000
 It supports the major single- board devices and virtual machine devices.

138
00:07:28,000 --> 00:07:32,000
 It gives you a next cloud with as little pain as possible

139
00:07:32,000 --> 00:07:36,000
 for the sake of running it and having it work as a home enthusiast.

140
00:07:36,000 --> 00:07:40,000
 So what it is, is it's an easy to use image. It takes the pain out of next cloud.

141
00:07:40,000 --> 00:07:43,000
 It's good for people who just want something that works.

142
00:07:43,000 --> 00:07:49,920
 What this isn't. It isn't a virtual playground design for system experts if you knew exactly what you wanted to begin with

143
00:07:49,920 --> 00:07:54,379
 Then you're probably not looking at next cloud pie. You're probably making your own

144
00:07:55,000 --> 00:08:01,139
 Next cloud so next cloud pie is notably not good at supporting things like containers

145
00:08:01,660 --> 00:08:08,959
 Docker these sorts of things. It's. It's meant as a set and forget option.

146
00:08:08,959 --> 00:08:12,519
 You set it up and then you are as hands off as possible.

147
00:08:12,519 --> 00:08:15,600
 If that's your goal, I think you will really like

148
00:08:15,600 --> 00:08:18,000
 Next Cloud Pi and I've run it for many years,

149
00:08:18,000 --> 00:08:19,000
 it's been great.

150
00:08:20,680 --> 00:08:23,000
 Next Cloud, AIO or All in One

151
00:08:23,000 --> 00:08:25,000
 is a Docker-based solution of NextCloud

152
00:08:25,000 --> 00:08:29,000
 that aims to simplify the installation and management of NextCloud

153
00:08:29,000 --> 00:08:33,000
 by combining all the necessary components into a single container.

154
00:08:33,000 --> 00:08:38,000
 It provides an easy way to deploy NextCloud with features like file sharing,

155
00:08:38,000 --> 00:08:41,000
 communication tools, and backup solutions.

156
00:08:41,000 --> 00:08:46,679
 Further, NextCloud AO is built and maintained

157
00:08:46,679 --> 00:08:50,159
 by NextCloud employees, which is nice.

158
00:08:52,159 --> 00:08:55,759
 Also worth giving a mention to the NextCloud Snap.

159
00:08:55,759 --> 00:08:57,480
 Some people like using the Snap

160
00:08:57,480 --> 00:09:02,480
 as another sort of effortless way to deploy NextCloud.

161
00:09:02,600 --> 00:09:04,200
 I have not personally used it myself,

162
00:09:04,200 --> 00:09:05,679
 but I know many people do. So you can also check out the NextCloud. I have not personally used it myself, but I know many people do.

163
00:09:05,679 --> 00:09:09,919
 So you can also check out the NextCloud Snap installation.

164
00:09:09,919 --> 00:09:14,480
 There are also various NextCloud virtual machine instances.

165
00:09:15,919 --> 00:09:17,080
 Whew, there's a lot.

166
00:09:18,720 --> 00:09:22,440
 Let's take a moment to do some software spotlights.

167
00:09:30,419 --> 00:09:36,340
 Flockis. Flockis is a bookmark syncing app for browsers iOS and Android. It syncs your bookmarks and tabs either to next cloud,

168
00:09:36,340 --> 00:09:43,600
 link warden, carekeep, git, basic web dev server. It's easy to connect into your

169
00:09:43,600 --> 00:09:46,080
 self-hosting service or to something like Google

170
00:09:46,080 --> 00:09:54,000
 Drive or GitHub. Flock is just tries to sync and get out of your way. Next cloud bookmarks is the

171
00:09:54,000 --> 00:10:06,000
 next cloud bookmark app you can optionally install, which will allow you to use something like like Floccus or the web UI to add and synchronize bookmarks

172
00:10:06,000 --> 00:10:10,000
 between your different Next Cloud clients.

173
00:10:10,000 --> 00:10:15,840
 I've used this successfully with Windows, Mac OS, Firefox,

174
00:10:15,840 --> 00:10:19,799
 Chromium, whatever you can think of.

175
00:10:19,799 --> 00:10:20,480
 I've done it.

176
00:10:20,480 --> 00:10:22,080
 It works awesome.

177
00:10:22,080 --> 00:10:24,000
 I absolutely love Next Cloud Bookmarks.

178
00:10:24,000 --> 00:10:25,360
 It's one of my favorite apps of all time. I've done some testing on it in the past. I think it is a works awesome. I absolutely love next cloud bookmarks. It's one of my favorite apps of all

179
00:10:25,360 --> 00:10:30,320
 time. I've done some testing on it in the past. I think it is a great tool and I highly recommend

180
00:10:30,320 --> 00:10:38,000
 checking out next cloud bookmarks if you're running next cloud. Recognize AI is a photo

181
00:10:38,000 --> 00:10:46,799
 recognition enhancement application for next cloud. It is system intensive. It basically requires x86.

182
00:10:46,799 --> 00:10:48,879
 It's not designed for single board computers

183
00:10:48,879 --> 00:10:49,960
 or anything like this,

184
00:10:49,960 --> 00:10:51,720
 but if you have powerful hardware

185
00:10:51,720 --> 00:10:53,840
 and you wanna add basic machine learning

186
00:10:53,840 --> 00:10:57,600
 to your NextCloud to do local first photo recognition,

187
00:10:57,600 --> 00:11:00,399
 that is totally possible to recognize AI.

188
00:11:00,399 --> 00:11:03,159
 I'll also leave a link to our previous interview

189
00:11:03,159 --> 00:11:06,320
 about recognize AI and the use of machine learning next cloud

190
00:11:06,320 --> 00:11:07,799
 from previous episode.

191
00:11:07,799 --> 00:11:10,480
 Check that out if you're interested.

192
00:11:10,480 --> 00:11:14,399
 Also in the self-hosted spotlight is the upcoming

193
00:11:14,399 --> 00:11:16,879
 NextCloud Atomic.

194
00:11:16,879 --> 00:11:19,879
 NextCloud Atomic is the easy-to-use batteries

195
00:11:19,879 --> 00:11:23,720
 included system for running NextCloud.

196
00:11:23,720 --> 00:11:28,320
 It is a wrapper for NextClouds all in one.

197
00:11:28,320 --> 00:11:31,039
 It provides the convenience of automated updates

198
00:11:31,039 --> 00:11:33,399
 and a number of additional services

199
00:11:33,399 --> 00:11:36,840
 that can be enabled individually on top of the system.

200
00:11:36,840 --> 00:11:39,700
 Things like disk management, full disk encryption,

201
00:11:39,700 --> 00:11:44,080
 TPM support, monitoring, and making everything accessible

202
00:11:44,080 --> 00:11:46,240
 from an administrative interface.

203
00:11:46,240 --> 00:11:48,600
 Next Cloud Atomic's aim is to provide all the tools

204
00:11:48,600 --> 00:11:51,320
 you would need to host Next Cloud as a hobbyist

205
00:11:51,320 --> 00:11:54,200
 or as a company assuming your needs can be covered

206
00:11:54,200 --> 00:11:56,240
 by a singular machine.

207
00:11:56,240 --> 00:11:58,639
 One of the core selling points of Next Cloud Atomic

208
00:11:58,639 --> 00:12:00,759
 is the operating system layout.

209
00:12:00,759 --> 00:12:03,679
 Everything related to the core system is contained

210
00:12:03,679 --> 00:12:05,279
 in an immutable partition that

211
00:12:05,279 --> 00:12:10,200
 gets replaced during updates, which allows for painless updates to either fully succeed

212
00:12:10,200 --> 00:12:15,899
 or fully fail and be automatically rolled back. There is no in between. Apart from updates,

213
00:12:15,899 --> 00:12:20,399
 this also enables a simple factory reset feature, which can be used to restore the system to

214
00:12:20,399 --> 00:12:24,480
 a working state in the event something goes wrong. The operating system is Debian as

215
00:12:24,480 --> 00:12:26,000
 its base, which is widely

216
00:12:26,000 --> 00:12:28,320
 trusted as a surper operating system.

217
00:12:28,639 --> 00:12:32,559
 Next Cloud atomic was made possible in part by the

218
00:12:32,559 --> 00:12:35,279
 prototype fund, the prototype fund.

219
00:12:35,279 --> 00:12:36,639
 Let's get into what that is.

220
00:12:36,919 --> 00:12:40,960
 Prototype fund is a fund for German developers seeking to work

221
00:12:40,960 --> 00:12:44,840
 on free and open source projects, offering six months of

222
00:12:44,840 --> 00:12:45,320
 funding so that you can work on your project. source projects, offering six months of funding

223
00:12:45,320 --> 00:12:46,799
 so that you can work on your project.

224
00:12:46,799 --> 00:12:49,519
 This includes projects like Next Cloud Atomic,

225
00:12:49,519 --> 00:12:52,039
 which we will be talking about today.

226
00:12:52,039 --> 00:12:54,080
 If you're interested in the Prototype Fund,

227
00:12:54,080 --> 00:12:57,000
 I will include a link in the show notes.

228
00:12:57,000 --> 00:12:59,679
 If you like the show, please do share it with others.

229
00:12:59,679 --> 00:13:01,559
 I am running a Steam key giveaway.

230
00:13:01,559 --> 00:13:03,679
 All I ask in return is you leave a review

231
00:13:03,679 --> 00:13:08,720
 on your podcast system of choice, no more than three entries per person, please. And please just leave more

232
00:13:08,720 --> 00:13:13,759
 than a one word review. Say anything you want. It doesn't matter. But that runs through November

233
00:13:13,759 --> 00:13:18,399
 1st right now and details on it are in the show notes. I hope you enjoy this long format

234
00:13:18,399 --> 00:13:23,159
 interview. And I want to say thank you to everyone who submitted your questions, concerns,

235
00:13:23,159 --> 00:13:25,279
 comments, especially the people

236
00:13:25,279 --> 00:13:30,200
 from the next cloud pie community where I've been a community manager over the years and

237
00:13:30,200 --> 00:13:33,080
 done my best to assist Tobias.

238
00:13:33,080 --> 00:13:37,240
 So we've done our best to address all of your concerns and questions here in the interview.

239
00:13:37,240 --> 00:13:40,919
 If you enjoy the show, keep in mind, you can always donate to me directly.

240
00:13:40,919 --> 00:13:47,120
 I will also include donation information for Tobias is in his projects as well as Marcel

241
00:13:47,120 --> 00:13:52,720
 either way. Thank you for listening. A quick moment of gratitude for Ignacio who is the original

242
00:13:52,720 --> 00:13:58,480
 developer of next cloud pie. Thank you so much for paving the way that allowed Toby is to take

243
00:13:58,480 --> 00:14:04,240
 over and allowed us to continue on to these exciting new steps today. You can always contact me through

244
00:14:04,240 --> 00:14:07,440
 email by following the podcast directly on the Fediverse

245
00:14:07,440 --> 00:14:09,639
 or your podcast platform of choice.

246
00:14:09,639 --> 00:14:12,700
 You can also join our Matrix chat and forum.

247
00:14:12,700 --> 00:14:14,399
 Please do enjoy this long format interview.

248
00:14:14,399 --> 00:14:16,559
 Look forward to even more discussion

249
00:14:16,559 --> 00:14:20,360
 dealing with Toby's Next Cloud Secrets application

250
00:14:20,360 --> 00:14:23,440
 in a future episode along with a focus

251
00:14:23,440 --> 00:14:26,240
 on container technology and whether tools like

252
00:14:26,240 --> 00:14:32,159
 Docker, Podman, and virtualization are right for you as a home enthusiast.

253
00:14:32,159 --> 00:14:36,799
 Thank you for listening to Linux Proper and let's go directly into the interview.

254
00:14:36,799 --> 00:14:38,320
 Welcome to the podcast.

255
00:14:38,320 --> 00:14:49,759
 Yeah, hi, I would say about six years fully employed and probably

256
00:14:50,960 --> 00:14:59,279
 about a to 10 years in my free time and privately. And I'm also working on a number of open source

257
00:14:59,279 --> 00:15:05,159
 projects among others, next slide atomic. Actually, for some reason,

258
00:15:05,159 --> 00:15:09,159
 most of the big open source project that I'm working on

259
00:15:09,159 --> 00:15:11,600
 within the Nestle ecosystem,

260
00:15:11,600 --> 00:15:15,000
 probably just because that's the one open source product

261
00:15:15,000 --> 00:15:17,320
 I use the most personally,

262
00:15:17,320 --> 00:15:19,720
 and that gives me a lot of value.

263
00:15:19,720 --> 00:15:24,720
 And yeah, so I'm working on Next Light Atomic,

264
00:15:25,000 --> 00:15:25,399
 Next Light Pie and Next Light Secrets mostly. And yeah, so I'm working on next-class atomic,

265
00:15:29,519 --> 00:15:30,759
 next-class py and next-class secrets mostly, during that.

266
00:15:30,759 --> 00:15:35,759
 Right now I'm in the process of working

267
00:15:36,440 --> 00:15:39,200
 as a freelance engineer full-time,

268
00:15:40,320 --> 00:15:44,399
 which has also the reason that I hope to be able

269
00:15:44,399 --> 00:15:46,480
 to focus more on my open source work that way,

270
00:15:47,200 --> 00:15:49,200
 but also be more flexible in

271
00:15:49,899 --> 00:15:54,279
 just generally what I want to focus on in my life and in my work.

272
00:15:56,759 --> 00:15:59,200
 I think, yeah, I think that's about

273
00:16:00,080 --> 00:16:03,759
 what there is to know right now for this context, for this broadcast.

274
00:16:04,320 --> 00:16:05,399
 Yeah, sure.

275
00:16:05,399 --> 00:16:07,720
 I am Marcel, Marcel Player.

276
00:16:08,559 --> 00:16:17,279
 I work for NextCloud full time currently for about three years now.

277
00:16:18,200 --> 00:16:19,759
 And have been

278
00:16:20,600 --> 00:16:27,000
 tabbling in open source projects for a number of years, about 10 I think.

279
00:16:27,000 --> 00:16:36,000
 Yeah, and I'm currently in my free time mostly focusing on floccus, floccus

280
00:16:36,000 --> 00:16:46,080
 bookmark syncing, which allows people to sync bookmarks across browser vendors and the NextCloud Bookmarks app

281
00:16:47,480 --> 00:16:50,299
 that acts as a backend for flocca

282
00:16:50,299 --> 00:16:52,620
 and as a standalone bookmarks app

283
00:16:52,620 --> 00:16:54,320
 in the NextCloud ecosystem.

284
00:16:59,399 --> 00:17:02,159
 Yeah, that's mostly it.

285
00:17:02,159 --> 00:17:05,720
 I've been on this podcast previously talking about AI

286
00:17:05,720 --> 00:17:08,799
 at NextCloud, which I'm involved in.

287
00:17:10,759 --> 00:17:11,799
 Yeah.

288
00:17:11,799 --> 00:17:12,640
 - Thank you.

289
00:17:14,400 --> 00:17:17,720
 Also, thank you for floccas.

290
00:17:17,720 --> 00:17:20,319
 I'm using that personally, actually.

291
00:17:20,319 --> 00:17:21,480
 - Nice.

292
00:17:21,480 --> 00:17:22,880
 It's always great to hear that.

293
00:17:23,880 --> 00:17:29,000
 - Although I'm not using it across browser yet, I think the idea just never occurred to me.

294
00:17:29,000 --> 00:17:33,000
 But yeah, lost opportunity there.

295
00:17:33,000 --> 00:17:35,000
 Which browser are you using?

296
00:17:35,000 --> 00:17:37,000
 Firefox mostly.

297
00:17:37,000 --> 00:17:40,000
 Contential question, contentious question.

298
00:17:40,000 --> 00:17:48,480
 Yeah, right now I don't really have the one browser I'm happy with. I support Firefox because I want to.

299
00:17:49,519 --> 00:17:55,599
 I'm not happy about the Google monopoly, of course, but at the same time, Mozilla.

300
00:17:58,079 --> 00:18:06,559
 It's very good at doing shady stuff every now and then, and I'm not too happy about that either and yeah it's

301
00:18:06,559 --> 00:18:13,359
 a work in process, a work in progress I would say. Totally agree. And do you mind

302
00:18:13,359 --> 00:18:30,720
 giving us an overview on what Next Cloud Pi and Atomic are? Sure. Yeah so maybe I just start with an extra pile because it's the more well-known and

303
00:18:30,720 --> 00:18:33,460
 the actually used product.

304
00:18:33,460 --> 00:18:40,119
 The other one is not in a usable stage just yet.

305
00:18:40,119 --> 00:18:45,559
 So an extra pile is basically, or I should say differently.

306
00:18:45,559 --> 00:18:47,559
 When you are running your next cloud,

307
00:18:47,559 --> 00:18:52,319
 you need to find a way of installing

308
00:18:52,319 --> 00:18:54,740
 and configuring NextCloud itself,

309
00:18:54,740 --> 00:18:59,740
 but you also need ways of managing your operating system,

310
00:18:59,759 --> 00:19:04,759
 your web server, your domain backups and so on.

311
00:19:04,960 --> 00:19:05,000
 So there are a lot of administrative tasks involved web server, your domain backups and so on.

312
00:19:05,000 --> 00:19:09,400
 So there are a lot of administrative tasks involved

313
00:19:09,400 --> 00:19:12,240
 in running a next cloud server.

314
00:19:12,240 --> 00:19:17,240
 And next cloud py basically takes a Debian system

315
00:19:19,160 --> 00:19:21,920
 and automates all of that stuff,

316
00:19:21,920 --> 00:19:24,319
 all of the administrative tasks starting

317
00:19:24,319 --> 00:19:26,160
 from the installation of next cloud

318
00:19:26,799 --> 00:19:31,039
 and ending with backups dynamic DNS.

319
00:19:35,759 --> 00:19:41,440
 Many, like backups, many features, server-side encryption and so on,

320
00:19:41,440 --> 00:19:45,039
 many features that you would have to solve manually as a systems

321
00:19:45,039 --> 00:19:55,200
 administrator. And the result is a system that allows you to run next cloud without ever interacting

322
00:19:55,200 --> 00:20:05,619
 with a terminal if you don't want to, because everything is configurable from an administration web user interface.

323
00:20:05,619 --> 00:20:09,880
 So that's, I would say, what next Cloud Pi is.

324
00:20:09,880 --> 00:20:19,200
 I sometimes call it managed self-hosting because it is the managed hosting experience but on

325
00:20:19,200 --> 00:20:22,880
 your own hardware.

326
00:20:22,880 --> 00:20:29,000
 And something that I should address because it always gets misunderstood.

327
00:20:29,000 --> 00:20:35,500
 Next slide is not specifically built for the Raspberry Pi, even though it has a Pi in the

328
00:20:35,500 --> 00:20:48,799
 name, but it does support a wide range of single board computers like the Raspberry Pi including it, but it also is available for VMs and containers,

329
00:20:48,799 --> 00:20:51,000
 LXD containers.

330
00:20:51,000 --> 00:20:57,440
 I, for example, run my currently,

331
00:20:57,440 --> 00:21:00,940
 my next-door instance that is currently backed by

332
00:21:00,940 --> 00:21:08,119
 an extra Pi on just a server server I built myself with consumer hardware

333
00:21:08,119 --> 00:21:31,000
 running Proxmox and they're inside of a container. So that's an X-LOT Pi. Yeah, I have been a user of NextCloud PIE for, I believe about seven years.

334
00:21:31,000 --> 00:21:37,240
 I should have looked up the numbers before the podcast.

335
00:21:37,240 --> 00:21:48,039
 But basically when NextCloud came into existence, a few months after I changed to Next cloud and

336
00:21:48,039 --> 00:21:55,920
 probably half a year or a year after I switched to Next cloud pi and it saved

337
00:21:55,920 --> 00:22:01,920
 me a lot of work back then and about two years ago I took over

338
00:22:01,920 --> 00:22:05,420
 maintain a ship of the project completely before I was

339
00:22:05,420 --> 00:22:14,859
 contributing a few things and now I am the core maintainer of the project

340
00:22:14,859 --> 00:22:26,720
 basically. And yeah, I think that's a good basis maybe to directly talk

341
00:22:26,720 --> 00:22:30,440
 about an extra atomic because it is similar in many ways

342
00:22:30,440 --> 00:22:36,240
 and does some things purposefully different

343
00:22:36,240 --> 00:22:39,079
 than extra time.

344
00:22:39,079 --> 00:22:42,519
 Basically, for the last six years,

345
00:22:42,519 --> 00:22:45,000
 I've been working as a,

346
00:22:45,880 --> 00:22:49,839
 yeah, professional software developer

347
00:22:49,839 --> 00:22:51,680
 and DevOps engineer.

348
00:22:51,680 --> 00:22:56,599
 I've been doing a lot of cloud application development

349
00:22:56,599 --> 00:23:01,599
 and cloud infrastructure and a lot of work with containers

350
00:23:02,279 --> 00:23:06,400
 and operating systems, build pipelines and so on. So a lot of work with containers and operating systems, build pipelines and so on.

351
00:23:06,400 --> 00:23:08,400
 So a lot of system level things,

352
00:23:08,400 --> 00:23:10,799
 but also application development.

353
00:23:10,799 --> 00:23:15,799
 And my knowledge about these things has been growing.

354
00:23:17,240 --> 00:23:21,079
 And I became a bit dissatisfied with the way

355
00:23:21,079 --> 00:23:23,119
 I was running NextCloud.

356
00:23:23,119 --> 00:23:30,160
 Because first of all, my skills have been,

357
00:23:30,799 --> 00:23:36,720
 yeah, have changed over the time. And I would do things differently than I did it

358
00:23:38,480 --> 00:23:45,279
 seven years ago. And secondly, the industry has changed. and there have been a lot of emerging technologies

359
00:23:45,279 --> 00:23:49,559
 that have not been as ubiquitous seven years ago.

360
00:23:49,559 --> 00:23:58,799
 For example, containers did expect them, but I don't think I have used them ever back then

361
00:23:58,799 --> 00:24:01,599
 and now I'm using them constantly.

362
00:24:01,599 --> 00:24:09,240
 Like that's always the go-to way of running an application is to see if there's a well-maintained and well-built

363
00:24:09,240 --> 00:24:13,880
 container for it because it makes life so much easier

364
00:24:13,880 --> 00:24:14,559
 if there is.

365
00:24:17,319 --> 00:24:21,599
 Also, a lot of--

366
00:24:21,599 --> 00:24:29,240
 yeah, I always had the issue. The next car I didn't fully cover the security

367
00:24:29,240 --> 00:24:35,599
 requirements that I had for running and yeah running extra interesting it was my

368
00:24:35,599 --> 00:24:47,220
 own data mainly because I didn't only want to encrypt the data directory, but I did want to

369
00:24:47,220 --> 00:24:54,579
 encrypt the full disk and that was not supported in extra pile. And secondly,

370
00:24:54,579 --> 00:25:01,500
 because there you need to jump through some hoops to be able to to encrypt the

371
00:25:01,500 --> 00:25:05,000
 full disk and still have your server reboot

372
00:25:05,000 --> 00:25:08,039
 without being physically near it.

373
00:25:08,039 --> 00:25:10,640
 So there were some challenges there.

374
00:25:10,640 --> 00:25:15,640
 And when I took over maintainer ship of Next.py,

375
00:25:16,319 --> 00:25:19,720
 I was exploring and considering options

376
00:25:19,720 --> 00:25:24,559
 to bring the project forward on those levels

377
00:25:24,559 --> 00:25:28,160
 and implement them. But ultimately

378
00:25:28,160 --> 00:25:33,799
 noticed that there are some things that I could never solve within the current

379
00:25:33,799 --> 00:25:42,319
 architecture. And so I decided to start a new project that would have a slightly

380
00:25:42,319 --> 00:25:48,880
 different objective and a slightly different goal and also target audience,

381
00:25:50,680 --> 00:25:55,680
 but would be at least as easy to use hopefully,

382
00:25:57,960 --> 00:26:00,319
 but a lot more professional

383
00:26:01,759 --> 00:26:07,160
 and yeah, following industry best practices in the way it solves things and

384
00:26:07,160 --> 00:26:14,640
 that project is next-out atomic. So next-out atomic is also like next-out

385
00:26:14,640 --> 00:26:21,240
 by a project that tries to solve the administration overhead that you get

386
00:26:21,240 --> 00:26:26,160
 when running next-out. The whole operating system management,

387
00:26:28,400 --> 00:26:52,559
 service configuration, backups, disk management, of maintenance, like on my side.

388
00:26:53,599 --> 00:27:01,039
 That was one of the issues with an extra pie that it takes a lot of effort to maintain.

389
00:27:10,160 --> 00:27:21,920
 of effort to maintain because well one of the issues is that the project is written mostly in Bash so it's about I think I counted it once 17 000 lines of Bash code and Bash is really nice

390
00:27:21,920 --> 00:27:25,000
 for automating operating system tasks.

391
00:27:25,000 --> 00:27:28,319
 Don't get me wrong, it's a very nice tool for that,

392
00:27:28,319 --> 00:27:32,680
 but there's a point where it causes issues

393
00:27:32,680 --> 00:27:37,680
 because especially Bash doesn't give you

394
00:27:37,720 --> 00:27:42,720
 a lot of guarantees of the environment and surrounding it.

395
00:27:44,759 --> 00:27:48,559
 Like a Bash trip could run and you wouldn't

396
00:27:48,559 --> 00:27:55,680
 notice if the variables it expects from the environment are set or not if they

397
00:27:55,680 --> 00:28:08,079
 have the right format if they like it doesn't support data types for variables. Basically everything is a string of characters. And

398
00:28:09,680 --> 00:28:17,599
 these things are different in more complex programming languages and that gives you a lot of guarantees

399
00:28:17,599 --> 00:28:30,079
 to notice early if you made a mistake in your code. And that among other things caused next cloud

400
00:28:30,079 --> 00:28:38,400
 pyre releases to always be a lot of hassle and effort to test and ensure

401
00:28:38,400 --> 00:28:45,000
 that there are no errors and it still caused errors to be overlooked in releases.

402
00:28:45,500 --> 00:28:47,440
 And with the new architecture,

403
00:28:47,440 --> 00:28:51,619
 I hope to have a more robust set

404
00:28:51,619 --> 00:28:53,700
 that can be more easily tested

405
00:28:53,700 --> 00:28:58,700
 and also is less prone to error sources like this.

406
00:28:58,900 --> 00:29:01,460
 And thus causes me less work

407
00:29:01,460 --> 00:29:06,559
 so I can better sustain it, which has become difficult for an Excel

408
00:29:06,559 --> 00:29:12,880
 Pi. So basically when an Excel Pi was created there were not many options to

409
00:29:12,880 --> 00:29:17,440
 host NextCloud because it was one of the... it was the early days of NextCloud

410
00:29:17,440 --> 00:29:28,480
 right. So NextCloud Pi manages the whole next cloud installation, database installation, PHP installation itself.

411
00:29:28,480 --> 00:29:35,200
 It has scripts for that. They work, but they need to be maintained and that takes a lot of the work

412
00:29:37,359 --> 00:29:45,000
 in maintaining the project. However, nowadays these things are actually solved

413
00:29:45,000 --> 00:29:46,880
 by other projects.

414
00:29:46,880 --> 00:29:50,559
 And I don't see a lot of value to solve them again

415
00:29:50,559 --> 00:29:52,579
 in my own project.

416
00:29:52,579 --> 00:29:54,200
 So with next electronic,

417
00:29:54,200 --> 00:29:58,119
 I actually integrate next to the order one,

418
00:29:58,119 --> 00:29:59,920
 which is maybe I should explain that

419
00:29:59,920 --> 00:30:04,920
 it's the multi-container deployment

420
00:30:12,160 --> 00:30:20,920
 that is developed at NextCloud itself at the company. And I actually integrate this container setup into NextCloud Atomic and focus a lot more

421
00:30:20,920 --> 00:30:25,519
 on the operating system tasks that are not solved by an excellent all-in-one.

422
00:30:25,519 --> 00:30:30,519
 So the heavy lifting in running NextCloud itself

423
00:30:32,319 --> 00:30:34,039
 and its surrounding services,

424
00:30:34,039 --> 00:30:37,839
 which have also increased over the time,

425
00:30:37,839 --> 00:30:41,319
 like now a classic NextCloud installation

426
00:30:41,319 --> 00:30:46,920
 has I think five containers or five services, depending on whether or not

427
00:30:46,920 --> 00:30:49,599
 you're actually using containers.

428
00:30:49,599 --> 00:30:55,440
 Like you have an ex-cloud itself, you have a web server, you have a Redis, you have a

429
00:30:55,440 --> 00:31:05,960
 database, and you have a service for talk. You have the unified push service.

430
00:31:07,859 --> 00:31:11,019
 And I think you will also have,

431
00:31:11,019 --> 00:31:16,019
 yeah, likely also a call of error online for office editing

432
00:31:16,539 --> 00:31:18,579
 and the whiteboard.

433
00:31:18,579 --> 00:31:22,700
 So it's actually eight services that you have to run

434
00:31:22,700 --> 00:31:28,839
 while it has been three to four when exit PI was created.

435
00:31:28,839 --> 00:31:38,000
 And this service management and configuration is now solved pretty well by an exit audit

436
00:31:38,000 --> 00:31:45,000
 in one. And so I'm integrating that, I'm fronting it with my own reverse proxy.

437
00:31:47,480 --> 00:31:52,480
 I'm doing some of the things that could be solved

438
00:31:52,680 --> 00:31:54,240
 by an oil and one, for example,

439
00:31:54,240 --> 00:31:56,640
 certificate management, backup management,

440
00:31:57,599 --> 00:32:01,240
 because I have more options to do them

441
00:32:01,240 --> 00:32:03,960
 on the operating system level,

442
00:32:03,960 --> 00:32:09,000
 or need more flexibility in how they are done.

443
00:32:09,000 --> 00:32:12,440
 But mostly I rely on an extra Doran one.

444
00:32:12,440 --> 00:32:19,279
 And I think that way I can actually better provide the value that an extra atomic is

445
00:32:19,279 --> 00:32:29,599
 adding by providing a robust and secure system and like operating system and additional

446
00:32:29,599 --> 00:32:37,039
 features that I'm not provided by the next one. Next up I, one of the bigger

447
00:32:37,039 --> 00:32:42,880
 shortcomings is that the build system is not compatible with running containers

448
00:32:42,880 --> 00:32:46,319
 inside of Next.py. I have actually--

449
00:32:46,319 --> 00:32:48,519
 I had started to push in the direction,

450
00:32:48,519 --> 00:32:51,759
 but ultimately realized it's too complicated,

451
00:32:51,759 --> 00:32:58,599
 because I basically had to rewrite the whole built system.

452
00:32:58,599 --> 00:33:02,119
 Currently, the built system installs NextCloud

453
00:33:02,119 --> 00:33:06,460
 and verifies certain things of the installation that they

454
00:33:06,460 --> 00:33:14,299
 worked during installation. And with containers, like the installation process

455
00:33:14,299 --> 00:33:20,460
 itself is running inside of containers and it's very hard to run containers

456
00:33:20,460 --> 00:33:30,200
 reliably inside of containers and expect them to be behave the same way as if they are not running instead of containers.

457
00:33:30,400 --> 00:33:36,000
 It's possible, but the engineering effort isn't worth it, in my opinion,

458
00:33:36,200 --> 00:33:43,200
 because you always would risk that in the end, you may

459
00:33:43,400 --> 00:33:45,000
 may be fixing things in containers

460
00:33:45,160 --> 00:33:46,880
 that are not fixed in the final system

461
00:33:46,880 --> 00:33:49,160
 and thus be overlooking errors.

462
00:33:51,359 --> 00:33:55,160
 And that's one of the shortcomings.

463
00:33:55,160 --> 00:33:58,880
 So I had difficulties to run something like

464
00:33:58,880 --> 00:34:03,880
 Nix.0 and one, or even things like the whiteboard itself

465
00:34:04,000 --> 00:34:06,839
 or even things like the whiteboard itself

466
00:34:09,760 --> 00:34:12,119
 inside of Nexcloud Pi as part of the, because the build process doesn't allow for it.

467
00:34:13,440 --> 00:34:17,840
 The second thing is one of the big pain points

468
00:34:17,840 --> 00:34:22,840
 for Nexcloud Pi is that it is running

469
00:34:22,960 --> 00:34:24,840
 a traditional operating system

470
00:34:28,079 --> 00:34:33,039
 with traditional update mechanisms, which next little atomic doesn't. I'll come to that in a second. And that means that

471
00:34:35,679 --> 00:34:49,199
 both the installation process and the update process is procedural. It runs some scripts, it applies them, it does some modifications to the system,

472
00:34:49,199 --> 00:34:51,820
 and hopefully it succeeds.

473
00:34:51,820 --> 00:34:58,420
 And if it doesn't, you will have to fix that to be able to go forward.

474
00:34:58,420 --> 00:35:07,000
 And that results in every system being slightly different. Because even if the script is the same,

475
00:35:07,000 --> 00:35:10,000
 the conditions in which it runs might not be.

476
00:35:10,000 --> 00:35:14,000
 For example, you have different features enabled.

477
00:35:14,000 --> 00:35:18,000
 You have a different date,

478
00:35:18,000 --> 00:35:21,000
 and you're using external packet repositories,

479
00:35:21,000 --> 00:35:24,000
 like the official Debian packages, for example.

480
00:35:24,000 --> 00:35:25,760
 And they have different versions

481
00:35:25,760 --> 00:35:31,360
 of packages at different dates. So there might be conflicts at one date and not another,

482
00:35:31,360 --> 00:35:38,480
 and thus your upgrade process might fail after some time without changing the process itself

483
00:35:38,480 --> 00:35:55,239
 and so on. These issues always existed for NextLoud Pie And next.atomic is using a separate approach in that it provides

484
00:35:55,239 --> 00:36:08,760
 the full disk image as is. And you download the final disk image, swap it out, like swap the previous disk image

485
00:36:08,760 --> 00:36:13,480
 with the new one and then you have the new version and if something goes wrong, you're

486
00:36:13,480 --> 00:36:32,000
 just stuck with the old version but not with a broken system in an intermediate state. And that also allows me to actually test everything just as you receive it as

487
00:36:32,000 --> 00:36:38,119
 next cloud atomic user and not have two processes that are both need to test that result in

488
00:36:38,119 --> 00:36:47,199
 different results and also result in every system even on the same version to be slightly different. So things can break in different ways.

489
00:36:48,699 --> 00:36:56,000
 And yeah, that was really something very painful with maintaining next

490
00:36:56,000 --> 00:37:01,400
 our pie because errors come up in ways that you cannot prevent as a maintainer.

491
00:37:01,400 --> 00:37:05,679
 >> Next Cloud Atomic itself is about immutability.

492
00:37:05,679 --> 00:37:08,920
 And that raises a question that's come in from listeners

493
00:37:08,920 --> 00:37:11,679
 wondering why you wouldn't just use something like say,

494
00:37:11,679 --> 00:37:16,320
 fedora silver blue or NixOS immutable operating systems

495
00:37:16,320 --> 00:37:18,840
 of Linux as your base.

496
00:37:20,639 --> 00:37:21,480
 - Yeah, definitely.

497
00:37:21,480 --> 00:37:26,820
 So actually I was considering some of these options.

498
00:37:26,820 --> 00:37:29,239
 Silver Blue is not a great much because it's

499
00:37:29,239 --> 00:37:33,400
 a desktop operation operating system with desktop manager

500
00:37:33,400 --> 00:37:35,519
 and so on included.

501
00:37:35,519 --> 00:37:41,639
 But there are other specifically other operating systems

502
00:37:41,639 --> 00:37:48,400
 specifically designed for that, like Fedora CoreOS for VMs or Fedora IoT

503
00:37:48,400 --> 00:37:51,719
 for basically IoT devices.

504
00:37:53,199 --> 00:37:56,760
 That actually look like they are designed for the job.

505
00:37:56,760 --> 00:37:59,679
 Also, there's the EUPLU,

506
00:37:59,679 --> 00:38:04,440
 a universal PLU project that offers a build framework

507
00:38:04,440 --> 00:38:10,559
 for building systems based on the

508
00:38:10,559 --> 00:38:34,559
 rat head atomic architecture for specific use cases and so on. is of course Nixos which I have also looked at then there is a yeah then

509
00:38:34,559 --> 00:38:45,000
 there are options from openSuser as well I forgot what's the name of the immutable server variant,

510
00:38:46,440 --> 00:38:48,440
 unfortunately, but yeah,

511
00:38:49,599 --> 00:38:52,420
 micro OS is the one that I was going for.

512
00:38:53,840 --> 00:38:56,199
 Yeah, open source of micro OS.

513
00:38:56,199 --> 00:38:57,539
 So that's also there.

514
00:38:59,039 --> 00:39:02,559
 Yeah, I have been considering many of these options.

515
00:39:02,559 --> 00:39:06,559
 I didn't consider some of them, especially BootC, which is

516
00:39:06,559 --> 00:39:13,280
 the basis for universal blue, for example, because when I started, it wasn't yet really available.

517
00:39:16,159 --> 00:39:28,760
 However, originally, I actually started with an entirely separate project or build system for building acceleratomic.

518
00:39:28,760 --> 00:39:33,239
 And I would actually like to mention that because I think it looks, it's really cool

519
00:39:33,239 --> 00:39:40,800
 and maybe it can be useful for some of your viewers or listeners to be more specific.

520
00:39:40,800 --> 00:39:48,699
 It's called skiff OS and it is basically a build framework around build route.

521
00:39:48,699 --> 00:40:11,400
 Build route being a tool for building minimal Linux systems from scratch for especially especially IoT and embedded devices. And that's really nice if you need something

522
00:40:11,400 --> 00:40:15,199
 where you want to be in control of every aspect.

523
00:40:15,199 --> 00:40:17,360
 You will be compiling a lot of things yourself,

524
00:40:17,360 --> 00:40:21,519
 but the build system takes care of compiling it.

525
00:40:21,519 --> 00:40:24,000
 So it's not difficult to do that.

526
00:40:24,000 --> 00:40:27,280
 It just takes some computation time. But you can

527
00:40:27,280 --> 00:40:35,199
 just compile all of the packages that you need specifically for your device and then you have a

528
00:40:35,199 --> 00:40:49,760
 ready image and skiffle as ads on top atomic updates and the ability to have and yeah it gives you a slightly easier configuration system and also

529
00:40:51,440 --> 00:40:57,760
 focuses on systems that are minimal but able to run containers. That was the original idea

530
00:40:57,760 --> 00:41:04,480
 which I wanted to use for next to atomic but ultimately I noticed that this build system

531
00:41:07,119 --> 00:41:08,719
 But ultimately, I noticed that the split system had a few issues for my use case.

532
00:41:14,159 --> 00:41:18,719
 One of them is it took too long to get updates, especially security updates. With running NextCloud, you have a service that's exposed to the internet.

533
00:41:18,719 --> 00:41:26,920
 So you, or at least many people will, and therefore, you need to have an operating system

534
00:41:26,920 --> 00:41:36,000
 that provides you with security updates very, very early.

535
00:41:36,000 --> 00:41:39,000
 So you reduce any issues.

536
00:41:39,000 --> 00:41:42,880
 Also, things-- a lot of security related features

537
00:41:42,880 --> 00:41:45,840
 were not the biggest focus of SK4S.

538
00:41:45,840 --> 00:41:55,440
 For example, with an exotic atomic, I'm supporting TPM based encryption for both disks and all

539
00:41:55,440 --> 00:41:59,480
 sorts of credentials that are used inside of the operating system, like for example,

540
00:41:59,480 --> 00:42:08,639
 your database password and so on and also for and also secure boot so images are signed by me

541
00:42:08,639 --> 00:42:19,840
 and not only images but also yeah something I will get to later that allows

542
00:42:19,840 --> 00:42:28,639
 me to update only parts of the operating system in an atomic fashion.

543
00:42:28,639 --> 00:42:34,039
 So these features were not well supported by Biltrude and therefore also not by Skiffel

544
00:42:34,039 --> 00:42:42,280
 as at least not in a manner where I wouldn't have to do a lot of work to bring it forward

545
00:42:42,280 --> 00:42:47,920
 and to make it work. And that's when I was looking for other solutions.

546
00:42:47,920 --> 00:42:50,420
 And I found M Cozy,

547
00:42:51,559 --> 00:42:55,199
 which is a build system provided by

548
00:42:55,199 --> 00:42:58,679
 the people behind system D.

549
00:42:58,679 --> 00:43:03,039
 And it's for example, also used for normal S,

550
00:43:03,039 --> 00:43:04,880
 if you know that,

551
00:43:04,880 --> 00:43:06,880
 I know you have recently covered the

552
00:43:06,880 --> 00:43:18,000
 KDE distro. But some time ago there was a, I think normal S existed for a while, but

553
00:43:18,000 --> 00:43:25,000
 now they have shifted their architecture to use MCOSI and an atomic way of upgrading.

554
00:43:27,519 --> 00:43:31,559
 And MCOSI allows me to basically take

555
00:43:31,559 --> 00:43:34,719
 any existing system image.

556
00:43:36,280 --> 00:43:38,039
 And as a matter of fact, I'm using

557
00:43:38,039 --> 00:43:43,039
 a standard Debian Trixie base right now

558
00:43:43,599 --> 00:43:48,619
 and run operations on it and create an image.

559
00:43:52,480 --> 00:43:56,460
 And in my case, I'm creating an immutable image,

560
00:43:56,460 --> 00:44:01,460
 which means it's basically you have a Debian system

561
00:44:01,619 --> 00:44:03,599
 but you don't have the package manager,

562
00:44:03,599 --> 00:44:08,400
 but I as the developer or maintainer

563
00:44:09,199 --> 00:44:18,559
 am using the standard Debian package system to install stuff and so the nice thing about

564
00:44:18,559 --> 00:44:28,539
 M cosy in comparison to booty or nixos is that I'm very flexible. I could use a standard Debian

565
00:44:28,539 --> 00:44:35,179
 base. I could also and that's what I am planning to do to support ambient devices

566
00:44:35,179 --> 00:44:47,480
 to support, yeah, single-world computers is I could also use an ambient base and use the ambient tools to install stuff

567
00:44:47,480 --> 00:44:51,840
 and then freeze it into an atomic image

568
00:44:51,840 --> 00:44:53,440
 and push it to devices.

569
00:44:55,159 --> 00:44:59,659
 And in my opinion, that gives me the best of both worlds.

570
00:44:59,659 --> 00:45:04,480
 I have the ability to create this minimal operating system

571
00:45:04,480 --> 00:45:06,000
 that only has what I really need,

572
00:45:06,000 --> 00:45:12,159
 only has the security related stuff. Therefore, I can afford to

573
00:45:14,079 --> 00:45:30,559
 I will have fewer critical updates because there's just fewer stuff on it. I have a lower attack surface and at the same time be flexible in the base

574
00:45:30,559 --> 00:45:36,400
 technology that I'm using. I'm not building my own operating system in terms of building

575
00:45:37,920 --> 00:45:44,800
 everything that makes an operating system. I'm just customizing my own operating system from existing

576
00:45:46,960 --> 00:45:48,000
 operating system, I'm just customizing my own operating system from existing base lines.

577
00:45:54,880 --> 00:46:11,519
 Could you talk a bit about the upgrade process and how that will be different for you as much as the user within Atomic? Next slide pipe usually an update would mean I would be adjusting the scripts that make next log pi next log pi

578
00:46:11,519 --> 00:46:20,679
 that automate everything. Then I would define how those could be tested. I would test them

579
00:46:20,679 --> 00:46:25,480
 manually, then I would run my pipeline to generate some images, then I would run my pipeline

580
00:46:25,480 --> 00:46:28,760
 to generate some images, then I would ask people

581
00:46:28,760 --> 00:46:33,119
 in the community to test those images on the devices

582
00:46:33,119 --> 00:46:36,159
 or environments where they are running an x.py

583
00:46:36,159 --> 00:46:38,800
 and get feedback.

584
00:46:38,800 --> 00:46:44,039
 And basically, when you install the update as an x.py user,

585
00:46:44,039 --> 00:46:47,000
 you would download the latest version of the scripts.

586
00:46:47,000 --> 00:46:54,000
 Then you would run all of the update scripts that would apply stuff in your operating system.

587
00:46:54,000 --> 00:47:04,000
 For example, exchange some scripts, exchange some config, replace something inside of a config and so on.

588
00:47:04,000 --> 00:47:09,000
 replace something inside of a config and so on. And then you would be on the latest version.

589
00:47:09,000 --> 00:47:12,000
 With Next-Out atomic, it's different.

590
00:47:12,000 --> 00:47:16,000
 You have your system installed.

591
00:47:16,000 --> 00:47:21,000
 You have two partitions that are used for the

592
00:47:21,000 --> 00:47:25,000
 root image, for the root operating system,

593
00:47:25,280 --> 00:47:28,920
 and then you have something called system extensions,

594
00:47:28,920 --> 00:47:31,760
 which is a feature by system D,

595
00:47:33,320 --> 00:47:38,320
 that can be used as an overlay over your file system,

596
00:47:38,639 --> 00:47:41,320
 very similar to how containers work,

597
00:47:41,320 --> 00:47:44,880
 and they are used for individual services

598
00:47:48,159 --> 00:47:58,519
 or used for the whole operating system. And when you do updates, then the update checks if there is a new image, downloads it, applies

599
00:47:58,519 --> 00:48:00,360
 it to the other partition.

600
00:48:00,360 --> 00:48:05,119
 Like if you're running partition A right now, I use this from partition A right now,

601
00:48:05,119 --> 00:48:08,480
 then it would write the new image to partition B,

602
00:48:09,280 --> 00:48:13,840
 and then it would do a reboot or a software reboot to partition B.

603
00:48:14,880 --> 00:48:19,519
 And if the system comes up successfully, then it would stay there

604
00:48:19,519 --> 00:48:22,079
 and mark the new partition as successful.

605
00:48:22,079 --> 00:48:25,760
 If it doesn't, then it would roll back to the old partition.

606
00:48:26,480 --> 00:48:34,239
 That's the general process. And that being said, that has one drawback

607
00:48:35,760 --> 00:48:52,320
 that your server needs to restart now and then. However, there are two things how I'm addressing that. One is I don't always update the whole system, but I use the already mentioned system extensions.

608
00:48:52,320 --> 00:49:01,840
 So basically I have system extensions that overlay your file system and it just appears

609
00:49:01,840 --> 00:49:05,440
 to your operating system like there are files there that are

610
00:49:05,440 --> 00:49:13,280
 not actually in the root image but they are in the system extension. And then I can download

611
00:49:13,280 --> 00:49:19,119
 a new system extension, swap that out, just restart all of the services that are affected by that

612
00:49:31,000 --> 00:49:39,559
 avoid a full reboot. That's one thing. The second thing is I will be looking into soft reboots. So system D allows you to actually mount the new root file system

613
00:49:39,559 --> 00:49:49,119
 to a temporary directory, switch over through that, and then restart and services which are marked as such

614
00:49:49,119 --> 00:49:50,719
 do not need to be restarted.

615
00:49:50,719 --> 00:49:55,360
 They can survive basically a kernel replacement.

616
00:49:55,360 --> 00:49:59,199
 And that's something that I will also be working on,

617
00:49:59,199 --> 00:50:01,159
 but that's not yet done.

618
00:50:01,159 --> 00:50:03,519
 It's only planned so far.

619
00:50:03,519 --> 00:50:10,000
 And maybe one third thing is relying on TPM based encryption,

620
00:50:10,000 --> 00:50:19,199
 which means your server can actually reboot if it supports TPM without user interaction. So you

621
00:50:19,199 --> 00:50:28,639
 can have scheduled reboots. You will be able to schedule when they happen and if they

622
00:50:28,639 --> 00:50:36,519
 happen at night you won't probably notice it and I expect root image updates to

623
00:50:36,519 --> 00:50:42,519
 not be more frequently in once per week. The process behind it is basically I

624
00:50:42,519 --> 00:50:45,000
 will have a build server

625
00:50:45,519 --> 00:50:50,519
 which regularly builds new images for both system extensions

626
00:50:50,800 --> 00:50:55,800
 and for the root image and then tests them automatically

627
00:50:55,800 --> 00:50:57,239
 and provides them.

628
00:50:57,239 --> 00:51:00,760
 And that's what users will receive.

629
00:51:02,840 --> 00:51:07,519
 And then download it, apply it and then switch over. So that will be the process

630
00:51:07,519 --> 00:51:17,119
 with an extra atomic as opposed to I write a lot of scripts, test them superficially

631
00:51:17,119 --> 00:51:25,000
 in an automated fashion and then very extensively manually and push them out after that.

632
00:51:25,420 --> 00:51:28,559
 - And could you talk a little bit about how this will impact

633
00:51:28,559 --> 00:51:32,000
 the upgrading updating of NextCloud itself

634
00:51:32,000 --> 00:51:34,880
 on the user facing side?

635
00:51:34,880 --> 00:51:39,199
 Example with the new version, 30 plus coming out.

636
00:51:39,199 --> 00:51:41,280
 - So that's also one of the nice things

637
00:51:41,280 --> 00:51:43,320
 of wrapping Next.org in one.

638
00:51:43,320 --> 00:51:49,239
 Basically right now when I support a new next.org version,

639
00:51:49,239 --> 00:51:54,079
 like I'm, for example, working on just now with Nixert32.

640
00:51:54,079 --> 00:51:59,679
 And Nixert32 with an Nixert file is--

641
00:51:59,679 --> 00:52:03,920
 I have to check the release notes.

642
00:52:03,920 --> 00:52:09,519
 And I have to check the administrator hints and then I have to

643
00:52:09,519 --> 00:52:16,800
 try it out and see if anything breaks, some things I miss things that break and with wrapping

644
00:52:16,800 --> 00:52:29,920
 extra all in one, that work is mostly done by the people over at next.all. And all I have to do is to check their releases,

645
00:52:29,920 --> 00:52:37,719
 which will, because they are using containers and the general setup of these containers is always very similar,

646
00:52:37,719 --> 00:52:48,000
 they will have breaking changes every now and then, but it will affect me a lot less than setting up next cloud completely in my system.

647
00:52:49,000 --> 00:52:52,000
 And basically what I'm doing with NxS1 in one is,

648
00:52:52,000 --> 00:52:58,000
 that's also maybe an interesting detail.

649
00:52:58,000 --> 00:53:09,480
 NxS1 in one in NxS atomic is run using Podman and is running not as root but as its own user, only having

650
00:53:09,480 --> 00:53:18,320
 access to the file system in the places where the actual files are located that are relevant

651
00:53:18,320 --> 00:53:19,320
 for next slot.

652
00:53:19,320 --> 00:53:23,800
 So your data directory for example.

653
00:53:23,800 --> 00:53:27,360
 And so it's next to all in-all-in-one is already running

654
00:53:27,360 --> 00:53:29,840
 very sandboxed, and then on top of that,

655
00:53:29,840 --> 00:53:32,079
 you obviously have to containerization.

656
00:53:34,039 --> 00:53:38,000
 And that means, next-order-all-in-one is very,

657
00:53:39,000 --> 00:53:42,239
 very much separate from the system.

658
00:53:42,239 --> 00:53:51,000
 And so I don't expect to have to adjust the system much to cater for an excellent only one.

659
00:53:52,000 --> 00:53:55,000
 Other than its own configuration.

660
00:53:56,000 --> 00:54:06,239
 And that can be tested a lot more easily than if everything can affect everything like it is the case with an XOT pi. - And are any of these changes being upstreamed

661
00:54:06,239 --> 00:54:08,059
 into all in one?

662
00:54:08,059 --> 00:54:10,360
 - Some actually are already,

663
00:54:10,360 --> 00:54:13,679
 but mostly I'm focusing not on changes

664
00:54:13,679 --> 00:54:15,380
 to the containers themselves,

665
00:54:16,800 --> 00:54:21,800
 but I will, yeah, I will contribute things

666
00:54:22,280 --> 00:54:24,760
 that make compatibility with Potman,

667
00:54:24,760 --> 00:54:29,599
 more difficult, for example, because the upstream,

668
00:54:29,599 --> 00:54:31,400
 they are mostly using Docker.

669
00:54:31,400 --> 00:54:34,679
 The reason why I'm using Portman is because it integrates

670
00:54:34,679 --> 00:54:42,320
 a lot better with system D. And it has some security benefits.

671
00:54:42,320 --> 00:54:47,599
 With Docker, you have to imagine that there is one central Docker process

672
00:54:47,599 --> 00:54:57,119
 that runs all containers. And when you run a new container, you just the command you

673
00:54:57,119 --> 00:55:08,000
 execute just talks to the central process and test the central Docker process to create a new process for the new container.

674
00:55:08,000 --> 00:55:12,000
 And so all containers are children to that one process.

675
00:55:12,000 --> 00:55:19,000
 And that means that some Linux kernel sandboxing features don't really work with that,

676
00:55:19,000 --> 00:55:25,000
 because when you define, basically,

677
00:55:25,880 --> 00:55:28,400
 in Nukes, there's a concept of control groups

678
00:55:28,400 --> 00:55:31,920
 and a process name spaces that would apply

679
00:55:31,920 --> 00:55:34,659
 to the process that you execute,

680
00:55:34,659 --> 00:55:38,460
 but the process you execute is just calling an API

681
00:55:38,460 --> 00:55:43,460
 and then waiting for updates from the Docker process,

682
00:55:49,159 --> 00:55:50,159
 but the actual container creation happens somewhere else.

683
00:55:50,159 --> 00:55:56,800
 So when I configure sandboxing and security restrictions for system D services that run

684
00:55:56,800 --> 00:56:07,280
 Docker containers, they don't work because everything is in the same control group in the same process namespace being attached

685
00:56:07,280 --> 00:56:11,039
 to the central Docker process or Docker daemon.

686
00:56:11,039 --> 00:56:14,679
 And that's the reason why I decided to go with partner.

687
00:56:14,679 --> 00:56:17,840
 And that's one of the things that I will keep contributing

688
00:56:17,840 --> 00:56:20,800
 if there are issues with partner support,

689
00:56:20,800 --> 00:56:25,000
 then I'll contribute those things back to all in one.

690
00:56:25,679 --> 00:56:30,760
 Other things are, yeah, I'm using all in one

691
00:56:30,760 --> 00:56:33,639
 a bit special, I have more,

692
00:56:33,639 --> 00:56:38,639
 I'm exercising more control over the specific configuration.

693
00:56:39,000 --> 00:56:40,840
 I'm not using the master container,

694
00:56:40,840 --> 00:56:44,360
 but I'm using the compose file that's provided

695
00:56:44,360 --> 00:56:46,719
 and actually doing slide

696
00:56:46,719 --> 00:56:53,239
 adjustments to that and I'm using mostly sockets to communicate between

697
00:56:53,239 --> 00:57:01,840
 services instead of local ports because they have a permission system built in

698
00:57:01,840 --> 00:57:05,579
 because they're using file system permissions basically.

699
00:57:05,579 --> 00:57:11,179
 And yeah, that's also something I will support

700
00:57:11,179 --> 00:57:13,980
 back if it's not supported yet.

701
00:57:13,980 --> 00:57:15,260
 Small things like that.

702
00:57:15,260 --> 00:57:19,099
 But mostly I'm not touching all in one match.

703
00:57:19,099 --> 00:57:24,099
 I'm just using it as is and building the system around it.

704
00:57:30,960 --> 00:57:31,440
 - When you say building around it, does that also include the apps themselves?

705
00:57:35,960 --> 00:57:39,559
 For example, things like next cloud bookmarks and next cloud secrets that you would otherwise install in addition, you know, on the running system.

706
00:57:39,800 --> 00:57:42,559
 Will that be managed as well?

707
00:57:42,760 --> 00:57:43,639
 Likely.

708
00:57:43,639 --> 00:57:44,199
 Yes.

709
00:57:42,800 --> 00:57:47,800
 that be managed as well? - Likely yes, although I have to see what cases those are

710
00:57:47,800 --> 00:57:52,800
 and they will likely have to be addressed one by one.

711
00:57:53,199 --> 00:57:56,480
 I mean, generally installing Nectored Apps

712
00:57:56,480 --> 00:57:59,539
 is possible in Excel to all in one, right?

713
00:57:59,539 --> 00:58:01,639
 So you can just install them

714
00:58:01,639 --> 00:58:09,760
 from the next-world administration interface as fast as fast My concern is in regards to the update breaking the next cloud apps themselves

715
00:58:09,760 --> 00:58:16,400
 right it's people who run a lot of apps and then when the major next cloud version update happens that

716
00:58:16,639 --> 00:58:19,480
 Breaks those other applications that they're using

717
00:58:20,880 --> 00:58:22,880
 That's something

718
00:58:23,679 --> 00:58:29,320
 Where I will definitely spend some time on just to, I mean usually

719
00:58:29,320 --> 00:58:37,800
 the next cloud update from the web interface checks, I think whether there are apps which

720
00:58:37,800 --> 00:58:46,000
 are incompatible and disabled system, which is not ideal because you can't easily roll back without applying a backup.

721
00:58:46,000 --> 00:58:55,000
 And I see if I can find a way around to prevent updates that are blocked by incompatible apps

722
00:58:55,000 --> 00:58:57,000
 and notifies the administrator instead.

723
00:58:57,000 --> 00:59:04,000
 Basically, the update process itself, however, is provided by Nextet or in one.

724
00:59:04,000 --> 00:59:08,159
 It is just triggered by next cloud atomic.

725
00:59:08,159 --> 00:59:12,400
 We had a user question also on whether this will make it

726
00:59:12,400 --> 00:59:15,960
 possible for them to use a magic.

727
00:59:15,960 --> 00:59:18,800
 For example, something installed at the operating system

728
00:59:18,800 --> 00:59:21,039
 level now by default.

729
00:59:21,039 --> 00:59:23,880
 This is the kind of thing that's not supported in Next Cloud

730
00:59:23,880 --> 00:59:25,280
 Pi currently.

731
00:59:25,280 --> 00:59:31,440
 There are two parts to this answer. So the first part is that, or maybe I should take

732
00:59:31,440 --> 00:59:38,639
 a second to explain the issue with the magic. Basically, a magic has been always plagued

733
00:59:38,639 --> 00:59:48,320
 a bit by security issues if you have untrusted images as input for it.

734
00:59:48,320 --> 00:59:54,320
 Because image formats can be very complex

735
00:59:54,320 --> 00:59:58,039
 and can allow you to actually do remote code

736
00:59:58,039 --> 00:59:59,440
 execution in your server.

737
00:59:59,440 --> 01:00:10,000
 Like you can embed scripts in some images that can cause someone to take over your server

738
01:00:10,000 --> 01:00:18,639
 if they are executed by an Emagic project with the appropriate permissions.

739
01:00:18,639 --> 01:00:27,639
 Next code, all in one, actually has a solution to that. And that is not using a magic for these things,

740
01:00:27,639 --> 01:00:32,360
 but instead using a container

741
01:00:32,360 --> 01:00:35,940
 that provides a API which does the same thing.

742
01:00:36,840 --> 01:00:40,079
 I think it's called imagine,

743
01:00:41,039 --> 01:00:44,599
 I'm not 100% sure right now,

744
01:00:44,599 --> 01:00:47,679
 but yeah, it's included in next-order all-in-one and it solves

745
01:00:47,679 --> 01:00:54,159
 this issue by relying on a different system than a metric.

746
01:00:54,159 --> 01:00:59,559
 Emetric has still a use case for theming in next cloud.

747
01:00:59,559 --> 01:01:06,840
 However, that is not critical because when you're doing theming, it's usually the next

748
01:01:06,840 --> 01:01:13,119
 cloud instance administrator that chooses the pictures that are being used.

749
01:01:13,119 --> 01:01:23,880
 So there is no risk of an attacker like uploading an image into a public share or something

750
01:01:23,880 --> 01:01:25,280
 that would then be processed by

751
01:01:25,280 --> 01:01:29,559
 a magic to create a thumbnail and had a risk of remote code

752
01:01:29,559 --> 01:01:34,460
 execution. And this the letter use case would be handed by

753
01:01:34,460 --> 01:01:38,239
 Imagine, both this container I hope it's called Imagine, should

754
01:01:38,239 --> 01:01:49,139
 look it up. Yeah, but generally the imagine would then only be used for internal purposes and then it is fine to

755
01:01:49,139 --> 01:01:50,380
 use.

756
01:01:50,380 --> 01:01:57,980
 What about those enthusiastic users who don't want to wait for you to test things and they

757
01:01:57,980 --> 01:02:00,000
 want to make their own changes?

758
01:02:00,000 --> 01:02:03,219
 Say changes to the containers or add additional containers.

759
01:02:03,219 --> 01:02:05,679
 Say plug in something like Jellyfin as a

760
01:02:05,679 --> 01:02:11,519
 media streaming service to watch their next cloud videos and make other changes without waiting

761
01:02:11,519 --> 01:02:15,519
 for you to test them in any way. How will that be supported?

762
01:02:17,679 --> 01:02:24,639
 Yeah, so that's really interesting and I've thought about that a lot. One of the main

763
01:02:30,079 --> 01:02:46,539
 and I've thought about that a lot. One of the main focuses of an extra atomic is to provide as little foot guns as possible. So it's in a sense both more tinker-friendly than extra pie and lasting differently. Because it you can be more

764
01:02:46,539 --> 01:02:49,960
 certain that when you do some changes, you

765
01:02:49,960 --> 01:02:53,860
 won't break anything. Because the things

766
01:02:53,860 --> 01:02:56,820
 that would break stuff, if you change them,

767
01:02:57,139 --> 01:03:01,340
 are not changeable. However, it also

768
01:03:03,739 --> 01:03:05,000
 restricts you in the ways you can change things

769
01:03:07,000 --> 01:03:12,000
 because you have to follow the system philosophy

770
01:03:13,159 --> 01:03:15,679
 and architecture in how things are managed.

771
01:03:15,679 --> 01:03:20,239
 And basically every service is running containers.

772
01:03:20,239 --> 01:03:23,719
 So it's hard to do anything without knowing

773
01:03:23,719 --> 01:03:26,000
 and understanding containers

774
01:03:27,000 --> 01:03:29,000
 and also

775
01:03:29,699 --> 01:03:31,699
 It's not meant to

776
01:03:32,699 --> 01:03:37,480
 Yeah, manually change things around in the operating system. The same applies to Nectl

777
01:03:37,480 --> 01:03:42,440
 By the way, but of course people do it all the way and that's a very valid use case

778
01:03:42,679 --> 01:03:49,360
 It's just one that also meant, okay, but you should only do it

779
01:03:49,360 --> 01:03:59,280
 if you're able to help yourself if you break something. With Next.atomic, I have one feature

780
01:03:59,280 --> 01:04:07,679
 that would cover this on my wishlist, but it's on the wishlist because I first want to focus on providing a stable

781
01:04:07,679 --> 01:04:15,360
 and working system that includes next cloud and everything that's needed to run that.

782
01:04:15,360 --> 01:04:28,480
 And after that, I will look into this. So what is this about? Basically, I would love to be able to provide containerized environments that are mutable,

783
01:04:28,480 --> 01:04:34,480
 where users can do whatever they want, where they can choose to expose specific directories

784
01:04:34,480 --> 01:04:47,800
 from the host and have it run their other services on there. Those would be likely inks containers.

785
01:04:49,239 --> 01:04:54,239
 So inks is a container format that's more

786
01:04:54,880 --> 01:04:58,400
 meant to run a whole operating system in a container

787
01:04:58,400 --> 01:05:00,159
 as opposed to Docker containers,

788
01:05:00,159 --> 01:05:04,119
 which are meant to run single applications

789
01:05:04,119 --> 01:05:05,000
 inside a container.

790
01:05:05,760 --> 01:05:09,099
 And those containers could then be

791
01:05:11,699 --> 01:05:14,719
 any distribution you like, basically.

792
01:05:14,719 --> 01:05:16,920
 They could be a Debian system.

793
01:05:16,920 --> 01:05:19,360
 They could be a Fedora system.

794
01:05:19,360 --> 01:05:22,440
 They could be open SUSO or whatever.

795
01:05:22,440 --> 01:05:24,920
 And you could install stuff and manage stuff there,

796
01:05:24,920 --> 01:05:31,639
 basically similar to how Proxmox containers work, if you will. So that

797
01:05:31,639 --> 01:05:36,280
 would be something I would really like but it's a it's only wish list right now.

798
01:05:36,280 --> 01:05:45,159
 And I think if I managed to do that that will also cater for the Tinkler use cases,

799
01:05:49,239 --> 01:05:52,119
 while still not being in conflict with the stability of the base system

800
01:05:52,119 --> 01:05:55,440
 and the next cloud installation and services.

801
01:05:55,440 --> 01:05:58,679
 - So if a user did an update

802
01:05:58,679 --> 01:06:02,480
 and they ran into some kind of issue,

803
01:06:02,480 --> 01:06:04,400
 what would they do?

804
01:06:04,400 --> 01:06:08,559
 And how is that different from next cloud pie

805
01:06:08,559 --> 01:06:16,440
 currently, especially in regards to that classically untested functionality you sometimes find

806
01:06:16,440 --> 01:06:19,960
 in next cloud, right, where you're like, Oh, here's something that's untested, I can click

807
01:06:19,960 --> 01:06:28,039
 and enable it. and I will. I will try to make that not easy to do.

808
01:06:28,079 --> 01:06:32,400
 So if you do it, then you know what you're doing.

809
01:06:32,679 --> 01:06:38,159
 Basically, basically my goal as maintainer is always to

810
01:06:39,199 --> 01:06:43,360
 protect users from making uninformed decisions.

811
01:06:44,880 --> 01:06:50,000
 I'm totally fine and I encourage you to use your system like you want.

812
01:06:50,000 --> 01:06:58,000
 But I want to make sure that you know the implications when you're doing it.

813
01:06:58,000 --> 01:07:08,760
 And with Nexide Atomic, it will be harder to do that kind of thing but it will be possible.

814
01:07:08,760 --> 01:07:17,760
 It will probably involve something like adding your own system extension which can overlay

815
01:07:17,760 --> 01:07:21,639
 files if you want to do changes to the basis.

816
01:07:21,639 --> 01:07:22,639
 So that's possible.

817
01:07:22,639 --> 01:07:25,280
 It's just not as straightforward as editing

818
01:07:25,280 --> 01:07:32,360
 a file. And the idea is that this tells you when you try to edit a file in your, like,

819
01:07:32,360 --> 01:07:48,000
 let's say, user bin directory, then that being read only will tell you, okay, that's not how I am supposed to interact with the system.

820
01:07:48,000 --> 01:08:08,760
 And then you will use a search engine and find a documentation entry where there's described how you can do it in a way that is easy to undo and still gives you a warning that this might

821
01:08:08,760 --> 01:08:13,380
 break things in unexpected ways because it's not how the system is meant to be

822
01:08:13,380 --> 01:08:19,939
 and it's not tested. So that's for general system modification. The other

823
01:08:19,939 --> 01:08:26,159
 thing is regarding NextCloud, you do have access to the next cloud installation

824
01:08:26,159 --> 01:08:28,439
 and data directory.

825
01:08:28,439 --> 01:08:30,539
 You can do whatever you want there.

826
01:08:30,539 --> 01:08:32,399
 You can use the web interface.

827
01:08:32,399 --> 01:08:38,439
 If something breaks, you will, the worst case should always be that you have to rely on

828
01:08:38,439 --> 01:08:39,920
 your backups.

829
01:08:39,920 --> 01:08:45,000
 And in the next time, I will make, I will, I will make the warnings

830
01:08:47,239 --> 01:08:49,840
 if you don't have backups a bit more present

831
01:08:49,840 --> 01:08:51,680
 than it was a next-up file.

832
01:08:51,680 --> 01:08:55,279
 And I will actually encourage you to set up

833
01:08:55,279 --> 01:08:57,359
 backups during the installation process

834
01:09:00,640 --> 01:09:08,000
 or show a warning that you don't have backup set up in the user interface,

835
01:09:08,000 --> 01:09:12,000
 the administration user interface provided by an external atomic.

836
01:09:12,000 --> 01:09:17,000
 So the main thing is if you have good backups,

837
01:09:17,000 --> 01:09:22,000
 then you can do whatever you want and don't have to be afraid.

838
01:09:22,000 --> 01:09:27,840
 If you don't have backups, there will be things that can't be easily fixed.

839
01:09:31,439 --> 01:09:38,319
 But that's like a general system administrator's rule of thumb, I would say.

840
01:09:39,680 --> 01:09:45,000
 Who would you say the target audience for NextCloud Atomic is?

841
01:09:45,000 --> 01:09:52,359
 And is that audience different from the people who would use NextCloud Pi currently?

842
01:09:52,359 --> 01:10:00,680
 NextCloud Atomic caters to a slightly different target audience, but I would say it's mostly

843
01:10:00,680 --> 01:10:14,960
 a broader target audience. However, the main focus of Nexide Pie in comparison to Nexide Pie

844
01:10:15,520 --> 01:10:37,000
 is focusing on robustness and security. And the focus of Nex Excel Pi is mostly on ease of use and supporting as many use cases

845
01:10:37,000 --> 01:10:40,000
 and also low budget use cases.

846
01:10:40,000 --> 01:10:50,720
 Next, atomic aims to support the same audience, but it focuses on the system security

847
01:10:50,720 --> 01:10:56,159
 path first. So the first things that will be supported by next atomic RBA machine

848
01:10:57,680 --> 01:11:02,159
 for two reasons. First, they are more easy to test, so it's easier to develop with them.

849
01:11:06,800 --> 01:11:16,920
 test so it's easier to develop with them and if I support visual machines I can faster progress the system itself and secondly because visual machines are

850
01:11:16,920 --> 01:11:21,840
 very ubiquitous they can be run anywhere they can be run on a single board

851
01:11:21,840 --> 01:11:27,119
 computer as well as on your own hardware as well as on a

852
01:11:27,760 --> 01:11:35,439
 hosting provider or cloud provider. And after that, I will work on support for single board

853
01:11:35,439 --> 01:11:49,800
 computers where there's one major challenge. Basically, next topic right now assumes that you have a TPM address or platform material.

854
01:11:49,800 --> 01:11:58,199
 That's the thing that Windows currently annoys everyone that they only support devices with

855
01:11:58,199 --> 01:12:11,920
 TPM. That's basically a chip that allows you to ensure the integrity of the operating system

856
01:12:11,920 --> 01:12:22,319
 and allows you to store secrets and keys inside which are only provided to the operating system

857
01:12:22,319 --> 01:12:28,640
 if the integrity is ensured. So it allows you to unlock your

858
01:12:28,640 --> 01:12:36,399
 disks without entering a password because it's provided by TPM only if your operating system is

859
01:12:38,239 --> 01:12:45,680
 secure, securely signed and its integrity is ensured by TPM.

860
01:12:48,079 --> 01:12:55,840
 That has a big advantage for servers because it allows you to reboot your server without user

861
01:12:55,840 --> 01:13:03,039
 interaction and still have this encryption enabled. And that's why I'm, that's one of the reasons

862
01:13:03,039 --> 01:13:09,699
 why I'm focusing on that also I don't want to have unencrypted credentials lying around if I can avoid it.

863
01:13:11,699 --> 01:13:28,159
 But I, after I get everything to a working and stable state, then I will work on a fallback system that will likely involve something like a web-based

864
01:13:28,159 --> 01:13:33,159
 unlock mechanism that can be used on device

865
01:13:34,800 --> 01:13:38,680
 without TPM encryption until then single board computers

866
01:13:38,680 --> 01:13:41,939
 without TPM will not be supported.

867
01:13:44,439 --> 01:13:49,359
 Unless you add TPM, for example, I think there are TPM shields

868
01:13:49,359 --> 01:13:55,579
 for some single board computers. I think there is a solution for the Raspberry Pi 5, for

869
01:13:55,579 --> 01:14:06,119
 example, but not all SPCs will be supported from the start. But regarding target audience, next

870
01:14:06,119 --> 01:14:12,119
 up atomic also extends the target audience to a mob, I would

871
01:14:12,119 --> 01:14:17,079
 say professional or even enterprise target audience.

872
01:14:17,920 --> 01:14:29,720
 Because I think with the system design architecture, it will be interesting for basically any company or small business

873
01:14:29,720 --> 01:14:40,560
 or NGO or community that is currently running next cloud on a single machine and managing

874
01:14:40,560 --> 01:14:48,159
 it themselves because it provides a number of guarantees on top of the existing options

875
01:14:48,800 --> 01:14:56,319
 in terms of safety and compliance that take a lot of effort to achieve yourself.

876
01:14:57,520 --> 01:15:05,600
 And so to sum it up, next slide, atomic still caters a lot to self-hosting.

877
01:15:07,600 --> 01:15:16,720
 It also caters to professional requirements like because I think next cloud is really a

878
01:15:16,720 --> 01:15:27,000
 system that tends to be trusted with sensitive and important data. And so that was important for me to focus on.

879
01:15:27,000 --> 01:15:34,760
 And it also caters to companies and NGOs and communities

880
01:15:34,760 --> 01:15:40,560
 that want their own next cloud and want to make sure it is

881
01:15:40,560 --> 01:15:43,119
 built with security in mind.

882
01:15:43,119 --> 01:15:48,079
 It has good monitoring options and good backup options.

883
01:15:49,020 --> 01:15:50,920
 - I also just wanted to share this comment

884
01:15:50,920 --> 01:15:53,899
 a user sent in thanking you for the years

885
01:15:53,899 --> 01:15:57,359
 that you have worked on next cloud pie so far.

886
01:15:57,359 --> 01:16:00,020
 And yeah, so they just wanted to say,

887
01:16:00,020 --> 01:16:02,760
 "Thank you, Ed, thank you from the community."

888
01:16:02,760 --> 01:16:04,239
 - Thank you, that's very kind.

889
01:16:04,239 --> 01:16:07,079
 I always love hearing from the community. Thank you. That's very kind. I always love hearing from the community.

890
01:16:07,079 --> 01:16:13,239
 And that's also something I really hope I can provide a solution

891
01:16:13,279 --> 01:16:17,279
 that covers the use cases of the community because.

892
01:16:18,800 --> 01:16:24,880
 Yeah, well, I think that's something I should say here.

893
01:16:25,000 --> 01:16:25,199
 I think that's something I should say here.

894
01:16:30,199 --> 01:16:31,319
 I won't be sustaining next card pie forever.

895
01:16:34,180 --> 01:16:36,840
 And I will at some point, when I think next card atomic has achieved

896
01:16:36,840 --> 01:16:39,479
 a certain level of maturity,

897
01:16:39,479 --> 01:16:41,739
 discontinue work on next card pie.

898
01:16:41,739 --> 01:16:47,840
 Right now, next card pie is mostly in a maintenance state, so I'm adding

899
01:16:47,840 --> 01:16:57,359
 new Nexrad versions, I'm fixing critical bugs. To be honest, I can't even fix all of the bugs,

900
01:16:57,359 --> 01:17:05,920
 because Nexrad Pie has many bugs and I know about them. It takes a lot of work to fix them. It's super hard to test.

901
01:17:06,560 --> 01:17:13,439
 It's often that there are new bugs when old ones are fixed and so on. I'm trying, basically,

902
01:17:13,439 --> 01:17:22,960
 my focus right now is to really ensure that all the existing systems are working, that they

903
01:17:22,960 --> 01:17:25,319
 support up to the next start versions, that they support up to the next cloud versions, that

904
01:17:25,319 --> 01:17:29,720
 they support up to the operating systems and so on.

905
01:17:29,720 --> 01:17:40,359
 And at some point, I will provide a path to migrate from next cloud to next cloud all

906
01:17:40,359 --> 01:17:48,859
 in one or next extra atomic. These migrations will be very similar because an extra atomic obviously uses an extra

907
01:17:48,859 --> 01:17:52,699
 or an one and that will...

908
01:17:52,699 --> 01:18:00,359
 Yeah, and then I hope that will be a good and even better option for

909
01:18:00,359 --> 01:18:09,239
 users that are currently using Excel Pi. So that will be some way for the future.

910
01:18:09,239 --> 01:18:16,359
 I don't think it will happen at least for the foreseeable months.

911
01:18:16,359 --> 01:18:25,000
 Like it will certainly not happen before probably mid-2026 or something.

912
01:18:27,920 --> 01:18:30,000
 But it will happen eventually.

913
01:18:30,000 --> 01:18:31,159
 - Super interesting.

914
01:18:32,399 --> 01:18:35,319
 - Is there any correlation between this podcast

915
01:18:35,319 --> 01:18:37,800
 and your upcoming conference talk

916
01:18:37,800 --> 01:18:42,000
 at the next cloud conference that you'd like mentioned

917
01:18:42,000 --> 01:18:43,039
 as part of the episode?

918
01:18:44,119 --> 01:18:56,000
 - I think it's actually a great complement for the next cloud conference talk

919
01:18:56,000 --> 01:18:59,000
 because they only have like seven minutes.

920
01:18:59,000 --> 01:19:05,000
 And I can't cover any of the technical details.

921
01:19:05,119 --> 01:19:10,119
 And it's nice to be able to point to this interview

922
01:19:11,539 --> 01:19:13,279
 and to the podcast episode.

923
01:19:14,560 --> 01:19:18,039
 - Yeah, it seems like a really useful project

924
01:19:19,399 --> 01:19:20,960
 in the landscape of Next.Cloud,

925
01:19:20,960 --> 01:19:29,359
 because yeah, Next. Play. NextCloud Play does serve a valid use case,

926
01:19:29,359 --> 01:19:36,239
 I think, which is this professional, like for people that are not professionals that want to

927
01:19:36,239 --> 01:19:44,560
 use NextCloud, NextCloud Play is kind of the ideal thing to use. And it's just unfortunate or

928
01:19:49,479 --> 01:19:55,960
 use and it's just unfortunate or well, it's just how it is that it evolved into the state where it's barely maintainable apparently. And it seems really cool that you're willing

929
01:19:55,960 --> 01:20:07,920
 to take the next step and turn up with something that is more maintainable and more secure and more stable. It's really cool.

930
01:20:08,720 --> 01:20:13,600
 You know, that makes me curious. What do you feel like you've learned as the maintainer from

931
01:20:13,600 --> 01:20:31,279
 doing this over the last seven or eight years? Oh, that's a that's a great question. So first of all, when I jumped into a next-class hosting scenario, it was actually before

932
01:20:31,279 --> 01:20:32,279
 next-class.

933
01:20:32,279 --> 01:20:38,399
 I started out with an on-cloud server that I was hosting on an old laptop.

934
01:20:38,399 --> 01:20:49,140
 And I think I spent a week just configuring Apache because I didn't know much about it and I wanted it to be secure and I didn't feel comfortable with it

935
01:20:51,760 --> 01:20:57,560
 Without yeah understanding every line I wrote for the configuration and

936
01:20:59,199 --> 01:21:01,199
 since then it has been

937
01:21:01,539 --> 01:21:04,439
 an amazing learning experience I have learned a

938
01:21:03,560 --> 01:21:07,960
 It has been an amazing learning experience. I've learned a huge amount about especially

939
01:21:07,960 --> 01:21:13,960
 Bash from Nacho from the original author of Nexelpile.

940
01:21:13,960 --> 01:21:17,800
 Like, don't get me wrong, the Bash quality in Nexelpile

941
01:21:17,800 --> 01:21:19,399
 is quite good.

942
01:21:19,399 --> 01:21:24,680
 It's just, I think, that the complexity of the project

943
01:21:24,680 --> 01:21:25,000
 has exceeded

944
01:21:27,239 --> 01:21:29,239
 the use case of Bash.

945
01:21:29,239 --> 01:21:32,880
 But I learned a lot about that.

946
01:21:32,880 --> 01:21:37,880
 I learned really a lot about system architecture,

947
01:21:40,960 --> 01:21:43,239
 system management about it.

948
01:21:43,239 --> 01:21:45,000
 I learned with National AtomicES-Out atomic,

949
01:21:45,000 --> 01:21:50,000
 I've been working on NACES-Out atomic for about a year now.

950
01:21:50,000 --> 01:21:56,000
 And I learned so much about Linux systems,

951
01:21:56,000 --> 01:22:01,000
 kernels, I learned more about containers than I ever anticipated.

952
01:22:01,000 --> 01:22:03,000
 And plan two,

953
01:22:03,000 --> 01:22:14,000
 like how the individual sandboxing features work and how they are actually not tied to any container runtime.

954
01:22:14,000 --> 01:22:26,000
 You can achieve the same level of sandboxing and isolation that you get with, for example, Docker containers entirely without them.

955
01:22:26,000 --> 01:22:34,000
 And that's also something I'm doing in Excel atomic with some system D services.

956
01:22:34,000 --> 01:22:51,000
 I have learned a lot of what trusted boot about build systems and also about, I think about, well, I hope that I have learned a lot about the needs of the community as well,

957
01:22:51,000 --> 01:22:55,000
 and I hope to be able to keep catering to them.

958
01:23:05,000 --> 01:23:07,399
 a very impactful story for me.

959
01:23:09,439 --> 01:23:10,859
 The whole next cloud hosting and next cloud pie,

960
01:23:12,760 --> 01:23:14,079
 and next cloud atomic.

961
01:23:14,079 --> 01:23:17,319
 - Yeah, it seems like a huge rabbit hole

962
01:23:17,319 --> 01:23:22,319
 to go into from just wanting to have a next cloud setup

963
01:23:22,680 --> 01:23:29,520
 into next cloud pie, best programming, and then even deeper into

964
01:23:30,479 --> 01:23:38,079
 containers, system D extensions and whatnot. Yeah, super truly.

965
01:23:39,039 --> 01:23:47,880
 I guess I'll take this moment to share my own experience getting involved with NextCloud Pie, which began in running it for my hacker space.

966
01:23:48,279 --> 01:23:52,680
 And that worked for two years until someone literally destroyed the computer.

967
01:23:53,640 --> 01:23:54,720
 But as part of that,

968
01:23:54,800 --> 01:23:59,119
 I was also learning to run a discourse forum for the hacker space.

969
01:24:00,039 --> 01:24:03,880
 And I ended up realizing that I was a lot more interested in the NextCloud

970
01:24:03,920 --> 01:24:05,399
 community itself

971
01:24:05,399 --> 01:24:07,960
 and so many like-minded people.

972
01:24:07,960 --> 01:24:11,000
 And through doing that, I got connected with Ignacio,

973
01:24:11,000 --> 01:24:13,520
 who was the original developer of NextCloud Pie

974
01:24:13,520 --> 01:24:16,000
 and thinking it'll be nice to improve our connection

975
01:24:16,000 --> 01:24:19,039
 to the Discourse Forum provided by NextCloud

976
01:24:19,039 --> 01:24:21,199
 at help.nextcloud.com.

977
01:24:21,199 --> 01:24:23,039
 So then I ended up becoming a moderator

978
01:24:23,039 --> 01:24:25,520
 and even administrator in order to further connection

979
01:24:26,319 --> 01:24:34,239
 between Next Cloud Pi and Next Cloud as a company. And that ended with you and I being in Berlin

980
01:24:34,239 --> 01:24:49,000
 together presenting at the conference. And yeah, it's be able to talk to you now.

981
01:24:49,000 --> 01:24:59,000
 Also, I really would like to take the opportunity and congratulate you to this podcast that you now have been running for, I think, over a year.

982
01:24:59,000 --> 01:25:08,880
 And yeah, really amazing to see what you made of it. And it's really nice to be back and talk to you about it.

983
01:25:08,880 --> 01:25:14,880
 After the time that we have spent together within the next cloud,

984
01:25:14,880 --> 01:25:20,640
 Py community, where I think I shouldn't leave that unmentioned.

985
01:25:20,640 --> 01:25:30,600
 One of the really amazing parts of the experience was working with the community and with the

986
01:25:30,600 --> 01:25:38,000
 active people from the community that organized the forum that helped each other out, that

987
01:25:38,000 --> 01:25:48,319
 contributed to the documentation that helped me test new releases and some of which also had in contributing code.

988
01:25:48,319 --> 01:25:58,720
 But just really getting a feeling for there are actually people who are not only using the product

989
01:25:58,720 --> 01:26:11,039
 but like it and want to bring it forward and support each other because in no universe I could provide

990
01:26:11,039 --> 01:26:17,600
 that as maintainer and provide this kind of community support that is actually provided

991
01:26:17,600 --> 01:26:20,359
 by volunteers.

992
01:26:20,359 --> 01:26:27,600
 Yeah, and yeah, you've definitely been one of the active community members too, and it

993
01:26:27,600 --> 01:26:36,600
 was really great to have, to be working with you and now to be back talking to you about

994
01:26:36,600 --> 01:26:38,079
 Maddie's project.

995
01:26:38,079 --> 01:26:43,479
 Yeah, and I just want to say thank you so much to both of you for being on this show.

996
01:26:43,479 --> 01:26:44,479
 It's great.

997
01:26:44,479 --> 01:26:51,680
 A nice full circle moment, of course. And from when we gave our presentation at the

998
01:26:51,680 --> 01:26:57,119
 next cloud conference a couple years ago, and I was on a panel discussion about how people can

999
01:26:57,119 --> 01:27:01,520
 contribute to next cloud, and they're going to have a new iteration of that panel discussion

1000
01:27:01,520 --> 01:27:07,000
 this year. I think they did it every year. And yeah, I'll link in the show so you can watch it,

1001
01:27:07,000 --> 01:27:12,000
 but I did feel at that time ready to step away, right,

1002
01:27:12,000 --> 01:27:15,000
 from being involved in that community because being involved

1003
01:27:15,000 --> 01:27:20,000
 in the next cloud got me, of course, more involved with next cloud more broadly.

1004
01:27:20,000 --> 01:27:27,000
 And I realized that I just needed to take time away because in order to do some kind of project like this or talk with the people involved

1005
01:27:27,000 --> 01:27:34,239
 I felt like I just kind of needed to take my own time right and live life and do other things

1006
01:27:34,640 --> 01:27:38,079
 Because I like you guys I like everyone at the next club company as people

1007
01:27:38,079 --> 01:27:39,960
 I mean I've gotten them know them and I like them

1008
01:27:39,960 --> 01:27:46,239
 So I just needed some time sort of away from being headfirst in it so I could feel like

1009
01:27:46,239 --> 01:27:51,800
 have these kinds of discussions for the broader public, which I'm happy to do.

1010
01:27:51,800 --> 01:27:54,359
 Yeah, I get that.

1011
01:27:54,359 --> 01:28:00,880
 Sometimes you need some distancing to figure out where to go next.

1012
01:28:00,880 --> 01:28:07,239
 Yeah, I look forward to even more of these kinds of conversations on the show

1013
01:28:07,239 --> 01:28:10,760
 moving forward, these kinds of interviews and, you know, these kinds of topics, of course,

1014
01:28:10,760 --> 01:28:16,079
 are of interest to me. And I think to the broader show audience. But I'm curious in

1015
01:28:16,079 --> 01:28:21,760
 terms of starting fresh now, what would you like, say, the next iteration of community

1016
01:28:21,760 --> 01:28:30,720
 behind your project to do to help you to contribute to to contribute, to be involved. What do you see that looking like and to be the most successful it can be?

1017
01:28:32,479 --> 01:28:47,000
 Yeah, so that's also a good question. I think it's hard to answer in a very general way,

1018
01:28:47,000 --> 01:28:50,920
 like in a whole ecosystem kind of way.

1019
01:28:50,920 --> 01:29:00,680
 I suppose the sharing of use cases and information

1020
01:29:00,680 --> 01:29:17,000
 and solutions for specific problems and integrations is something that's super valuable to contribute

1021
01:29:17,000 --> 01:29:28,079
 in a general way within the next cloud ecosystem, for example, or any other open source ecosystem. Specifically for an excellent atomic, I am actually planning

1022
01:29:28,079 --> 01:29:38,079
 to start calling for contributors with the next community conferences upcoming because

1023
01:29:38,079 --> 01:29:46,239
 so far I have not done that a lot because I needed to figure out how things work, how the architecture is and so on. I

1024
01:29:46,239 --> 01:29:58,239
 couldn't easily work with other contributors before I had a strong vision and understanding

1025
01:29:58,239 --> 01:30:06,520
 of the system myself. But now I'm actively looking for contributors that are either wanting to

1026
01:30:06,520 --> 01:30:13,479
 contribute in the area of Rust development, like the user interface, many

1027
01:30:13,479 --> 01:30:18,399
 of the system tools are written in Rust for next-order atomic, which was a choice

1028
01:30:18,399 --> 01:30:28,000
 because Rust allows you to catch a lot of errors before you actually ship anything,

1029
01:30:28,000 --> 01:30:31,000
 rather than some other linkages.

1030
01:30:31,000 --> 01:30:38,000
 And secondly, people who know something about system administration

1031
01:30:38,000 --> 01:30:48,239
 and would like to contribute there through the system building process and maybe are curious about atomic distributions

1032
01:30:48,239 --> 01:30:51,479
 or build systems in general.

1033
01:30:52,439 --> 01:30:56,640
 And those I invite to just contact me.

1034
01:30:56,640 --> 01:30:59,840
 I will shortly also provide contribution guidelines

1035
01:30:59,840 --> 01:31:01,960
 on the next atomic webpage.

1036
01:31:03,239 --> 01:31:06,319
 Hopefully they will be available when this episode is out.

1037
01:31:11,760 --> 01:31:14,560
 And lastly, but I think that maybe at a later point,

1038
01:31:16,239 --> 01:31:26,199
 some time this year there will be a test release and I welcome you to test it out and to give me feedback and to,

1039
01:31:26,199 --> 01:31:30,000
 yeah, let me know what you think, what you need,

1040
01:31:30,000 --> 01:31:32,000
 how well it covers the use cases.

1041
01:31:32,000 --> 01:31:37,000
 Just let me know.

1042
01:31:37,000 --> 01:31:43,000
 And I will consider all sorts of feedback that I receive.

1043
01:31:43,000 --> 01:31:47,760
 >> And will you be looking for feedback

1044
01:31:47,760 --> 01:31:49,920
 primarily through GitHub?

1045
01:31:49,920 --> 01:31:54,920
 - Yes, and no, I'm not completely decided on that yet.

1046
01:31:58,399 --> 01:32:03,399
 I could, I'm actually thinking about building some

1047
01:32:11,119 --> 01:32:04,979
 I'm actually thinking about building some sort of feedback or community involvement mechanisms right inside of Next

1048
01:32:04,979 --> 01:32:15,279
 World Atomic.

1049
01:32:15,279 --> 01:32:18,479
 But for now, GitHub is a good place.

1050
01:32:18,479 --> 01:32:24,000
 If you want to contact me about technical things regarding Next World Atomic, then you

1051
01:32:24,000 --> 01:32:27,859
 can absolutely create issues on exaltatomic.

1052
01:32:28,920 --> 01:32:33,760
 Likely at some point there will be a policy

1053
01:32:33,760 --> 01:32:35,760
 that will help you decide, well,

1054
01:32:35,760 --> 01:32:37,239
 that's the right place for it.

1055
01:32:37,239 --> 01:32:39,359
 But for now, that's the way to go.

1056
01:32:39,359 --> 01:32:42,279
 If you're interested in one of my projects,

1057
01:32:42,279 --> 01:32:46,560
 I like, if you're interested in Next Cloud Pi,

1058
01:32:46,560 --> 01:32:49,520
 you will find options to interact with the community

1059
01:32:49,520 --> 01:32:52,920
 and myself on nextcloudpi.com.

1060
01:32:52,920 --> 01:32:54,640
 If you're interested in Next Cloud Atomic,

1061
01:32:54,640 --> 01:32:57,119
 you will find information about the project

1062
01:32:57,119 --> 01:33:00,119
 and soon or so contribution guidelines

1063
01:33:00,119 --> 01:33:04,640
 on nextcloudatomic.com.

1064
01:33:04,640 --> 01:33:11,239
 And when you want to contact me and ask me about anything that's

1065
01:33:11,239 --> 01:33:28,960
 related to those projects or if you are looking for like contract work in any way or want about stuff you can find me on Mastodon or find my email

1066
01:33:28,960 --> 01:33:30,359
 on my web page.

1067
01:33:30,359 --> 01:33:33,560
 You will also find my Mastodon account there.

1068
01:33:33,560 --> 01:33:36,600
 So I guess it makes sense to just include it in the show notes

1069
01:33:36,600 --> 01:33:37,800
 if that's fine with your chains.

1070
01:33:42,439 --> 01:33:44,520
 Yeah, also my web page would probably

1071
01:33:44,520 --> 01:33:46,439
 be the best starting point.

1072
01:33:46,439 --> 01:33:52,159
 You can just email me and say hi and we can chat.

1073
01:33:52,159 --> 01:33:54,359
 It would be awesome.

1074
01:33:54,359 --> 01:34:00,600
 MasterClear.de in my case.

1075
01:34:00,600 --> 01:34:08,000
 Well, yeah, thank you. Thank you for having me. Thank you for chatting about my projects

1076
01:34:08,000 --> 01:34:18,960
 and work and life in open source in general. It was really fun. And I hope, yeah, I hope

1077
01:34:18,960 --> 01:34:23,000
 you'll keep having a great time with this podcast.

1078
01:34:23,000 --> 01:34:25,159
 Thanks.

1079
01:34:25,159 --> 01:34:33,479
 That will conclude today's episode, The Longest Ever, and it is part one of part two. In the

1080
01:34:33,479 --> 01:34:39,279
 second part of the interview, we'll talk all about how they handle donations and asking

1081
01:34:39,279 --> 01:34:49,680
 Tobias about how he did his fundraising to work on next Cloud Atomic. Also ask Marcel about the same, how they feel about donations, how they have balance in their

1082
01:34:49,680 --> 01:34:54,079
 lives with their other interests and asking about what those interests are.

1083
01:34:55,600 --> 01:35:00,319
 We'll also be talking all about containers in the next episode and whether containers

1084
01:35:00,319 --> 01:35:05,920
 and virtualization might interest you as a home enthusiast. And who there for really?

1085
01:35:05,920 --> 01:35:09,720
 So if you have thoughts, feel free to send them in podcast@james.network.

1086
01:35:09,720 --> 01:35:11,239
 Thank you so much for listening.

1087
01:35:11,239 --> 01:35:16,119
 Please do share the show if you liked it and you can look forward to more in the next

1088
01:35:16,119 --> 01:35:19,479
 episode of Linux Prepper.

1089
01:35:19,479 --> 01:35:30,000
 Bye. [MUSIC]