LINUX Unplugged - 434: Endlessly Flat

Episode Date: December 1, 2021

The Director of EndlessOS joins us to respond to recent Flatpak criticism. We take the opportunity to expand on the overall effort to solve Linux fragmentation. Special Guests: Martin Wimpress, Neal Gompa, and Will Thompson.

My latest Linux box has more connectivity than a MacBook before 2021, has a full QWERTY keyboard, and it fits in my pocket. It's the Pocket Popcorn Computer. It's still really early days with this thing, but it's a handheld Linux device with a 1080p display and a pretty nice battery that is user-replaceable. And they're thin enough that you could legitimately probably buy three or four off of Amazon and just keep them in your backpack. It's got a backlit RGB keyboard. And, of course, it runs Linux, right? I mean, obviously. It's not, like, fully done yet.

It still has a few rough edges, but I really like it so far. I just got it this morning, and I've been playing with it. How rough are the rough edges? Well, they're rough. I don't know if there's really even a full image that's done yet for it. So it's a pretty basic command line device. Yeah. And there's some things like if you turn the keyboard backlighting on and then you don't turn it off before you shut it down, it's stuck on. But it's stuff that's like totally understandable for an early device that seems solvable so it's not like i'm

too worried about it and it's funny how nice it is to have something that you can pull the back off of and replace the batter like it just sort of you get your you run your finger under there and it just kind of pops right off and it's within a second i'm in there and i can swap the battery out what a concept i'm pict'm picturing an ASMR battery swap session here. Hello, friends, and welcome back to your weekly Linux talk show. My name is Chris. My name is Wes. And my name is Brent.

Hello, gentlemen. I'll be playing with this popcorn computer for a little bit. And I'll try to give you an early impression slash review next week. But coming up on the show this week, we've talked about a tricky problem in the past. It's Linux fragmentation in a way that we don't normally consider fragmentation. It's an actual tricky problem specifically for shipping applications on Linux and desktop applications. And there are several different types of technologies out there to solve this problem from Docker and snaps and app images. And Flatpak is one of the best known ones in our community

and on the desktop. But recently, a very critical analysis was posted that brings using Flatpak into question to solve the various software distribution problems we have on Linux. In fact, you may have seen it. The post was titled Flatpaks are not the future or something to that effect. So this week, what we wanted to do was work through some of those criticisms, respond to the ones that make sense to respond to, and maybe even discuss some of the changes already being made in Flatpak that address some of those concerns.

So in just a little bit, Will Thompson, the director of Endless OS, or the platform for Endless, over at Endless, he's sort of like the king of Endless OS, will join us to discuss some of this. And Endless OS knows their Flatpaks. I'll have to get the number from Will, but it's a lot of Flatpaks. So before we get into all of that, I wanted to say time appropriate greetings, virtual lug. Hello, Mumble Room. We have quite the panel today, which is great because this is a topic that has been on all of our minds. And it seems every solution we've come up with has its group of critics.

So I think it's going to be a good little chat. Well, before we dive into the nitty gritty details of Linux packaging, we do have a bit of early housekeeping to do today. So a plan is coming together. This is a big deal. And I wanted to give everybody a heads up as soon as possible. We're really early days into this, so I don't have everything figured out yet. As soon as possible. We're really early days into this. So I don't have everything figured out yet. But brace yourselves.

We have some announcements to make. We are moving our meetup. For the new server christening party. To January 2nd. 2022. We're going to have a new year. New server. And a new love party.

As well. As the launch of a new Linux show. So let's get this all out there. We want you to come up to the studio on January 2nd, horrible virus aside. We're going to have to keep our eyes on that because we just don't know at this point in time where that's going. So we will be keeping an eye on the news. We will try to stay flexible in that regard. We're

going to have to ask that of you as well. But right now, assuming things are okay, January 2nd, 2022, LUP from that point forward will be live on Sundays. This is a massive change, and it's not one that we're making lightly because we love our Tuesday time slot, but we're moving a few things around. We'll have more information in that regard soon. That's one of the changes that's taking effect starting January 2nd. LUP will be live on Sundays at the same time. I'm going to make an effort though to participate in a live stream on Tuesdays at the regular time most weeks. I'll have more information on that soon. So there will still be some live stream and mumble attendance at that time. We'll also launch the new server. It'll be the christening party. We'll have a potluck here at the studio with the audience. And then what we'll do is we'll launch the server. We'll eat. And then

Brent, Wes, and I will go into the studio and record a Linux Unplugged. And our guests are welcome to stay here and listen to us record the show live in the studio. We both have a living room, which you'll be able to wait in. And of course the studio itself, uh, then that point forward level will be on Sundays. And we'll also have a brand new Linux show that is launched that I'll have more information on soon that I am super excited about. So there's a ton of stuff going on new year, new server, new love, January 2nd, come hang out with us in the studio. We will also try to live stream that party. I don't know how the hell we will do that. So it's like a

50-50 shot, but you know, I'm willing to like bring us like a jitsi and set it up on a few devices around the house or something. We'll figure it out. And if you are in the area or you can make it, you're welcome to join us for the potluck and the new server christening and the new love live day.

We can talk more about that too of course in the post show you're always welcome to join us on tuesdays while we are remaining in this time slot i think we're going to be live every week for the rest of the year as far as i can figure because love doesn't land on a holiday so we will be live for a few more tuesdays and we would absolutely love to have you so check in on us say, say goodbye, maybe, you know, if you're a Tuesday person, and if you're a Sunday person, pencil it in, consider joining us. And hopefully, hopefully, you'll love the new show when it's launched and announced. But I'll have more information about that later, because we have a lot more to get into. And hey, don't forget jupiterbroadcasting.com

