Nextcloud Atomic Interview, immutable Nextcloud for single computers

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]