Flathub to verify first-party apps and allow developers to collect monies

Quoting: Samsai

Quoting: STiATIsn't that a risk and circumvents the whole idea? I mean.. you have profile.d which gets executed and could do all kind of stuff there. Even modifying the ostree...

Who's going to modify it though? You'd still need root and none of the recommended ways to install software grant root access to any installation procedure. You would have to pipe some script off the net into sudo bash and at that point the script could just dd your drive full of garbage anyway. The immutability is not primarily a security feature but a stability feature: it ensures atomic and transactional system updates so that the software is always in a consistent state.

Point taken, I still think there will need to be technology innovations or adoptions to make it really "immutable" and you can automatically mount hard drives without actually every having to touch any root file system. Or generally making really the whole root file system read only.

But I take your point about the applications, which isn't actually true with flatpak though, since they do have file access and you only need one bug there to exploit it. And as of the current state, there is no difference in flatpaks <where> in the FS they potentially could access, if they can get privileged out of the container - they are.

As a stability feature - yes, that's pretty much clear that's a good feature I'm certainly interested in. It's basically how I do treat my main system (despite driver installs - this nvidia driver :D .. but that could be installed into ostree too).

I get where they're going. Maybe not there yet 100 %, but the distinction of making it a stable base and having apps work independently of the base makes sense. I actually like the approach. Maybe too early for me to switch there yet though, I'm really not prepared to do development containers for everything I do :D.


Last edited by STiAT on 25 January 2022 at 11:28 pm UTC

To be honest, there is no such thing as a "perfect" distro that does everything "right".

Why?

Because what is right for one person, is the exact opposite of what someone else wants from their distro.

But that's the beauty of Linux see, we can use the distro that fits our needs best, we are not tied to using a specific one, so if it doesn't fit us then we can move on.

With that said, I always say that Arch has great documentation and I would highly recommend anyone who wishes to learn more about Linux and how it really works to use it for a while.

It's a great distro imo, however as for "stable" - I wouldn't say so. System breaking changes may occur with the only notification being the blog on the Arch website - for avid Arch fans this is no big deal, but for a new Linux user they wouldn't understand why this happens.

While in my opinion stable releases are better than rolling for a new user (stable package versions, less instant changes etc etc) there are rolling distros that even a new user could find usable, for example OpenSUSE Tumbleweed.

Tumbleweed can be installed via GUI, uses btrfs by default with snapshots fully enabled - so if updates break it, rolling back to a working system can be done in less than 5 minutes even for a newbie. Heck, even if you bust the configuration yourself you can rollback in less than 5 minutes.

Now that is what I call new user friendly. If we break out of the rolling releases, there's always OpenSUSE Leap that also has snapshots, failing that new users may find Mint comfortable.

Generally for new users, I aim to give them a comfortable experience that won't leave them needing to run a command line or getting confused, so my go-to is usually Mint for a complete newbie.

Arch would probably have most new users running away screaming about how Linux is still all terminal based and old fashioned that doesn't work. Rightfully so, Arch is not aimed at complete novices, it's aimed at people that want more fine grained control over their system, people who like to tinker and those who want to learn more about the technical side of Linux.

Now, me personally I always use whatever fits - I stopped the whole "distro fanboy" thing a number of years ago - although Fedora will always hold a special place in my heart .

I use a combination of RHEL, Debian, Fedora, Arch and OpenSUSE systems - using each system where they fit best for the task at hand.

Anyway, it's also why I'm not a big fan of Flatpak, if I'm using RHEL for example - I don't want a nightly build of apache that I need to update everyday, I want a version I can install and leave running that's stable and secure, hence RHEL and proper SELinux policies - For example, I only just rebooted one RHEL server that had over 4 months uptime, it was secure though thanks to kernel kpatch's which address security vulns (live patching kernel without full reboot - great since a reboot would take around ~5 minutes due to slow bios checks) and system services just being rebooted with systemctl, thus all up to date and working. This is an example of a strength of RHEL.

But as I wrote before, each distro has their strengths and advantages - that's why we get to pick which ones work for us best.

We should never get to the point of depending on Flatpak, because it's usage case will not fit everybody and their individual setups. Linux's ability to adapt and fit different users needs is one of it's biggest strengths, by taking that away by requiring users to always use a Flatpak version is very dangerous and will make a lot of people angry.

Quoting: Purple Library GuyThat video says "Flatpak is the future". Well, I'm willing to believe Flatpak is (the future of proprietary software on Linux). I don't think it would be such a good idea for every damn application and utility, the open source ones, the main Linux software ecosystem, to be using Flatpak instead of normal package management.

Why not Open Source apps? I use Kdenlive Flatpak and it's very much better than the RPM package I could get (when I was using Fedora Workstation) from RPMFusion, and Kdenlive Flatpak is an official compilation, so if it fails I can report directly to Kdenlive developers.