slash calendar to actually find out when we're live. Yeah, that's very, very handy. So let's talk about one of the most popular solutions to solve the Linux desktop problem. And that is really that we have so many different distributions with so many different library versions and so many different this and that. Plus, you have a general requirement to start sandboxing applications for security purposes. If you want users to be able to download things safely online, it'd be nice that those things are limited in what they can do to a system. And it solves a problem. And Flatpak isn't the only one. Snaps do this.

App images do this. In a lot of ways, just general containers can do this. But today we're talking about Flatpak. And I like to think of it for the end user, it solves a problem where you can be on an old version of Debian and I can be on a brand new version of Fedora, but we can run the same application. In a lot of ways, that's how it's going to impact end users ultimately. But a lot of ways, it also means we have a way to preserve software it also means we can run new software on old systems and it gives users and developers predictability you can always expect

that a subset of runtimes will be supported and compatible so you actually have a versioned thing on the linux desktop you can target so flatpak solves those kinds of things with runtimes and whatnot in there. And it solves the sandboxing problem. And it also lets vendors self-host their own repositories and projects. It does support commercial software. And it also has a very popular distribution mechanism through Flathub that is being integrated into distributions like Fedora. But nothing is so perfect that it can't be criticized. And the reality is there is quite a bit of criticism out there about Flatpaks. And the one that's really

been going around this week is a criticism of some of the design choices in Flatpak. And one of them really comes down to storage and just duplication of work and libraries. Well, Will Thompson wrote a blog post this week addressing this criticism. And with Will's role at Endless, he's pretty deep in this ecosystem and is definitely one of the people to talk about this. Will, welcome to Linux Unplugged. Thanks. It's really great to be here.

Thanks for the invitation. So you are the director of platform at Endless OS, and I get a sense that means you're pretty familiar with how many flat packs you guys ship and the role of flat packs in the Endless distribution. Is that right a sense that means you're pretty familiar with how many Flatpaks you guys ship and the role of Flatpaks in the Endless distribution. Is that right? Yeah, I guess so, yeah. I'm the director of OS these days. It's a funny situation.

You'd expect from the name of EndlessOS Foundation, we only do an OS. We do other things as well. But yeah, I'm responsible for the OS side of things. The whole distro is based around Flatpaks. We ship a small and shrinking number of apps baked into the system, and as much as possible is done with Flatpaks on top of that.

So a typical installation of Endless comes pre-installed with 60, 80 Flatpaks out of the box. My system right here has 160-something. Wow, that definitely is more than anything I've got in any of my boxes. So you really live in the flat pack lifestyle. And so you must be just completely out of disk space because one of the criticisms I've seen is that once you have that many flat packs,

you have a hard drive full of runtimes and duplicate libraries. Is this true? Well, it depends what you think of as full and big. I ran some numbers on this. This was one of the things that jumped out at me from this post because one of the first projects I worked on at Endless was around a downloadable version.

And although part of the thesis of Endless OS is that disk space, when you've pre-installed lots of offline content, is much cheaper than getting internet connectivity in a rural town. So you better use the cheap disk space to store as much as possible so you don't have to download it later. But then when you come to actually people wanting to download it, you start looking a little closer at how much space things are using.

From those 160-something apps on my system, I can't measure the apps quite so easily. Maybe I can. We'll do it live. Let's check. But while I type and see if I can type fast enough to type while I can talk. Hey, real-time data is worth it. Absolutely. That's what we're all here for. That's my fundamental point here is the data exists.

You just have to look for it. So I'm running the numbers on the app. So I have 56 gigabytes of Flatpak stuff installed. And bear in mind that includes a complete offline copy. No, not a complete offline copy, a large subset of Wikipedia in two languages, loads of offline reference material in video form and so on, as well as things you might normally think about as apps.

And so that's 56 gigs of stuff, of which 8.7 gigs is the runtimes i'm excluding some noise around the edges for translations and stuff like that so you know you may think that's that's 8.7 gigs of of the of the runtimes for those apps that sounds like quite a lot but the basic os is only four gigabytes so i think if you have a more conventional Linux system lying around it'll be interesting to look at how much storage you have on there for the apps versus the platform they depend on. A little harder to separate them perhaps. Sure. And if you install like your first Flatpak, maybe it's GIMP or Steam for some

of our listeners, you'll see a lot of runtime dependencies pull down. And it does seem like, gosh, that's a lot to install one application. But then when you install your second application that uses some of those same runtimes, it's already on the system, and the next app installs much quicker and pulls down a lot less data. Yeah, that's exactly right. And I had a look at this as well. And although there are a few stragglers where there's one app using one runtime,

which is not ideal, the vast majority of the apps on my system are shared across five runtimes. There's more than 100 of them across just five runtimes. So I think if you amortize the cost out across of all the apps using the same runtime, it starts looking a little bit less scary compared to the first impression.

That's exactly how I felt when I first started using a lot of Flatpak applications. When I went all in on Flatpak applications for a few of my Fedora installs, that was essentially my experience. So let's move to some of the other criticisms just to kind of get your thoughts on it. I think one of the other kind of criticisms that resonated for me was the sandbox still allows for essentially full access to somebody's home directory where a lot of their important information would be. And it allows for writing to something like the.autostart directory, which could just reinfect a user's system upon login over and over again. And he kind of makes the assertion that it's not like Android and iOS,

so therefore it's not good enough. What are your thoughts on that? Because this is obviously an important issue for Endless. Yeah, it is. I think it's a little bit more complicated than that post set out. Some apps can certainly write to those locations, but the Flatpak sandbox by default forbids all of that stuff. There's a kind of tricky balance of pragmatism and security here. Flathub would be useless if the apps didn't work.

