You NEED Flatpaks (Here's Why!) | Trafotin
Вставка
- Опубліковано 25 чер 2024
- I hate dependency hell, but we have an answer! I hate versioning, but we have an answer! I hate Linux security, but we (sort of) have an answer? Just fix Lutris...
Website: trafotin.com
Donate:
✨ Patreon: / trafotin
💰 Liberapay: liberapay.org/trafotin
Connect with us:
🐦 Twitter: / trafotin
📒 Odysee: odysee.com/@Trafotin:4?r=H3rc...
🐘 Mastodon: vt.social/@trafotin
📁 Gitlab: gitlab.com/trafotin
🪙 Crypto:
XMR: 84ZpcYxjfkT7uFGXgmi2jH2wyhUBMx8hGBJ3sAp478rKSShMAJHR3DhVVPSwCAskReRBPifzpA5Vu7HPpzAxHUux3SFS4bh
🎵BGM: [フリーBGM DOVA-SYNDROME / FREE BGM DOVA-SYNDROME]
dova-s.jp/
👋 Outro: Khaim - Neon Lamp
khaimmusic.com
👇 Sauce:
• Let's try Fedora Silve...
• Joanna Rutkowska, Next...
media.ccc.de/v/ASG2018-181-fl...
learn.microsoft.com/en-us/win...
support.apple.com/guide/secur...
• AppArmor Crash Course
ieeexplore.ieee.org/document/...
popey.com/blog/2021/05/disabl...
Chapters:
0:00 The Flatpak Revolution
3:46 Why not Snaps or AppImages?
8:42 Easier is better
10:53 Outro - Наука та технологія
I don't think your anime character gives some value but the topic definitely does. Keep up the good work!!
Silly advancement. You'll have to pry my dependency hell from my cold, dead hands. In all seriousness, Flatpak is great and there is definitely a place for it, but for many apps I do like them native from repos. I turn to Flatpak to solve dependency issues when they happen or repo unavailability issues.
I only use flatpaks already, except for one 1 app
Trafotin: "You *NEED* Flatpaks"
Me: "Well, after carefully examining that, NO!"
There are 14 different ways of downloading applications.
We need on standard they can all use!
There are now 15 different ways of downloading applications
instant classic xkcd
It still comes down to many of us running a mix of flatpaks, snaps, appimages, and deb pkgs because those were the path of least resistance to getting and installing an app that we really want and that works on our systems.
Flatpaks work without system d
Silverblue, Kinoite and MicroOS to the rescue!!
5:50 You're actually wrong about that, it's the other way around. AppImages (and snaps) are both compressed with squashFS, it's AppDir (which the compressed AppImage is derived from) that is uncompressed. Flatpaks actually do not compress dependencies at all, however it does share dependencies where the dependencies are duplicates and using Flatpak specific runtimes which is how it hopefully helps save space while catering to the exact dependency needs of each installed application. In the scheme of things if you installed lots of programs the Flatpaks would probably win out in disk size due to dependency sharing, especially if the programs are from similar project origins (KDE apps for example), but on a smaller scale AppImages would likely have a smaller footprint.
Just wish flatpaks matched my systems themes..
There is some piece of software that is only available through the AUR, compiling it yourself and perhaps some odd repo that you can't use, that I would love to make a flatpak of.
Problem is I don't know how, or if i even am allowed to
2:53, I see a few features missing from that diagram, dunno if flatpak addresses them but I'm definitely addressing them in the library & app combo I'm making.
1. Shared libraries within the flatpak ecosystem (so not the native shared libraries)
2. Access to the native shared libraries
3. Multiple versions of apps & libraries (system wise so linux x86 vs windows x86 vs linux x64 vs etc)
3. Support of OTG containers, for example I'm designing mine to look for an OTG_HOME variable for which it would then look for ".paw" inside that directory, that would then be prepended to the PATH variable so that anything designed for the paw ecosystem is expected to work on any system paw is compiled for, no excuses, paw's lib/s will provide the needed layer to query what is available in a portable way (assuming you need to query anything at all), the intent of paw is change the programming paradigm from "native 1st then cross-platform" to "cross-platform 1st then native"
I'm designing paw with the mindset that there should be 4 types path with at least 2 subsets that should be prefixed to the PATH variable to search for apps & libraries in
1. System wide path (SHARED_HOME)
2. User wide path (HOME)
3. On the go directory (OTG_DIR)
4. Development directory (TOP_DIR)
As for the subsets
1. Main/Release/Public (required, prefixed before the below)
2. Debug (cannot be prefixed with timed)
3. Timed (cannot be prefixed with debug)
I don't like that a lot of libraries find the need to distinguish what version they are by inserting stuff like "dbg" into their names, should be jut one name and have the right path prefixed to the normal path, same with system libraries, should have a separate path for debug & timed libraries so that if a debug/timed library is not provided then the main library etc is used instead, this would be particularly useful if want to debug the entire code chain instead of just the app/lib to see exactly what went wrong so that can then search the upper code chain for the cause more easily.
I'm also considering a host mode for the app part of paw's lib/app pair, where it uses the native equiv of dlopen() instead of the native equiv of execve() (may have mis-remembered the name there) and then searches that library for it's own main() function and hands over to that instead, since the paw environment setup & destruction would then be fully handled by the app the library can remove the related calls from it's code, being just a library means a bunch of makefile code can be removed too
You know what's easier?
sudo pacman -S packagename
I will use flatpaks if the default repo package has a problem.
Why "-S", to a new user "flatpak install" is easier and way more descriptive.
@@LaughingOrange
You have a point. On my system, it's is even easier.
I have alias i='sudo pacman -S' in my .bashrc file, so to install anything via pacman, I just type 'i packagename'
Also, Garuda does not lack any apps I need that flatpaks offer. If I was using a distro with fewer app choices, I would consider using flatpaks.
IS there a dock available as flatpak?? I can't find one.
I LOVE flatpak.... takes longer to install them for me-- (download speed here is only 4 meg right now-- although fiber optics is coming soon- cable on the pole ready to be hooked up).. but I DO love flatpaks.. DONT like snaps-- too many issues- at least the ones I've tried- ALL of them..
This is why fedora is the only option at the moment.
I use fedora silverblue so I basically HAVE to use flatpaks or distrobox.
Good video.
Excellent ad for flatpak.
You nailed everything by supposing most of the facts!
Now do more videos that are convincing ppl that Linux is the future by going around all this carnivore comunity.
Great content
the anime is a vampire!
I may not go outside, but I'm not a vampire. My eyes aren't even red.
The Brave flatpak needs some help.
What is the problem with the flatpak version of Brave?
@luizfernandes1149 If you have more than one profile opened in separate windows, it becomes unresponsive. Also you can set it as the default browser, but it will always ask you again when you start it up. Sometimes you'll get logged out of your accounts when you get an update as well.
Chromium is complicated because I have read from some sources online (GrapheneOS's site for example) Flatpak's sandbox compromises the default sandbox of Chromium, which is more substantial on Linux, yet there are also people who use Microsoft Edge or Brave as Flatpak because of the Flatpak sandbox. Not sure what to believe here, but it is an unofficial package and unless you're distro isn't officially supported, just use their native package.
@@Trafotin I normally do, but I run Kinoite on my work machine. I'll mostly likely end up distroboxing it.
My only issue with Flatpak is that if you install something as System and it has dependencies, but later you install another package that has the same dependency but as User, Flatpak will install this dependency twice, as System and as User, even though they are the same.
This is because some applications need custom runtimes to do what they need to do. This is why there are incremental versions of GTK, QT, Nvidia, etc. If they didn't, applications would break, and normal Linux systems are arguably more inflexible and just as messy in the same way.
@@Trafotin can you counter flatpaks hunger for ssd space with deduplication, is btrfs and flatpak the dreamdeam then?
i.e. all flatpak apps have there personal libaries but the the same blocks only exist only one time due to btrfs dedublication
Yes, flatpaks will take up more diskspace, but these days storage options are not that expensive. Slightly slower launch times and more storage space is the trade-off for occasional dependancy-hell situations.
@@huhu9084 flatpak also deduplicates by default with ostree but not at the same level as btrfs
Kool
Hello! UwU
ff2mpv doesnt work in librewolf flatapk :(
I don't know this extension, but if you try "flatpak-spawn -host;/usr/bin/mpv", it might work, but this is already a workaround.
Flatpak is a future! A future in which the calculator weighs 300 megabytes and requires 3 gigabytes of runtimes.
Flatpak is the present
The calculator isn't 300MB. Things like Gnome Software may display it that way, but that's including the Gnome Runtime, which is shared among apps. Gnome Calculator is 4MB.
AppImage is better.
Sandboxing is how you end up with macOS, iOS, iPadOS, or Windows 10 S. Linux is supposed to be the opposite. Freedom! No walled gardens, no centralized systems! AppImages get this right. You can get apps anywhere, no need to wait for a distro to publish it (or trust whoever is managing the distro's repo). And apps can easily be modded and interacted with by other apps!
If this is "the future of Linux", then I'd rather use Windows, for the freedom it will provide over Linux! I already use my own self-made "AppImages" on Windows lol.
And you are on about AppImages being like macOS, when in fact flatpaks are way closer. Sandboxing is on both macOS and flatpak, but not AppImage. A centralized store is on both macOS and flatpak, but not AppImage!
App Image is the Most Powerfull Linux Tool....
At this time no support for firefox-nightly builds.
There's an unofficial community Flatpak of Nightly by the Mozilla Wiki. It's a Czech website, but I can't link it here.
I don't get it, what's wrong with using native packages? Sure, pretty good for servers, but them being pushed for desktop use is ridiculous
nix
no thanks
Not pushing back, genuinely wanna understand: you landed on “trusted repository (instead of random websites), ease of use, and security.” As a long-time Debian user, that sounds like solving what Debian solved 30 years ago. Doesn’t the fact that the Debian stable repo is extremely conservative (precisely to avoid breaking the system or increasing the chances of security vulnerabilities) compensate for any lack of isolation? And if the only rejoinder is “maybe, but Debian is not bleeding edge,” just know most people outside Reddit don’t really care about that.
Not being on the bleeding edge is not the same as secure. It reduces the probability of new issues being introduced but it also usually leads to slower reaction times when issues in older versions are found. It is doable via back porting the security fixed however it's adds another step to publish the security fix. Sandboxes also introduce another preventive layer which may make the issue less damaging even if exploited before it's fixed.
For this reason I wouldn't count being conservative with updates as a replacement for sand boxing. It does however resolve issues with dependency hell.
There are actually a lot of people caring about somewhat newer package versions, especially in terms of Linux gaming and content creation, bugs and incompatibilities are numerous and need constant fixing. That's not a Reddit isolated occurrence, it highly depends on what you expect to run on your system.
PS: Another thing I just remembered. Dependency hell exists on both sides. Developer and User. Debian fixes it for the end-user, however, the developer still needs to support all the different distributions separately. Even Linus Torvalds complained about that: "Linus Torvalds on why desktop Linux sucks"