Many Linux users don't want solutions, they want patches that mitigates things but don't solve anything, because if you don't use Linux typing one thousand of commands per day because of mediocre software available for Linux, you aren't a true Linux user.

Quoting: EduardoMedina

Quoting: Purple Library GuyThat video says "Flatpak is the future". Well, I'm willing to believe Flatpak is (the future of proprietary software on Linux). I don't think it would be such a good idea for every damn application and utility, the open source ones, the main Linux software ecosystem, to be using Flatpak instead of normal package management.

Why not Open Source apps? I use Kdenlive Flatpak and it's very much better than the RPM package I could get (when I was using Fedora Workstation) from RPMFusion, and Kdenlive Flatpak is an official compilation, so if it fails I can report directly to Kdenlive developers.

Many Linux users don't want solutions, they want patches that mitigates things but don't solve anything, because if you don't use Linux typing one thousand of commands per day because of mediocre software available for Linux, you aren't a true Linux user.

I use Mint. I never touch a command line, I can't remember a package ever breaking. Flatpak solves a problem I don't have, by introducing a bunch of bloat. For as long as open source stuff is being maintained, and depends on libraries that are fairly current, normal packaging should be fine.

Closed stuff, on the other hand, typically doesn't get maintained for nearly as long as it may be used. A solution that bundles the libraries it needs with it is going to come in handy. If my old Loki copy of Alpha Centauri had been done as a Flatpak, maybe I could still play it today without masses of workarounds.

As long as we're talking about the virtues and follies of Arch...

I use Arch because it's simple. I started with Ubuntu, which I used until I broke it. And then I tried Manjaro, which always had problems. And then I tried Arch, and it has always "just worked". There are next to no configuration changes made for any packages, and because I make all the configuration changes, I know how things are set up. I don't have to deal with Flatpak/Snap/AppImage because I can just pull any package I want (including the proprietary) from the AUR.

I maintain a single Pop!_OS computer today, while everything else uses Arch, and man, things are just much harder for me to deal with. Doesn't help that the core software used is so abnormal. I don't even know how to build software from source and manage it with apt—it seems possible, but it also seems beyond me. Arch Linux is what I choose for a desktop computer because I don't want any of the hassle that comes with other distributions.

I often want obscure or unusual packages that most distributions don't package anyhow, so I'd still be building from source (or doing something less manageable) on another distribution. The AUR just makes this edge case super easy for me. It's a frictionless experience for me.

Now, as I said, on another distribution without this flexibility, Flatpak/AppImages could certainly address this problem. But that's only if they're built correctly. And if the Audacity maintainers can't figure it out, I worry how everyone else is doing. It's a problem (I hope) will be solved in time, but I keep hearing about Steam Flatpak issues, OBS Flatpak issues, etc. And the most important problem—in my eyes—they solve is maintaining old software that simply isn't developed anymore but is still useful to people. An ordinary binary from 10 years ago probably wouldn't work, but an AppImage probably would. Great for both proprietary and abandoned free software (so long as developers take advantage of it).

Maybe I just don't know how to use any other distribution except Arch. I'm willing to accept that.


Last edited by pleasereadthemanual on 28 January 2022 at 12:57 pm UTC

I'm an Arch user... have been for at least a decade. I've only really dabbled in Flatpak itself, but, honestly... given we're obviously all Linux gamers... Flatpak (or some iteration of it) is one of the core changes to Linux that will help break Microsoft. The simple reasoning behind this is, the biggest game developer complaint for Linux is "it's fractured". Flatpak (though not perfect) goes a long way to homogenize the distributions in a way that will make it easier for developers to develop their games for Linux and distribute them for Linux and not a specific distro. Furthermore, if we want more games, we need more players, and those players still find Linux complicated/confusing. While Flatpak will not automatically solve that problem outright, given that Flatpak (in theory) works for all Linux distros, then users will have a more reasonable expectation that if the package/game is on Flatpak it'll probably work on there distro. These are huge deals if we want more games. To get those games we need to make the road easier for the developer and the gamer.

Honestly, I don't really see Flatpak as being that drastically different than Docker, and docker has been a huge boon in the network space.

In the end, I doubt the traditional package manager is going away. At worst you'll see a duality in that Flatpak will be automatically installed along side your distro's native package manager and there'll be a toggle for which source if your default package source. Even more likely, the command line distro tools will remain separate, for the CL-jockies.

Quoting: pleasereadthemanualAs long as we're talking about the virtues and follies of Arch...