And if the apps are written expecting they can write to your whole home directory, then they can't be made to work without that without someone going and modifying them and if you know that that may be intractable right now for various reasons but the the the preferred way for this stuff to work is that apps don't have these kind of static holes in the sandbox and they instead request access to just the resources they need so So that could be files, it could be a webcam. Hopefully in the not-too-distant future, your microphone will be treated the same way.

And one of the criticisms that I think is totally valid is that previous versions of GNOME software would claim that if an app is a flat pack, then it has a nice badge saying it's sandboxed. And this gives you this false sense of security, which I think is totally true, which is why in GNOME 41, software totally revamps this presentation.

So one of the big changes in GNOME 41 was a major revamp to GNOME software, which Endless contributed a lot to. And one of those changes is that now apps have a kind of traffic light system of are they safe, are they possibly unsafe, or are they unsafe? And so this is based on sort of heuristics about the kinds of these kind of sandbox holes that they request access to. So you can make a somewhat more informed decision. I mean, whether people at the end of the day would prefer to have Zoom work or not is another question,

but the information I think is a lot less misleading these days. And so if anything, it's shot in the other direction. There's lots of apps which have the word unsafe near them, which if you're taking a strip reading of this, they are. So I guess the hope is that this can act as a stick where the carrot is better APIs for getting out of the box. Right. I wanted to recommend a really nice graphical application to review and modify Flatpak application permissions called FlatSeal. We'll have a link to this in the show notes and

you can open that up. It'll show you your Flatpak apps and it'll give you a really quick overview of what they can and can't do. And just even having that kind of information is nice. And that's something that Flatpak enables. So FlatSeal is that app. Okay. So, well, there was one other criticism that I read in there that I thought, hmm, yeah, that doesn't seem great. And it's when he talks about namespace collision. He says Fedora publishes a Flatpak of GIMP as org.gimp.gimp. But that conflicts with the official org.gimp.gimp that is published by the actual GIMP developers on Flathub. And he says, you know,

they should have solved for this namespace collision problem ahead of time, and now it's sort of too late. Your thoughts on that? Yeah, this is an interesting one, right? Because one of the strengths of the Flatpak as a technology is that it's possible to have multiple repositories. And so Endless has its own app repo as well.

So Endless OS systems come pre-configured to install apps and have apps pre-installed from FlatHub and also from our own apps repository. That's kind of mainly because we deployed and released Endless OS with Flatpak before FlatHub existed back in 2016. And over time, we've been careful to avoid this kind of duplication. So when an app appears on FlatHub, we would remove it from EOS apps.

I mean, actually, in the early days, often we would be submitting the app from our store up to FlatHub. And for exactly this kind of reason, it makes for a pretty confusing user experience when you're offered two apparently identical ways to install the same app, and they may be pretty different maybe it wouldn't have been how i how i would have done it but uh the the other side of it i suppose is that because of the way the the sandboxing works apps only have access out of the box to data in a directory named for the app so you might hope that if you've installed the fedora version of the gimp and then you think oh actually the, actually, the version on FlatHub is fresher and you switch to that, you would probably like it to not lose all your settings, to not lose all of the dynamic

permissions you have given it through the portal system in a future month slash year when GIMP actually uses the portal APIs that Flatpak already provides. This is a problem, and it's one we've tried to avoid and end this by just not doing this, if that makes sense. Yeah, I mean, it does. And that is sort of the nice thing, is you can do that, you can have your own repository.

There's also all these different types of apps, right? I mean, it's one thing when we talk about GIMP because it's free software that multiple people can package versus maybe some of the proprietary apps, which the blog we're discussing also maybe puts a little focus on. It might not have that problem with, say, Slack. Yeah, it might not.

And the nice thing, one of the upsides of Flatpak and the standard selection of runtimes as an app developer is it gives you the stable baseline to target. And I think that's important both for larger commercial developers but also for small indie developers. There are loads of apps which have been written in the past year or so which are popping up straight onto FlatHub and they haven't had to run the gauntlet of getting through.

Someone has to painstakingly submit them to 20 distros or so. So yeah, I think one of the most interesting examples is OBS, the live streaming software. Backing up a bit, most apps on FlatHub are maintained using a Git repository on the Flathub GitHub org. With one historical exception has been Firefox. The Mozilla, when they make a new Firefox release, they publish the same official binary directly into Flathub. So it's the same bytes that you can download from their website, which has its ups and downs.

But one of the ups is that it's got all of the official Mozilla API keys baked into it. And Flathub now has, or is about to to have i forget which the the second such app obs the live streaming studio software will now be published directly to flat hub and again it has for the first time other than the ubuntu package so i suppose the second time but non-ubuntu users can get an officially supported version of that that has the API keys baked into it to access various web services that community source builds don't get. And by publishing it to this one place, they can reach all of the distros. That's really exciting to hear, actually. I think the other general criticism that really kind of comes down to philosophy and not really a technical

criticism, it's common in our community and it's one that our community is particularly quick to go to. And that is just a general criticism around the complexity of all of this. It's getting so complex that it's getting beyond the scope of an average user's ability to understand, and therefore, it's a negative thing. What are your thoughts on that? Well, who is your average user? The technology seems, some of it is pretty complicated. The way that portal APIs work to

securely pass access to a single resource from the host into the flatback is certainly more complicated than just opening a file on disk. But I think we all hear, perhaps, and I'm pretty sure the author of this post agrees that actually sandboxing is something we really do want. We do want this fine-grained,

user-interactive runtime permission system that requires the app to make Flatpak-specific API calls to activate permission dialogues. I'm quoting directly from this blog post because I agree, and that is what Flatpak provides. It has that. So this is a nice point. We agree on this. This is good.

And you need some complexity that you don't have with just simple file system access to enable that. But one of the things that works well with Flatpak for endless OS is that it makes, by really wholeheartedly adopting it, it actually makes the whole platform simpler to administer, particularly if you're not the kind of person who actually wants to administer a computer, you just want to use it. So Flatpak uses OS Tree, which is a bit like Git for

