Don't Call it a Christro
Aug 17, 2025
When personalities clash, the users come last. Meanwhile, Chris' hyper-tuned setup stops being a toy and starts looking like a daily driver.
Sponsored By:
- Managed Nebula: Meet Managed Nebula from Defined Networking. A decentralized VPN built on the open-source Nebula platform that we love.
- 1Password Extended Access Management: 1Password Extended Access Management is a device trust solution for companies with Okta, and they ensure that if a device isn't trusted and secure, it can't log into your cloud apps.
- Unraid: A powerful, easy operating system for servers and storage. Maximize your hardware with unmatched flexibility.
Links:
- 💥 Gets Sats Quick and Easy with Strike
- 📻 LINUX Unplugged on Fountain.FM
- Toronto Meetup - JB Colony Events
- Linux is about to lose a feature – over a personality clash — A large and unfortunate mistake in the kernel development management process is underway.
- Re: [GIT PULL] bcachefs changes for 6.17 - Josef Bacik
- Ubuntu Developing New "Dangerous" Desktop Images Concept — Ubuntu is testing "Dangerous" Desktop Images, daily builds with all Snaps pulled from the edge channel.
- Ubuntu 25.10 Will Ship With Linux 6.17 Even If It Means An Unstable "-rc" Kernel
- syncthing 2.0 Released! — This is the first release of the new 2.0 series. Expect some rough edges and keep a sense of adventure! 🙏
- Z-Wave is not dead - Home Assistant — TL;DR: Z-Wave is alive and well, partly due to a strong community that is building new open-source resources.
- Home Assistant Connect ZWA-2 — The ultimate way to connect Z-Wave devices to Home Assistant.
- Z-Wave reborn - Home Assistant Connect ZWA-2
- Home Assistant Connect ZWA-2 Reveal Promo - YouTube
- Hyprvibe — A riced up Hyprland desktop running ontop of NixOS
- Keybinds Reverting to older config? · Hyprvibe Issue #2
- Errors at the top of the screen · Hyprvibe Issue #3
- Quinn's NixOS Setup: The Formatter
- Quinn's NixOS Setup: The Home
- Quinn's NixOS Setup: The Shared
- Quinn's NixOS Setup: The Hosts
- LibreNMS — A fully featured network monitoring system that provides a wealth of features and device support. LibreNMS is a fork of Observium.
- Observium — Observium is a network monitoring and management platform that provides real-time insight into network health and performance.
- Shift Systems / ShiftMon · GitLab — An open source monitoring and logging tool based on Ansible, Telegraf, Grafana, and a bunch of other tools
- sst/opencode — AI coding agent, built for the terminal.
- Lightning Grows Up | This Week In Bitcoin 68
- flatpak/xdg-native-messaging-proxy
- NativeMessaging portal for sandboxed browsers · flatpak Issue #655
- Pick: papra — The minimalistic document archiving platform.
- Papra - Demo
- Pick: lue — Terminal eBook Reader with Text-to-Speech
- Pick: wlgblock — This project replaces the usual password screen with a Gameboy emulator running a patched Pokémon game!
Transcript
WEBVTT
00:00:11.519 --> 00:00:16.039
Hello, friends, and welcome back to your weekly Linux talk show. My name is Chris.
00:00:16.259 --> 00:00:17.139
My name is Wes.
00:00:17.499 --> 00:00:18.659
And my name is Brent.
00:00:19.159 --> 00:00:23.679
Hello, gentlemen. Well, coming up on the show today, we have some big news stories to dig into.
00:00:24.579 --> 00:00:29.499
Then I'm going to tell you how my hyper-tuned play toy has turned into something
00:00:29.499 --> 00:00:31.479
that's maybe the real deal.
00:00:31.659 --> 00:00:35.959
And then we'll round out the show with some great boosts, a whole rack of picks,
00:00:36.099 --> 00:00:39.419
too many picks, and a lot more. So before we go any further,
00:00:39.639 --> 00:00:43.159
let me say a time-appropriate greeting to our mumble room. Hello, VirtualLug.
00:00:43.859 --> 00:00:47.939
Hello, Chris. How are you? And hello, Brent. Hello. Hello, Dave.
00:00:48.839 --> 00:00:51.899
Nice to see you. Everybody camping out there in the quiet listening.
00:00:52.059 --> 00:00:55.499
And shout out to our live matrix as we go along, too.
00:00:56.239 --> 00:01:01.299
And, of course, Define.net slash unplugged. Go meet Managed Nebula from Define Networking.
00:01:01.579 --> 00:01:07.539
It is a decentralized VPN built on the open-source Nebula platform that we love.
00:01:07.539 --> 00:01:10.379
And I'll get more into that in just a moment. But Nebula is really something special.
00:01:10.539 --> 00:01:14.779
It's super fast. It's simple. And it has industry-leading security.
00:01:15.639 --> 00:01:18.839
Nebula's decentralized design means that your network is resilient in a way
00:01:18.839 --> 00:01:21.959
that the other providers just cannot offer or manage.
00:01:22.219 --> 00:01:26.339
And you can go from just a home lab all the way up to a global enterprise.
00:01:26.559 --> 00:01:30.759
It was originally developed back in 2017 to securely connect Slack's global
00:01:30.759 --> 00:01:32.579
infrastructure, which is all over the place.
00:01:33.239 --> 00:01:37.159
And they've got, like, the world's trade secrets in their system.
00:01:37.159 --> 00:01:38.339
So they had to have it secure.
00:01:38.499 --> 00:01:41.579
Nebula was engineered to scale, perform, and be secure from day one.
00:01:42.279 --> 00:01:47.999
And this, okay, what I love is that it's truly top to bottom an open source platform.
00:01:48.639 --> 00:01:51.559
Right? So if you're building your whole network infrastructure on this,
00:01:51.699 --> 00:01:54.079
you could do all of it yourself, open source.
00:01:54.439 --> 00:01:57.599
But it also means that you can watch development and see where things are going.
00:01:58.901 --> 00:02:02.901
And there's an issue that has been in the works since October of 2022.
00:02:04.241 --> 00:02:08.421
And it's a nice little win for the Nebula community because they've begun testing this upstream now.
00:02:08.601 --> 00:02:13.681
And it allows Nebula to support multiple UDP source ports, i.e. multiport support.
00:02:14.201 --> 00:02:17.581
And this is no small feat. Like this has been challenging for WireGuard in general.
00:02:17.801 --> 00:02:20.861
And this week the work was finished upstream. Now it's not shipping.
00:02:21.001 --> 00:02:22.161
They're still looking at it.
00:02:22.821 --> 00:02:26.761
But what it means is this new multiport support means that you can tunnel a
00:02:26.761 --> 00:02:29.661
whole range of UDP source ports instead of just one.
00:02:29.981 --> 00:02:32.281
And that spreads the traffic across multiple flows.
00:02:32.941 --> 00:02:36.721
So if you've got like a cloud provider that's limiting you, or maybe you're
00:02:36.721 --> 00:02:41.261
on a connection like Starlink that's throttling you, you can kind of spread that out now.
00:02:41.881 --> 00:02:45.321
They're running through the test. It's not shipping, but oh man,
00:02:45.381 --> 00:02:48.521
does it look good. And the payoff is better reliability on these connections too.
00:02:48.861 --> 00:02:52.861
And in the thread of the PR, there's some massive gains noted.
00:02:53.581 --> 00:02:57.161
They write, I suspect that Verizon was throttling individual UDP streams.
00:02:57.781 --> 00:03:03.521
So this proved that to be true. I went from 50 megabits to one gigabit by using
00:03:03.521 --> 00:03:05.481
a 4X multiport configuration.
00:03:05.821 --> 00:03:06.201
Whoa.
00:03:07.121 --> 00:03:12.081
Yeah. So it's one of those things where as somebody who's planning their infrastructure,
00:03:12.821 --> 00:03:14.721
it's really nice to see this stuff coming.
00:03:14.841 --> 00:03:19.181
You can watch this from 2022 all the way to today where they're working it out.
00:03:19.281 --> 00:03:21.181
They're testing it. They're documenting the results.
00:03:21.561 --> 00:03:26.501
They're discussing if they should ship it. It's all right there for the world to see.
00:03:27.161 --> 00:03:30.221
And you can trust it when you build on top of that because it's open source
00:03:30.221 --> 00:03:31.921
and that's all just out there in the open.
00:03:32.561 --> 00:03:35.121
And they make it completely hassle-free with their managed product.
00:03:35.541 --> 00:03:37.741
Nothing else has the resilience, speed, or scalability.
00:03:37.921 --> 00:03:40.821
Get started with up to 100 hosts, absolutely free, no credit card required.
00:03:40.821 --> 00:03:43.941
Go to defined.net slash unplugged.
00:03:44.241 --> 00:03:46.461
That's defined.net slash unplugged.
00:03:49.204 --> 00:03:53.024
Okay, so we are planning our Texas road trip. We're still looking for anybody
00:03:53.024 --> 00:03:54.884
who would like to help us go there and do our coverage.
00:03:55.024 --> 00:03:57.924
So reach out to me, Chris at JupyterBroadcasting.com if you'd like to work together.
00:03:59.184 --> 00:04:05.364
And we have been considering a just after the fest meetup.
00:04:05.784 --> 00:04:10.144
And I want to know if there's interest because it's specifically for people that are road tripping.
00:04:10.824 --> 00:04:13.984
We haven't really figured this out, but we figure towards the end of Texas Linux
00:04:13.984 --> 00:04:17.984
Fest or the day that we're leaving, as we're going out of town or something
00:04:17.984 --> 00:04:21.124
like that, We set up for a breakfast and we have one last goodbye.
00:04:21.864 --> 00:04:24.564
We usually do these things like before the events or during the event,
00:04:24.644 --> 00:04:25.684
but I thought, wouldn't it be kind of fun?
00:04:25.824 --> 00:04:30.624
So if you want to join us, reach out, boost in or send us an email and say you'd
00:04:30.624 --> 00:04:34.504
be interested in doing like a after the festival meetup kind of thing.
00:04:34.624 --> 00:04:38.964
And if we get a few bites, we'll put something together like Brent over there.
00:04:39.064 --> 00:04:40.244
He's putting something together right now.
00:04:40.244 --> 00:04:43.324
Sure am i've been thinking the last couple weeks that
00:04:43.324 --> 00:04:46.784
i might consider crashing the september 20th
00:04:46.784 --> 00:04:49.864
meetup of the jb crew in toronto but i
00:04:49.864 --> 00:04:54.344
want to know would people show up if i end up in that neck of the woods maybe
00:04:54.344 --> 00:04:59.804
i can convince i don't know other jb friends to show up too so uh let us know
00:04:59.804 --> 00:05:06.864
if you'd be interested in a brent crashing september 20th in toronto and uh if so,
00:05:07.744 --> 00:05:13.204
please go to our jb colony events website there's a little posting there of
00:05:13.204 --> 00:05:17.124
the location and uh if if you don't mind register your attendance and let us
00:05:17.124 --> 00:05:18.824
know if that would be interesting to you.
00:05:18.824 --> 00:05:21.364
I guess we got to get some tickets huh chris.
00:05:21.364 --> 00:05:26.724
Yeah we better i mean i don't think actually we were technically invited yet west so true.
00:05:26.724 --> 00:05:30.924
Let us know if you'd like us to invite chris and maybe.
00:05:30.924 --> 00:05:36.304
Don't uh but yeah colony events.com and we will have a link in those show notes,
00:05:39.650 --> 00:05:43.710
All right, so let's do a news update. It's been a minute, and there is a story
00:05:43.710 --> 00:05:49.730
that we sort of have a midway update on, and it's BcacheFS's inclusion in the Linux kernel.
00:05:50.490 --> 00:05:54.510
And while things are still very much in development and the situation is fluid,
00:05:54.770 --> 00:05:59.690
as things stand right now, it is possible that Linux may lose out on the next
00:05:59.690 --> 00:06:04.250
big file system, not because of code issues, but over a clash of personalities.
00:06:05.630 --> 00:06:10.630
And Linux 6.17 is out, but without the BcacheFS updates.
00:06:10.950 --> 00:06:15.890
Yeah, just to be clear, it's not that 17's out totally, but we're in the RC phase now.
00:06:16.030 --> 00:06:21.070
So that merge window has closed and no poll for BcacheFS.
00:06:21.390 --> 00:06:26.390
And it's all kind of unfortunate timing because BcacheFS core developer Kent
00:06:26.390 --> 00:06:28.410
Overstreet passed guest on this program.
00:06:28.410 --> 00:06:33.550
Well, he mentioned that he'd planned for BcacheFS to actually shed that experimental
00:06:33.550 --> 00:06:37.030
label in 6.18, the next kernel.
00:06:38.450 --> 00:06:44.410
But, unfortunately, disagreements over his criticisms on the LKML about the
00:06:44.410 --> 00:06:49.470
ButterFS file system, well, that ended up turning into a rather heated exchange
00:06:49.470 --> 00:06:51.270
on the mailing list this past week.
00:06:52.010 --> 00:06:56.050
Meta's Yosef Bacik has done a ton of great work on ButterFS,
00:06:56.790 --> 00:07:01.970
called Kent's behavior unacceptable, and the ext4 maintainer Ted So went further,
00:07:02.110 --> 00:07:07.270
saying, many developers see him as, quote, toxic, and want his code removed.
00:07:07.550 --> 00:07:11.170
And Ted was clear, not for technical reasons. It seems like actually most of
00:07:11.170 --> 00:07:15.050
the folks in this thread respect Kent's technical chops and BcacheFS,
00:07:15.290 --> 00:07:16.770
you know, just as a code base.
00:07:17.310 --> 00:07:21.890
But for Kent's style of communication and his conduct, and in particular here,
00:07:22.330 --> 00:07:24.670
criticizing other file systems in the kernel.
00:07:25.090 --> 00:07:31.390
Now, Kent has promised to stop criticizing ButterFS, but the fallout makes it
00:07:31.390 --> 00:07:36.970
even more likely that BcacheFS won't be seeing any advances or maybe even not
00:07:36.970 --> 00:07:39.550
continued acceptance in the kernel.
00:07:40.805 --> 00:07:44.305
You know, it kind of seems like this dispute is highlighting a long-running
00:07:44.305 --> 00:07:48.425
issue we've seen for years in the development of Linux, which is sometimes,
00:07:48.805 --> 00:07:51.265
you know, it's not just about the technical decisions.
00:07:51.445 --> 00:07:55.365
That can actually be overshadowed by personality clashes, politics,
00:07:55.585 --> 00:08:01.485
and just people having to try to work together in the open across the world,
00:08:01.685 --> 00:08:03.545
maybe without really even knowing each other.
00:08:03.805 --> 00:08:07.405
And that can actually leave users in a lurch. You know, you might not get the
00:08:07.405 --> 00:08:11.365
tool you want, not to technical reasons, but because of people.
00:08:11.805 --> 00:08:15.165
Now, we thought Liam over at the register put it pretty well.
00:08:15.385 --> 00:08:19.145
It looks likely that Overstreet has upset too many important,
00:08:19.465 --> 00:08:21.945
influential people and hurt too many feelings.
00:08:22.145 --> 00:08:28.065
And as a result, Linux is not going to get a new next-gen copy-on-write file system.
00:08:28.305 --> 00:08:33.045
It's a significant technological loss, and it's all down to people not getting
00:08:33.045 --> 00:08:37.025
along, rather than the shared desire to create a better OS.
00:08:37.525 --> 00:08:41.245
I think that is well put. I'm on the record of thinking this is an extremely
00:08:41.245 --> 00:08:42.585
important file system for Linux.
00:08:43.465 --> 00:08:48.705
And my takeaway is, and I say this, I don't like saying this at all because
00:08:48.705 --> 00:08:51.425
I have so much respect for the individuals involved. They're really titans.
00:08:51.845 --> 00:08:55.225
We stand on their shoulders and, you know, they're smarter than me.
00:08:55.325 --> 00:08:56.585
They've accomplished more than me.
00:08:57.405 --> 00:09:00.465
They're great individuals. And yet,
00:09:00.825 --> 00:09:07.765
as happens to anyone who is in a position of power and maybe some comfort for
00:09:07.765 --> 00:09:12.005
a while, they lose touch with the people on the ground and they become more
00:09:12.005 --> 00:09:13.405
and more out of touch over time.
00:09:13.725 --> 00:09:17.065
And I think we're seeing the signs of that right here. And I get no joy in saying
00:09:17.065 --> 00:09:20.645
this, but they don't have the hunger to make Linux competitive anymore.
00:09:21.185 --> 00:09:25.925
And they don't understand the situation out here on the ground or facing because
00:09:25.925 --> 00:09:27.325
they don't deal with these things anymore.
00:09:28.065 --> 00:09:31.045
I would bet you if you polled them, most of them are probably using Extended 4.
00:09:32.418 --> 00:09:35.558
So the people that are probably perfectly comfortable with the way things are
00:09:35.558 --> 00:09:40.258
right now are put in a position to make a decision over personality conflict.
00:09:41.058 --> 00:09:45.358
And it makes the operating system less competitive. There will be ways to run
00:09:45.358 --> 00:09:48.858
BcacheFS, and no doubt we will cover those ways and we will use those ways.
00:09:49.278 --> 00:09:54.398
But when you don't include it in the kernel, you are going to always exclude
00:09:54.398 --> 00:09:59.038
a certain niche of users, maybe embedded systems or something like that.
00:10:00.098 --> 00:10:04.218
And it doesn't provide the level of guarantee that a file system built into
00:10:04.218 --> 00:10:07.718
the kernel does when you do upgrades and, you know, update your bootloaders
00:10:07.718 --> 00:10:08.898
and your kernels and your whatnots.
00:10:09.338 --> 00:10:14.218
So it's a downgrade in functionality for what is a very competitive and impressive file system.
00:10:15.858 --> 00:10:20.958
And this was going to be one of the answers to not having ZFS in the kernel.
00:10:22.218 --> 00:10:25.278
This is another issue that the kernel developers have been ignorant,
00:10:25.458 --> 00:10:26.678
arrogant, and out of touch on.
00:10:27.918 --> 00:10:32.118
And so Bcash FS was a solution to this that took the pressure off of the ZFS issue.
00:10:33.618 --> 00:10:37.098
But they're too blind by their own egos to appreciate the stakes here.
00:10:38.298 --> 00:10:43.358
We literally are making decisions based on feels now. And my last point on this.
00:10:44.598 --> 00:10:48.798
The tone is set from the top. You set the tone from the top.
00:10:49.098 --> 00:10:53.998
And Kent is being persecuted for things that are no worse than have been said
00:10:53.998 --> 00:10:55.418
by Ted or Linus themselves.
00:10:55.418 --> 00:11:00.938
Just two weeks ago Linus told an individual that their code made the world a
00:11:00.938 --> 00:11:06.298
worse place you set the tone from the top so how do you persecute Kent who hasn't
00:11:06.298 --> 00:11:07.678
even said anything that hostile,
00:11:08.438 --> 00:11:13.418
when the leadership acts like that all the time and if we zoom out over the
00:11:13.418 --> 00:11:15.698
30 years of which Kent is familiar with,
00:11:16.498 --> 00:11:19.218
the dialogue was even more let's say robust,
00:11:20.078 --> 00:11:24.378
so we have 30 years of the tone being set from the top.
00:11:26.308 --> 00:11:30.988
And then all of a sudden, we just shut the door on that. And as a result,
00:11:31.248 --> 00:11:34.628
everyone listening to this podcast loses out.
00:11:36.188 --> 00:11:40.868
Everyone running Linux. And there's not even a good technical reason.
00:11:42.408 --> 00:11:43.648
This is where we're at now.
00:11:45.228 --> 00:11:49.528
It's pretty embarrassing. That's my take, at least. Hopefully this gets worked out.
00:11:49.628 --> 00:11:53.948
It's still, you know, it's an in-fluid situation.
00:11:54.628 --> 00:11:55.988
It's a dynamic situation.
00:11:56.308 --> 00:12:01.148
So there was some talk in it. I guess to hear Kent talk, it almost happened
00:12:01.148 --> 00:12:05.468
that for 6.17, he was able to find an intermediary, you know,
00:12:05.548 --> 00:12:08.448
to sort of be the person interacting with the mailing list that wasn't Kent.
00:12:08.648 --> 00:12:12.668
But of course, that's a tough job between being acceptable to Kent and knowing
00:12:12.668 --> 00:12:15.668
and being able to work well with the upstream Linux community.
00:12:15.668 --> 00:12:19.888
So that might be something we see in a future somewhere. And I saw over on the
00:12:19.888 --> 00:12:24.988
BcacheFS subreddit, a ZFS dev coming over and chatting with folks there and
00:12:24.988 --> 00:12:26.248
offering a lot of really constructive,
00:12:26.448 --> 00:12:31.048
concrete advice about, you know, if DKMS or similar is going to be the main
00:12:31.048 --> 00:12:34.508
way to run this file system for a while. There are advantages to that.
00:12:35.028 --> 00:12:38.068
There are some tips were shared, which is great. It's not like this is pure
00:12:38.068 --> 00:12:41.228
antagonism between all of these file system developers. I don't want that to
00:12:41.228 --> 00:12:42.648
be the picture people get here.
00:12:43.008 --> 00:12:45.928
And Kent has committed, it sounds like, to being, you know, pretty aggressive.
00:12:45.928 --> 00:12:52.028
Of so there won't be a ton of lag issues so you know 6.17.0 or whatever you
00:12:52.028 --> 00:12:56.448
know one of the first kernels that you might actually run should have good support.
00:12:56.448 --> 00:13:01.488
Yeah so we can now have a long distance relationship with bcachefs i will.
00:13:01.488 --> 00:13:04.728
Say too i just want to be clear like i don't think we're trying to say kent
00:13:04.728 --> 00:13:08.008
hasn't done you know hasn't had issues here i'm not trying to defend all of
00:13:08.008 --> 00:13:11.848
the statements by kent or say that there couldn't be a lot of improvements on that side too.
00:13:11.848 --> 00:13:12.688
I agree but.
00:13:12.688 --> 00:13:14.528
The end result is is definitely disappointing.
00:13:14.528 --> 00:13:19.508
Yeah there's some frustration too that Kent couldn't have adapted his approach
00:13:19.508 --> 00:13:23.868
and communication style much earlier in all of this there has been several off-ramps
00:13:23.868 --> 00:13:27.948
along the way that he could have taken here and that I think is on Kent and
00:13:27.948 --> 00:13:32.328
that's just my opinion so it's not all the kernel developers but there is just this,
00:13:32.928 --> 00:13:35.588
I don't I'm gonna I'll punt it to the audience to tell me if you think I'm off on this but
00:13:35.588 --> 00:13:38.708
I just think there is this extreme irony
00:13:38.708 --> 00:13:42.948
in individuals who have been called toxic and are
00:13:42.948 --> 00:13:47.768
now calling someone else toxic and it's just they're doing to someone what has
00:13:47.768 --> 00:13:51.448
been attempted to be done to them and it's i don't like it i don't know boost
00:13:51.448 --> 00:13:54.748
in you know my thoughts on bcashfs have been clear how do you feel about this
00:13:54.748 --> 00:13:59.008
entire situation let us know because uh it's got me fired up.
00:14:00.314 --> 00:14:02.894
I am hopeful that there will be either some sort of, like Wes said,
00:14:02.954 --> 00:14:06.534
intermediary or a pretty straightforward approach.
00:14:06.774 --> 00:14:10.414
Kent is all over the kernel development cycle, so I have no doubt,
00:14:10.414 --> 00:14:14.634
like, the day that the kernel ships stable, he'd probably have an update. It's a solution.
00:14:15.434 --> 00:14:19.694
It's one I shouldn't have to use, but it's a solution. Let's talk about something
00:14:19.694 --> 00:14:22.874
kind of fun. This is interesting.
00:14:23.474 --> 00:14:27.974
Ubuntu has committed to developing a new dangerous desktop image.
00:14:28.574 --> 00:14:33.434
Yeah, they're calling it the Dangerous Edition. It's daily builds,
00:14:33.454 --> 00:14:38.954
and all the applications are snaps pulled from the edge channel for the snap.
00:14:39.594 --> 00:14:43.734
So it's the absolute newest, raw, most experimental snap versions.
00:14:44.354 --> 00:14:50.534
And the idea here is to make it easier for devs to seed snaps during what they
00:14:50.534 --> 00:14:54.194
call their spike development, kind of like their sprints, which can last for like six weeks.
00:14:54.934 --> 00:14:59.854
And then they can focus deeply on one thing and this could be a time to get that stuff involved
00:15:00.274 --> 00:15:04.114
recently that was done with tpm full disk encryption work and the next spike
00:15:04.114 --> 00:15:08.334
is the desktop prompting client i suppose i think this is really interesting
00:15:08.334 --> 00:15:11.114
obviously it's not meant for end users to run on the daily but,
00:15:13.072 --> 00:15:17.392
I like that they're calling it the dangerous version, the Ubuntu Dangerous Desktop.
00:15:17.392 --> 00:15:18.892
I think that's a great name.
00:15:19.032 --> 00:15:22.672
And it really conveys like, hey, don't run this as your daily driver.
00:15:22.832 --> 00:15:27.472
But if you need access or if you're working on something developing, this is where to go.
00:15:27.832 --> 00:15:30.912
I think it's neat, too, because previously, right, this was all kind of work
00:15:30.912 --> 00:15:34.032
that I'm sure many developers, people hacking on this stuff,
00:15:34.232 --> 00:15:36.272
were doing already in various different ways.
00:15:36.472 --> 00:15:40.212
So the more you do it faster and make it available upstream so that you have
00:15:40.212 --> 00:15:43.252
a common shared base to start development from that's refreshed often,
00:15:43.792 --> 00:15:46.692
I mean, that's just less work for more people, which is great.
00:15:46.972 --> 00:15:50.792
We did get some more details here. Canonical engineer Tim Anderson of the Ubuntu
00:15:50.792 --> 00:15:56.132
release management team had a nice summary of these new dangerous desktop images,
00:15:56.312 --> 00:16:01.072
saying, quote, we're currently working on building what we're calling dangerous images.
00:16:01.392 --> 00:16:04.632
They'll be the same as daily desktop images for the Devel series,
00:16:04.832 --> 00:16:08.392
but all of the snaps will be on their respective edge channels.
00:16:08.832 --> 00:16:12.172
This work is ongoing, and there's going to be some more news soon.
00:16:12.552 --> 00:16:16.772
These images are intended to help developers who work on our seeded snaps.
00:16:17.252 --> 00:16:21.092
During the TPM full disk encryption spike earlier this year,
00:16:21.412 --> 00:16:24.632
all the snaps for daily builds were switched to edge to help those developers.
00:16:24.952 --> 00:16:29.472
And these dangerous images will remove the need to do this in future spikes,
00:16:29.732 --> 00:16:31.492
one of which starts on Monday.
00:16:32.092 --> 00:16:37.192
For those who are unaware, within Canonical, we've started doing spikes this cycle.
00:16:37.452 --> 00:16:42.292
Spikes are segments of the whole cycle, six weeks long, where members of varying
00:16:42.292 --> 00:16:46.872
teams join together to focus on one topic, partially or entirely,
00:16:47.352 --> 00:16:49.292
leaving behind their regular daily duties.
00:16:49.992 --> 00:16:54.412