I use Arch because it's simple. I started with Ubuntu, which I used until I broke it. And then I tried Manjaro, which always had problems. And then I tried Arch, and it has always "just worked". There are next to no configuration changes made for any packages, and because I make all the configuration changes, I know how things are set up. I don't have to deal with Flatpak/Snap/AppImage because I can just pull any package I want (including the proprietary) from the AUR.

I maintain a single Pop!_OS computer today, while everything else uses Arch, and man, things are just much harder for me to deal with. Doesn't help that the core software used is so abnormal. I don't even know how to build software from source and manage it with apt—it seems possible, but it also seems beyond me. Arch Linux is what I choose for a desktop computer because I don't want any of the hassle that comes with other distributions.

I often want obscure or unusual packages that most distributions don't package anyhow, so I'd still be building from source (or doing something less manageable) on another distribution. The AUR just makes this edge case super easy for me. It's a frictionless experience for me.

Now, as I said, on another distribution without this flexibility, Flatpak/AppImages could certainly address this problem. But that's only if they're built correctly. And if the Audacity maintainers can't figure it out, I worry how everyone else is doing. It's a problem (I hope) will be solved in time, but I keep hearing about Steam Flatpak issues, OBS Flatpak issues, etc. And the most important problem—in my eyes—they solve is maintaining old software that simply isn't developed anymore but is still useful to people. An ordinary binary from 10 years ago probably wouldn't work, but an AppImage probably would. Great for both proprietary and abandoned free software (so long as developers take advantage of it).

Maybe I just don't know how to use any other distribution except Arch. I'm willing to accept that.

 
apt source <package name>
or if you want to download and build, add -b.

If it's not in the repos, most source trees have a 'debian' folder, so you should be able to build it fairly easily on any deb based distribution. If it doesn't have a Debian folder, then there are now tools to try to automate that. Though I haven't needed to use those, so not sure exactly how they work.

PKGBUILDs are very simple to make and really are one of the shining things about Arch. Documentation is the other one. The only other free operating system that has comparable documentation would be FreeBSD, in my experience.

Quoting: slaapliedje

Quoting: pleasereadthemanualAs long as we're talking about the virtues and follies of Arch...

I use Arch because it's simple. I started with Ubuntu, which I used until I broke it. And then I tried Manjaro, which always had problems. And then I tried Arch, and it has always "just worked". There are next to no configuration changes made for any packages, and because I make all the configuration changes, I know how things are set up. I don't have to deal with Flatpak/Snap/AppImage because I can just pull any package I want (including the proprietary) from the AUR.

I maintain a single Pop!_OS computer today, while everything else uses Arch, and man, things are just much harder for me to deal with. Doesn't help that the core software used is so abnormal. I don't even know how to build software from source and manage it with apt—it seems possible, but it also seems beyond me. Arch Linux is what I choose for a desktop computer because I don't want any of the hassle that comes with other distributions.

I often want obscure or unusual packages that most distributions don't package anyhow, so I'd still be building from source (or doing something less manageable) on another distribution. The AUR just makes this edge case super easy for me. It's a frictionless experience for me.

Now, as I said, on another distribution without this flexibility, Flatpak/AppImages could certainly address this problem. But that's only if they're built correctly. And if the Audacity maintainers can't figure it out, I worry how everyone else is doing. It's a problem (I hope) will be solved in time, but I keep hearing about Steam Flatpak issues, OBS Flatpak issues, etc. And the most important problem—in my eyes—they solve is maintaining old software that simply isn't developed anymore but is still useful to people. An ordinary binary from 10 years ago probably wouldn't work, but an AppImage probably would. Great for both proprietary and abandoned free software (so long as developers take advantage of it).

Maybe I just don't know how to use any other distribution except Arch. I'm willing to accept that.

 
apt source <package name>
or if you want to download and build, add -b.

If it's not in the repos, most source trees have a 'debian' folder, so you should be able to build it fairly easily on any deb based distribution. If it doesn't have a Debian folder, then there are now tools to try to automate that. Though I haven't needed to use those, so not sure exactly how they work.

PKGBUILDs are very simple to make and really are one of the shining things about Arch. Documentation is the other one. The only other free operating system that has comparable documentation would be FreeBSD, in my experience.

The package I was trying to build from source was yt-dlp about half a year ago. I spent about an hour looking around, but there didn't seem to be a clear-cut way to do it, so I inevitably just gave up and built it from source "the normal way". I'm not sure about the other reasons for building from source, but I'm so used to using Pacman to manage packages that I build with `makepkg` because it's an easy way to keep track of packages and cleanly uninstall them.

I made the mistake of using pip to install protonvpn a year ago...never again. Using pip is a surefire way to create an unmanageable mess of packages that Pacman inevitably gets confused with.

The documentation is really a goldmine. I always find myself there, learning new things about software that often the upstream developers haven't bothered to document. I've heard about FreeBSD, but haven't had the occasion to look into it.