computer programs, or Git for file systems. One of the things that works really well in Endless OS is that we've really adopted Flatpak wholeheartedly. Flatpak is a footnote about Podman containers, but all apps on the system from a user who doesn't know what a terminal is, is perspective. They're all coming from Flatpaks, or they're baked into the OS. And the OS is, just like Flatpaks are,

is distributed as a single immutable blob. You can't add packages or remove packages from Endless OS. It is a single unit, and it gets updated atomically using the same deduplication for updates as Flatpack provides you can roll back to the previous version which is kept around in case of something terrible and so this actually makes for a really simple system that for more than half a decade endless os systems have been automatically updating if they're online both the os and flatpacks if the network connection is not metered. This happens automatically in the background and safely.

So the resulting complexity for a user, I would claim, is actually less. You have one place to get your app. You have one button to hit to install it. If you press remove, it's gone. You can't break the OS. I would say that's been my experience too, is there may be more going on under the hood, but it has, from an end user's perspective, especially when I'm using something like GNOME software and Fedora

35, it is very simple. Will, if you wouldn't mind, I wanted to give Wimpy a chance to jump in here and a couple other people, because I know they've got a few questions. So Wimpy, go ahead. Hello there. This is a fascinating conversation. And I read the blog post that you're sort of citing in all of this um and i i suppose i'm coming out in support of not just flat pack but you know containerized application delivery as a philosophy as a whole um the whole argument that it is complicated for people to install applications using insert name of your favorite containerized application platform. And by the way, I'm excluding AppImage from that because it is not that. It's bunkum. It's simply not true. The data that I had available when I worked at Canonical

showed us that overwhelmingly the people installing applications on the Ubuntu desktop were doing it through the software center, which was a rebranded version of GNOME software. And application installs are but a click away, regardless of whether that's a flat pack or a snap. And it could not be easier. And all of that ability to do atomic updates and reliable updates and having a single source, authoritative source for application delivery is far simpler than it ever was in the past with, you know, scattershot copper repositories or PPAs that you have to, you know, tag on the end of your operating system or, you know, the AUR on top of Arch. So I completely reject that argument that it's complicated for new users because it could not be simpler. I'm curious, maybe what do you think, because part of the thing in this blog post is that we're talking about a lot of different groups. There's the user perspective, but then there's also

the distribution perspective and then the application developer. And it seems like to some extent this post is maybe arguing, not necessarily for PPA, but for the standalone simpler installations. Maybe you're downloading a tar file or you're running a standalone installer in the Windows way. Curious how that rings to you, Wimpy. I feel like it doesn't matter which of the contemporary packaging systems you're utilizing,

their integration with those software services, those software delivery services, make that easy. And the core principle, certainly from a Snap perspective, was this. If you look at what popularized in the mainstream app stores, which is mobile phones, those applications are not curated, packaged, or maintained by a group of volunteer packagers. Those applications are packaged and delivered directly to those stores by the application developers. So it's positive news that the authoritative publishers of things like Firefox and OBS Studio, and I know OBS Studio has been getting a massive leg up from the fine work from George and all that he's been doing in OBS in the last year or so. It's fantastic work. The fact that Flathub is pivoting to vendor-published apps rather than community-maintained apps is the right move because there are tens of thousands of applications

in our distributions repositories maintained by volunteers. There are millions of applications in the app stores for the mobile platforms. And one of the big differences is there are millions of bits of software on GitHub, but they are not in our application repos. If we pivot to a developer publishes their app, that scales far better than spreading millions of apps across a few hundred enthusiastic maintainers. I couldn't put it better. I think one of the kind of pragmatic things about FlatHub historically has been you've got to start somewhere, right? And so a larger proportion than I would like of the apps on FlatHub are community maintained. And I think that is changing. And the work like, yeah, George's work on helping to get the OBS studio working well

as a FlatPack, integrating well with all the modern portals, and getting this publication, this first-party publishing working is really superb. The other interesting development in this area is that FlatHub has just put out a call for contractors to work on FlatHub. It's on the FlatHub discourse. I can pop a link. Maybe I can send a link over to pop in the show notes. So the Gnome Foundation supports FlatHub with various things. working to contract someone to work on, or some ones to work on a short-term project around these kinds of things, around identity, being able to verify that,

yes, this app is published by the person who, or people or company that make the app, to the end of being able to accept payments to the app uploader, not to Flow Hub, which is something that's alleged in this post, to the app uploader. Because if you can make a vibrant place that individual developers, companies, organizations

can publish their own software straight to users, the mobile platforms have shown us that people use orders of magnitude more apps there than they do on their computers, both because they're available and because you can install them trivially and fearlessly. Hopefully this project can be made to happen and we're really excited to see it happen.

Yeah, that is some great insight, Will. Thank you so much for taking some time late in your evening to join us and discuss some of this. I feel like I've learned a lot. And I just wanted to say also thank you for taking the time to originally post your response, because that's really what kicked off the conversation between Wes, Brent, and myself and led to kicking this off on the show. So again, thank you for all your work there, Endless, and for joining us. Thanks very much for having me. It's been a pleasure. I'm

glad to have sparked some useful conversation. Linode.com slash unplugged. Go there to get $100 in 60-day credit on a new account, and you go there to support the show. Linode is cloud hosting done right under your control with 11 data centers worldwide. And they've been at this for 18 years, building the absolute best experience for running applications on Linux in the cloud. If you want to build something yourself or deploy one of their many one-click stacks, Linode has excellent options for you. And the performance, The performance is incredible.

They've been rolling out MVME PCIe storage. It's so blazing fast. And I just simply wouldn't host everything that Jupyter Broadcasting has built in the last couple of years on Linode, unless it was super fast. You know I'm a performance hound. Linode has screaming fast systems.

If you need fast CPUs, they've got AMD Epic processors. If you need super fast storage. And of course, they can always help you dial in the right price to performance. That is something they excel at. They're typically 30 to 50% cheaper than the major hypervisors out there. They just want to lock you into their crazy platform anyways. And there's no way they can support you like Linode can. Linode has the absolute best customer service in the business.

They have super fast rigs, great networking. They are their own ISP and a Linux culture that permeates throughout the company. I mean, that's why they started the company. So there's a lot of reasons to choose Linode. And I didn't even get into like the dashboard and the API and the one-click applications that are so nice to use. I mean, they're there. But have you thought like how great it would be just to have your own GitLab or Jitsi server in just a couple of clicks? So I just, I really don't need to say much more.

Because I think what puts it over the top is when you go grab that $100 and try it yourself. Because you get to try something rad and you get to support the show. It's a great opportunity to learn and a great opportunity to support the show. Linode.com slash unplugged. Go get that $100 in 60 day credit on a new account and support the show. Linode.com slash unplugged. Now, Chris, I think we have about two more criticisms that are worth mentioning. You want to pick it up there? Just a few more from the post.

One that's probably definitely worth talking about because it's one that end users are going to experience is it is complicated when it comes to specific software packages that require drivers, like NVIDIA video drivers, like the Steam package, because you could be on like Ubuntu i don't know 1804 and flatpak can't do anything about your kernel it's it's got to work with the host kernels system so it will then have to pull down a runtime that matches your specific kernel so if you can imagine on the backend that's a lot of work it's a lot of different runtimes and it it isn't an elegant solution but it feels like the kind of problem

you do solve for fragmentation. And yeah, it's a little bit technical on the backend, but as long as the end user experience remains consistent and the developer experience remains documented and workable, it actually seems like it's a pretty good compromise despite its complexity. But in all of this, I think we've kind of gotten a little carried away conflating a few technologies. A lot of things are getting thrown around like containers and sandboxing. And the implication might be in these conversations

that you have to have flat packs or snaps to have sandboxing. But that's not necessarily the case. And Neil, I think you wanted to expand on that. It's actually never really been the case that security, sandboxing, these portals and all that stuff are necessarily requiring you to change the way the application is built and distributed. Because the OBS Studio RPM in Fedora, for example, or Firefox in Fedora when running on Wayland activates those portals and does all the same things. Fedora when running on Wayland activates those portals and does all the same things.

Your general computing experience can be more consistent in this regard if application developers know how to code to these APIs, whether it's shipped as an RPM or a Flatpak, a Snap, a Debian package, or even just a bloody tarball that you download or an app image. And I don't think it's a good idea for us to conflate the two because that leaves a large gamut of applications that can benefit from these technologies when they cannot be distributed that way. Like system critical applications or stuff that should be part of the base OS so that you have a functional set of base software should also be able to take advantage of these things. There's no reason that you can't have the bubble wrap-based sandboxing

with the portals and all that stuff kick in for an RPM like you do for a flatpack. Neil, I'm curious if you have any insights into how Fedora is approaching flat packs and especially some of those namespace concerns that have been floating around. The way we're doing it right now is that the software centers prioritize Fedora sources by default

over third-party ones. So there's a priority level and ours is higher. And if you click the button to install something, it will prefer the Fedora source over, you know, in the third party one. If the identifiers are the same and the user hasn't changed any settings. The reason why this comes up actually is a fairly interesting one. In some cases, it's just straight up not a good idea to distribute or bundle the distribution of something from a third party, particularly when there are legal requirements or the upstream developer may have questionable character or things like that. For example, Audacity from earlier this year, the stuff that they're shipping has some of those things going on, but the Audacity, RPM, and Flatpak from Fedora don't. And I think it's important to recognize that there is actually a tradeoff to switching to a model where developers are the ones doing all of this distribution work themselves. And that is, you no longer have a reviewer or a counterweight. That may be fine. That may not be fine. It really

depends. Like a big part of in the Android ecosystem, you know, I know a lot of people were talking about this, about how, you know, people use apps more on Android and iOS and whatnot. But like in the Android ecosystem, there has historically been a problem of malware before, you know, Google started getting into it and started digging into all the things. And even with all that, it's still a problem because at the end of the day, developers have no check against them. There is nothing checking them. And yes, the Linux distribution model is certainly not perfect. And, you know, maybe a balance of the two is certainly better. And yes, the Linux distribution model is certainly not perfect. And, you know, maybe a balance of the two is certainly better. But like, let's not get carried away and throw out the baby with the bathwater. It's still valuable to have people being checks against

each other to make sure that we're all doing a good job here. Yeah, especially with security in mind. Wimpy, it looks like you have some thoughts. And I know you have some experience on the deduplication conversation here. Can you fill us in? Yeah, so on the proliferation of libraries and what have you, there are mechanisms that exist in Snaps and Flatpak that allow you to create reusable runtimes, which still means there is some duplication, but that duplication is one time only for a common runtime that exists across most applications that you're going to run on the desktop. But this is one of the sort of prices you have to pay for containerized applications, that it does come with that sort of bundling approach. applications, that it does come with that sort of bundling approach. And there are technologies that are growing in popularity that address some of this in order to trim out some of that duplication of files. And I'm not going to plug this too heavily, but where I work now,

we have an open source project called Docker Slim, which does precisely this using dynamic and static analysis, will pull out all of the cruft that exists in Docker and OCI containers. And there's no reason why those technologies couldn't be applied to the Linux desktop space. And speaking specifically about the Linux desktop, there are two very important points that people need to get on board with regarding contemporary application delivery on Linux, the Linux desktop. The first is, if you install, let's say, Google Chrome in the traditional way, you download the RPM or the DEB from the Google Chrome website and install it on your system, or the dev from the Google Chrome website and install it on your system, go and S-trace Google Chrome when it starts up and go and look at just how much grubbing around it does in your home

directory, trying to hoover up everything it can learn about you and your system. And you will start to appreciate the efforts because i know that the linux desktop users a huge percentage are very privacy orientated privacy conscious people the sandboxed applications prevent that kind of you know just pillaging of your information and data before you even go to a website and you get you know tracked and traced there so consider that the sandboxing does play a role in protecting your privacy you need to be thinking about that and the other is this all significant investment that happens in the linux ecosystem today is in container and virtualization technologies. It is a multi-billion

dollar industry. Desktop Linux cannot refuse to get on board with containers and VMs as part of of the OS landscape in the future. If we do that, we are paving a way towards obsolescence and irrelevance because all the significant development is in those technologies and desktop Linux users need to embrace this. It's an inevitable future. If we resist it, then it's over for us. You know, there is no future. So it's a matter of embracing the technology, the people that are competent and capable, improving and developing the support around those technologies. And you do a great job of putting it all into perspective. those technologies. And you do a great job of putting it all into perspective.

What we have to keep in mind is desktop Linux's bread gets buttered by the enterprise side. I mean, even like we've talked about recently here on the show, Pipewire is the direct result of businesses investing in automotive Linux. And what a lot of very clever developers have been very, very good at doing for a long time is leveraging the investments for enterprise Linux into desktop technologies. And that's what's happening here. And I think you make a great point, Wimpy. It's kind of like even if you wanted to make the argument, well, the other desktop operating systems don't have to do this. Well, they have a different business model. No, but they are. Mac OS is a hugely virtualized platform, and so is Windows these days.

It's just all transparent and hidden under the covers, and that's where we need to get to. Right, yeah. In fact, I broke this down on Coder Radio recently. The last three versions of macOS have, each version has just completely re-architected the file system directly underneath the user without even them noticing. To the point now where macOS is using an immutable file system for its primary OS. Right. And the applications folder is a hybrid folder of immutable applications that are grafted in with the user applications that are stored in a writable section of the APFS disk system. And when they reboot and stuff like that, they're checking the signature of a snapshot image, and they're booting into a snapshot. And then when they do updates, they're doing like the immutable switch over and reboot like like we've been talking about in desktop Linux now for years with some of these things. And they just incrementally rolled it out in the last three

releases. It's also important to note that for both Windows and Mac OS, they did it without changing the way developers deliver applications. That's a huge difference from how the Linux world is approaching it. And that's, I think, a big part of why people are resisting so hard. Because in the commercial world, it is recognized that you cannot screw with people when you are trying to improve the user experience. And that is something that I don't think enough people on the free software side actually understand.

We probably need to wrap it here because we have to wrap up at some point. But the other thing that's been interesting is I'm really getting a better sense of what the future looks like for Flathub. And I think I'm good with it. I think that's actually going to be a good thing. If it's some kind of paying mechanism that I'm comfortable with, assuming that it's something that's nice and clean and doesn't feel gross, I think that's going to be a great direction for FlatHub. I mean, something we've kind of talked about needing more widely in our ecosystem, right? And I mean, so far there's been various attempts, but none of them are necessarily widely successful. Yeah, yeah. I mean, I think the elementary OS app center has proven it out on a certain scale.

And I think FlatHub would be the next scale up. And it's the thing that we've always looked for. Even back when we had quite the software store on Ubuntu, we really always wanted something that was cross distro. And a few different places, even the Lindos folks took a crack at that, but nothing quite like this. And part of it is because Flatpak is solving those fundamental issues. And then Flathub is just a front end on top of getting access to this stuff and making it simple for the end user. But with all of that, I think we'd just like to leave it to the audience. So if you'd like to give us your thoughts or your opinions on this stuff,

or perhaps you think we've missed something, please do let us know. Sometimes the pushback emails are our absolute favorite emails to respond to. So go to linuxunplugged.com slash contact and share your thoughts. Now we did a episode, Linux Unplugged 431, that's three episodes ago on command line love, which was a bit of an homage to the Ubuntu podcast segment. And we keep getting mail from that episode. It's just incredible. So here are three from that. Kostas wrote in and he says, as a programmer, I would fight tooth and nail before anyone took my command line away from me. That said, I'm familiar with two situations where the command line is a no-go.

Any device without a physical keyboard at hand, mobile phones, tablets, integrated gaming PCs, think Steam Deck or its myriad predecessors, including my beloved One X Player. These devices rely on software keyboards, which are ill-equipped for regular usage of the command line. I would have to totally agree. And Chris, maybe that device you teased in the pre-show is maybe solving that for you. He continues, the lack of English language skills is the other situation. Let's take my parents as an example. Greek retirees with a past end-of-life iMac that I'm about to install Linux on. My father was coding on a ZX Spectrum in his 20s and relied on books translated to Greek to get him going. I doubt he would be able to deal with man pages written in

English to get stuff done. As far as I know, and correct me if I'm wrong, command line interfaces don't get translated as much as graphical ones. I believe that we can find a lot of people in communities where mobile phones are their primary computation device and English proficiency is low. The command line is cool and powerful, but not always an option. Now, I was curious with that. Does anyone use translations of the command line on a regular basis, maybe in the Mumble room? Yeah, it's commonplace. Some people don't know this, but one of the major innovations from GNU was adding first-class support for internationalization and localization to the command line. It didn't really exist in the way that we have it today in Linux.

It didn't exist before then. One of the reasons why the GNU core utils is so complex, I know a lot of people say use BusyBox or like or some of the other ones because they're simpler, whatever, less bloat. A lot of the bloat actually comes from the

fact that they made internationalization a first class aspect of their user space. And that has actually carried forward to most of the important command line tools like

your package managers, your monitoring utilities, a lot of those things tend, like even Docker has translations. Podman too, like it's a fairly common thing. Maybe not man pages necessarily because the man page translation infrastructure kind of sucks.

But even with that, go look at your file system sometime. There's actually a good chunk of translated man pages. Pycrash, I wanted to give you a chance to jump in because I think you've been involved with some of these translations. I speak Spanish and German and I provided translation for a couple of distributions and open source projects. And actually get translated i mean the output from the command line one of the biggest problems i had when i started using testing is i needed to set my command line to please do the output in english because most developers when they

put in english when they look at the back So a lot of the command line utilities actually are doing output in your language. The only thing that is not translated, it's usually the flags, for example, are for recursive or stuff like that. But otherwise, it's actually, the output is actually really good in non-English languages.

Okay, that makes me feel a little better. I wasn't quite, this is why it's so great to have an open Mumble room because I just really wasn't quite sure what the answer was to that. I felt like man pages, that made sense because there's so many alternatives online now. Right, it's an area we're kind of blind to.

Yeah, it is good to hear there's a lot of work though getting done there. Listener Kevin quickly mentioned and remind me, which I forgot, that in Brunch with Brent with Stuart Langridge, he mentioned that search engines are in essence a command line prompt with an understanding by the user that no mistake they make can harm their system. So check that out. We'll leave a link in the show notes. Mind blown. Mind blown, right? It's a command line that average users have

just adapted to. They've gotten used to. For a little piece of maybe some spicy mail that we got, Forrest Lake writes in, Hey team, just listen to your command line love episode. I hate to say it, but that's the biggest bunch of elitist BS that I've ever heard. You, the show and guests always talk about productivity and how shaving off time can have such a big impact on your day. But we expect people to waste time jumping on forums, asking the hyper-intelligent gurus how to do things on the command line. That is a waste of precious time and very unproductive, as the general response for the elite is Google it. I'm not here to give you answers. You need to learn young Padawan. I've been a Linux user since the 90s and will always look for a GUI way of doing things as the forums provide no answers for people without receiving some attitude.

If there was a GUI solution for every problem just like Windows, then the year of the Linux desktop would have been in the late 90s or 2000s. I guess the question is, do you want Linux to be omnipresent or an OS distro for those who camp in the forums? That is a very strong opinion. I have used Linux since the 90s, and I could probably count on one hand how many times I've actually gotten like an STFU, go Google noob kind of response. It did happen more often in the early days in IRC, especially when you come like charging into a room

and there's like a conversation. They're all in the middle of like some heated debate for like the last half hour and you pop in there demanding an answer. Yeah. Sometimes you get told to, you know, take a hike that used to happen more often, but now we have so many platforms that are like specifically set up to come ask your question and get an answer. So the context has been set. The table has been set for you to come and ask your question. Then I find that to be a lot less of an occurrence. And then when you participate in more niche down communities,

like the podcast communities or a distro specific community or a project specific community, you find even nicer people there because it's even a smaller group of people that are generally like-minded because they're organized around something. And so it's pretty common in those groups to have like people around that are like sort of the unofficial welcoming committee that are generally very nice on outreach. I really don't find this to be an issue and I'm just kind of using nearly 30 years of experience to derive that opinion. So from that, it's your experience, but that's not everyone's experience, right?

That's what I, that's what my conclusion is from that. I think the other thing I just wanted to point out is that the response of how people talk about command line tools and the functionality of command line tools, those are two different things. And I'm not saying command line tool for every situation, but how people tell you how to use them and what they are capable of doing are two separate issues. Right. And of course there's different modes here, right? You mentioned productivity and the feedback, and yeah, okay, I mean, if you're having to learn additional tools, that might slow you down now, but you also have to think about the long term, and some of the reasons we love the command line is because if you do have stuff to get done,

it can often be one of the most efficient ways to do it. Command line tools are just software in the same that graphical applications are software, and there are graphical applications are software. And there are graphical applications that are complex to use, like DaVinci Resolve. And I had to spend hours watching videos and reading documentation to even scratch the surface of what's possible with that software. So I think it's fine that if you are doing something complicated, you might need to seek some resources, reference material, tutorials, user group in order to learn how to manipulate that software to do what you need to do. And I don't think it's strictly the preserve of command line applications. Very well put.

of command line applications. Very well put. I mean, I've seen some really complex enterprise applications that, you know, you have to send end users to training sessions just so they can master 10% of its functionality.

And when it comes to, you know, supportability and whatnot, like one of the positives and negatives, right, is the community support. But part of that is self-inflicted. We just don't have the, you know, outside of SUSE and I think also Canonical, I don't know of anyone that directly offers desktop Linux support anymore. And you kind of have to go with what's

out there. And maybe in the future, if the desktop market share, desktop Linux market share grows a little more, we'll start seeing more and more of those supportability options show back up again like they were in the 90s when everything when everyone was like thinking that it was going to take over the world immediately. But right now we just don't have it. You know, and I've thought about this since we've talked about it on the show because we have gotten a lot of feedback. And I think what I really believe when it comes to this command line tools or over graphical tools is I think if you're going to use Linux as a system that's important to you, it's worth knowing some of the fundamental commands, like how to change directory, how to list the contents, how to look at processes, maybe how to read your logs, maybe how to stop or start a service, maybe how to reboot from the command line in case you get stuck, you know, you could drop to a terminal and reboot the thing. Maybe even if I could go as far as to say, maybe even kind of a rough understanding of grub or whatever your bootloader is. You know, those, I think, are things that are worth investing in that, you know, you

spend four to six hours learning that stuff. You know, maybe you even spend, I don't know, 48 hours, but it'll pay dividends for 15, 20 years. Maybe not Grub. Well, maybe actually. I mean, hell, I still see systems with Lilo, so. That's a scary thought. I know. I saw a systems with Lilo, so. That's a scary thought. I know.

I saw a vendor system running Linux 2 recently. No. Yeah, with an Apache, an old version of Apache. Oh, my God. So, you know, it's just like, and, you know, the commands work, right? Got on that box, figured out how much disk space was available. It was valuable still. It's a very old system.

And so some of that stuff I think is worth learning. But at the same time, if there's an application like FlatSeal that's going to give you a nice graphical overview of what permissions your different FlatPaks have, I have at it. I think that's a great use of a graphical application. No kidding, right? There's just stuff that really makes sense to have in a GUI

and there's other stuff that works nicely in the command line. We don't have to, as you often say, Chris, you know, you invent a new thing, the old stuff doesn't go away. Like these kind of coexist together and probably will for a long time. Right.

Also, I think this has been sparked to some extent from, you know, Linus's comments during his Linux challenge. You know, he was very critical of was very critical of the Linux command line as we have to get away from it. But actually, the Linux command line is one of the fundamental things that defines Linux. If we do away with that, then what does Linux become? Its differentiator is gone. Its power tool goes away. The thing that makes Linux Linux no longer exists.

So I don't think we should throw it away or give it up. I think we should embrace it. And we can have both. We can have fantastic command line utility and also great graphical applications. We don't need to choose one over the other. Yeah. I feel like we're really starting to see that too

with things like FWPTI, where you've got some command line components and some libraries, and then you're seeing different graphical tools being built. System76 has one.

GNOME has one. Canonical's building one based on Flutter. But it's all using the same stuff under the hood. And if you wanted to, you could do those same firmware updates from the command line. And that's kind of, I think, what we have figured out over time and the kind of thing we're getting better at building. I think the aspect of what

most people have an issue with in terms of the command line is that there's a messaging problem. You have the problem of some people in the community talking about how the command line is easy. And while it is efficient, 100% agreed there, you can do a lot of things faster in there. Well, I wouldn't say FFmpeg or anything like that. But there are certain levels of complexity that the GUIs offer, like Wimpy said. But I think it's more of the messaging that people often say it's easy or simple. And when you're talking about people who just get started, there's not really a fair association to easy or simple. But what they're what they think is easy and what they think is simple is going to be different than a

lot of people who use those terms. That's a good point. Hello, Michael. Good to see you. I think what really kind of bears your point out is I think of it in some ways, FFmpeg is such a great example, as simpler than the GUI. Because I've got a terminal command. I've got Phish installed. I type FF. And like the whole thing just auto-completes. I hit tab. I change the file names and hit enter.

And for me, that's simpler than launching a GUI. You have Phish to help you. The poor soul who's working with the distro default of Bash or, God forbid, BusyBoxSH or something, got nothing. They got nothing. No, it's true. And if you do FFPlay or FFMPEG or FFConvert, TAC-TAC-HELP, you're worse off than you were before you started. No, it's absolutely true. I was really just making the joke that, you know, if you've been using something for a while and you get comfortable with it,

it obviously is the easier. That's the best part about command line tools, is it's very easy to develop a rhythm for how to use things. And that's where we keep coming back to this, you know, to what extent are we embracing what we expect new users to know and how much do we expect them to embrace the new platform they're coming to and learn the tricks of the trade there? And it seems like it's often a balance. Where is that line?

Yeah, exactly. Okay, well, we got to wrap it up there. We could keep going all day. But listen, the change is in the air. And we'd love to have you show up on a Tuesday while we're still here. See you next week. Same bad time, same bad station. I know, I know.

But come join us on a Tuesday. Hang out with us. And if you're around on a Sunday, our virtual lugs getting together at noon Pacific, having a good old time talking Linux open source projects and things they've been working on. And all kinds of folks from around the community pop in there and have a good time.

It's nice. And then your mumble's ready to go for the show. And then in the future, when the show's on Sunday, well, you'll know where to find us. If you're in the industry, be sure you're not missing out. Go get Linux Action News, linuxactionnews.com. Don't miss an episode. Join us back here Tuesday at noon Pacific, 3 p.m. Eastern at jblive.tv.

linuxunplugged.com slash 434. See you next Tuesday! I don't know how we're going to title this one, but let's give it a shot. JBtitles.com. Let's go pick something. We need your help. We really do. We do. We do.

We do. Michael, don't worry. Don't worry. The good news is we're going to be live on Sundays, but we're going to be noon, and you guys are usually done by then. That is not why I joined, but also kind of partly why I joined. Wait, what? I'm just saying because I can't join anymore.

I know. I know. There is that. Noon what? Pacific'm just saying, cause I can't join anymore. I know. I know there is that noon. What Pacific? Okay. Yeah. Because you're one Eastern, which is, oh yeah. Yeah. You're fine. Yeah. Yeah. It's not our first choice. I actually really liked being live on Tuesday because, uh, often, you know, guests like will can join us and stuff like that, but we, you know, we can also record off air and things like that, but there's just a series of changes going on, and we've got to make a few adjustments, and so that's one of them. There's a lot of positives to it, too. It also means that more often than not, Wes and I will be in studio together.

Several times it will be Wes, Brent, and I in studio together, which is going to be really nice. I always really enjoy the shows where we can all be in the same room. So that's going to be something that happens more often. And we can do more meetups and things like that on Sundays and whatnot. So there's a lot of other nice positives to it as well. But changes are coming. And I'm both excited and anxious about new shows and all of that.

So let's not stress about it. And let's just title this thing. Let's just get it figured out. We can do this.