I would love for the permission system to move more towards the Android/IOS/Macos system, where you need to explicitly give your permission. It could be optional on a system basis, but it would be an improvement imo
Yea, a big security flaw of flatpaks is the fact that applications are able to grant themselves permissions by default. Kinda defeats having a permissions system if the user doesn’t have to think about it. Having prompts would be good since applications could dynamically ask for permissions instead of leaving it up to the user to set any needed permissions. Like if it needs regular access to a directory, instead of assuming the user knows to add it using flat seal, it can just be a permissions prompt. As far as I know, this doesn’t yet exist and would be nice
Is this not a problem that has to be rectified on the portal frontend side? For example, if you were using the xdg-desktop-portal-gnome it would be responsible for prompting the user if they want to allow a program to use the camera.
I really like portals and the permission system and find myself going out of my way to use Flatpak apps as a result. Being able to have granular control over notifications, backgrounding, filesystem access, etc all from one place is an absolute game changer.
I'm surprised that KDE with Plasma Mobile, or you know Purism with Phosh, never thought of having the notification portal revised to be more adapted to mobile.
I love sandboxing and permission systems.... when they work. I hate them when they fail without good reason or notification and don't even mention a solution. (e.g. give the app access to a directory) On windows I hated how Discord scanned all my processes, did god knows what with my devices, and could basically start a screen-capture any time it felt like it so I'd prefer that sand-boxed.
@@balsalmalberto8086 Linux has plenty of sandboxing capabilities, and there are "similar apps" available. Most of it is very distro/application directed, not user directed though. In the sense that policies are not easily managed by the user. I'd like to see a split approach to it, where you have default policies which are wide, then you as the user can narrow down the confines on top of it (or open up additional if required). The problem is that it needs to be high-level enough for a user to understand and use in a GUI, but still allow for power users to logically apply more advanced permissions without studying a bible-length documentation first.
The more control over my system and applications the better! I really don't get the naysayers who want to stay with just the user permissions. They make no sense on a single user system.
@@cameronbosch1213 I'm against systemd yet Wayland has been my goto for the past year, and I support the changes to the notification portal. I don't get your point
@AOSP-is-still-Linux What I'm trying to say is that those users are against ANY change, whether it's positive, negative, or even just needed. I do see why some people don't like systemd because of no major alternatives on many big distros, but yeah, I agree with you otherwise. (I do use a distro that uses systemd by default btw. And yes, I also use Wayland and support desktop portals.
My only problem with staying on Wayland, and using the Portals, is the fact that Applications can't remember their settings for manual given permissions between runs. Such as using OBS, you have to basically re-setup your screen caps on each run of OBS, because OBS settings cannot remember their given permissions, once they are given permission to do the captures. This is a major flaw in my opinion, and should be something that is recorded on a per app basis, that is not limited to 1 time run.
You should be able to grant permissions permanently with the "flatpak override" command. Or if you're on KDE you can install the Flatpak KCM to change Flatpak permissions right in the KDE settings panel
I think something like how web browsers / mobile OSes do it. Opening a dialogue window like "[application] wants to access [thing]. Don't Allow, Allow once, Allow while using the app, Allow always". This way you can select if you want the app to have access for just this time, or just give it access forever (until you explicitly disable it or reinstall or something)
@@bluesillybeard The usual explosion of problems there is similar to file choosers: what GUI should be used? Should the app present it, or the system? How would it be generalized if it has to be presented with different frameworks, like Qt or GTK?
Flatpak is something very interesting and it's what Linux needs, but currently almost every application in Flatpak I have some problem with permission, theme or tray icons not showing... If it's supposed to be something simple that just works, there's still a way to go.
Themes is a big want to and not necessarily a need. As long as ui is not malformed and does keep bright / dark setting, I don't think it's the highesr priority issue
@@razzeeee Some flatpaks are by default misconfigured with their permissions for filesystem access, though. And it's really annoying, and something that is really preventable if package maintainers set the packages up right.
8:17 This is a weird example to use; apps don't have direct USB access to keyboard and mouse. I *don't want* any applications to have access to my keyboard directly, except for the configuration utility. If they did, they'd be keyloggers. You make it sound like the current state of linux desktop is that sandboxed apps have access to all USB devices because they need keyboard/mouse
I'm the developer of a GTK4 app, portals are really really nice, I can just ask GIO or GTK to request a file picker, take a screenshot, send a notification and stuff like that, and it just works across any desktop
4:00 it is useful. KDE connect for example, you can reply to text messages from the notification on the desktop! Notification deferral makes sense. You can snooze notifications in android. Something like this would be incredibly useful there. 'n unseen notifications' is important, especially on mobile. It would be shitty to not have. Android has it. I use it. Persistent notifications are incredibly useful. Notification urgency is useful. A call, alarm, timer etc should show up at the top of the list.
One thing I really want is the dialout group to be a portal. Things like Arduino are annoying to use because of it and it always made me feel insecure adding myself to it.
3:56 Iu se this quite often, because I use KDE Connect and quite like to use WhatsApp's quick reply in the notification that even works through the desktop notification through KDE Connect.
considering your recent video about the best PR ever for the 3DS emulator, I'd be surprise if there isn't a notification demon to vibrate those devices!
4:55 I think this prevents an app from scheduling notifications after they are deleted which might lead to some crashes because the app no longer exists
Icon badges should **not** be notification counters, they should be for app specific features like unread emails only. the only app that should ever show a notification count as a badge is the notification panel itself.
I always thought the lack of a proper permission system was weird, especially when GNOME settings has permissions on each app's page but there's usually nothing there
A notification that buzzes game controllers that are plugged in could make sense in certain situations, like you're gaming and it's a really important notification (or someone calling on some VOIP etc), or even simply you have audio muted, or have headphones connected to another device (telephone) etc. Might wanna avoid touching simracing wheels though; some of them have very realistic strengths, enough to break fingers, don't wanna have them jerk unexpectedly.... Definitely something that should be optional, and configurable per-importance, per-app, user selection of vibrating device, different profiles etc
My only issue, and its a pretty niche use case is my CAC(Military ID) doesnt work with flatpaks despite the "support" being there and it has access to PCSC. Or im missing something. But it just doesnt work. Tried countless articles and things I've found in comments.
In my experience as a dev that has a flatpak I can say that flatpak sandboxing hurts linux. Flatpak is a good way to release applications that work reliably across all linux distros, but many applications can either not be easily made to work in flatpak or cant be done at all without major hacking around flatpak (that's the case for my application). There should be an option to release a flatpak without the sandboxing (except the library sandboxing that makes the application work on all distros). Not all applications are made to be sandboxed. Not all applications are standard (simple) gnome applications.
3:00 Brodie, they mean like a rumble motor in the device itself. Like what if you're running a wayland session on a linux mobile device. Example: pinephone-pro with the gnome wayland de.
I think you should release your "credit roll screen" as a short because sometimes I want to just put it on repeat or a full version with the full song :p
Thank you for the amazing video. I would love the permission system as I use Flatpaks often simply because of the fact that they are sandboxed and I only give them permissions for the Files which I ireally do need for that application. It gives me some feel of security and control over what an app may actually use.
I was hoping you were going to say they fixed the horrendous download speeds for updates and the inability to parallel downloads. O well, still way better than snaps.
I know Flatpaks are objectively great but they are a NIGHTMARE for every linux beginner. Themes don't apply to flatpaks correctly so you gotta figure out how to correct that, flatpaks don't come with the correct permissions out of the box (Collector literally doesn't work OOTB), don't get me started on environment variables... and flatseal doesn't even come preinstalled with most distros so how would newbies even know it exists... sorry for the rant lol
I feel like flatpak is currently relying too much pre-defined behaviour to poke holes in the sandbox. This is fine if people are actually aware of how the package is defined, but I'm willing to bet not many people actively think about that. It needs more runtime prompting like pretty much every other modern OS have moved to. This is probably up to the the portal front end developers though.
🤓I have a very old 90's Logitech force feedback, multi-button joystick that became obsolete with Windows XP, although with a hacked driver and other hacking worked OK, but it's always worked well with Linux out of the box since when I first tried it ~2010. I haven't tried it in quite a while, I'm already surprised how well it's held up, and still expecting to pull it out and find all the rubber decayed to shreds, then turn it on and smell motor smoke, so I'm kind of scared to even look!
13:54 what about the WebExtensions portal? I follow that, and even though the checks are now all-green, I still don't expect to have that until at least Summer 2025. That's how much false hope I've endured from following that MR. As for the usb portal, I'm so happy it got merged. I _finally_ have no need to layer Gnome Boxes on my image just because the stupid thing cannot do usb devices redirection on Flatpak.
so uh.. I don't have source code or evidence for this, but a buddy long ago rigged up a playstation controller (3? maybe 2? dunno when they supported bluetooth) to vibrate whenever he got a notification on his gnome desktop, depending on the type of notification. I don't think it was really "supported" beyond a script was run that did something to make the controller vibrate.
I had to create my own notifications in my application (that is in flatpak as well) because notifications dont reliably show on all desktop environments (especially kde plasma) in some circumstances. In my case the notification needs to always show and always on top of applications. I got bug reports because of this notification design in desktop environments that I had no control over.
Frankly, flatpaks need a giod theme portal. Yesterday i indtalled kwrite & it couldn't pick my kvantum theme Yeah yeah we can just copy the flatpak version of the theme or just copy themes from the /usr/sahre/theme dir to .themes but its a lot extra work to keep uodated both dirs and symlinking doesn't work. And as for flatpak version, most of the themes doesn't have a flatpak versison.
Does anyone know a notification daemon that just black-holes all notifications? I despise notifications with my entire being, but for some reason quite a few applications don't work correctly if you don't have a notification daemon running, for example flameshot. Flameshot goes into a 15s-30s loop of trying to write something to the notification daemon over dbus and only once that time has elapsed does the screenshot get put into the clipboard. Similar things occur with other applications....
to be fair I am a person who's using from time to time the reply located in a notification. For example when I get a Microsoft Teams notification and all I have to say is "OK", "Done" etc, something short and to the point. If I could have that keyboard centered it would be even better (early days of exploration in this matter).
Yes it does you just need to install a Flatpak of the theme (which should be automatic). Otherwise if it’s an obscure theme you just export the /usr/share/themes directory (or ~/.theme) to the sandbox using a command
@@lightechoes Flatseal itself, doesn't matter how many themes you install or how many overrides you put on it, it only works with adwaita or adwaita dark.
It blows my mind that "the API should not delay notifications" is even a conversation. In full screen applications and especially in games, that should be the user's choice, not the program's. What am I missing?
I think that means apps aren’t able to request a delay on their notifications, not that desktops aren’t allowed to temporarily hide notifications. they were talking about API features, not implementation requirements
Strictly from technical point of view, Snaps are by far superior to Flatpak. Snap is the only package format that works universally for desktop applications, server, IOT.
Permission systems always tend to move towards people just clicking on OK to get on with it. I can't think of the last time I pondered whether UAC was asking something useful. Then again, they tend to happen at expected times. Android permissions have been whack for a while but they seem to be a little better now than they were. The location access request for something that's not inherently a location access function is still a bit odd.
The biggest flaw is that it install the same dependency ten times. And will never be "fixed" because is not a bug, but a feature to handle dependency hell.
Considering how cheap storage is nowadays, i'd take it over packages that are unuseable cause they never updated to new version of framework (gtk, kde etc)
My biggest issue with flatpack is that it allows the use of old dependencies, so you completely miss out on any security patches or performance improvements that would be part of running up to date versions of those same dependencies. Its alright (not great but alright) if the intent is to run older software which is no longer developed/maintained and just wont run on modern systems anymore (kind of like a wayback machine for linux desktop applications). Knowing that its always going to potentially be at least a little bit sketchy. But what happens if a flatpack app has a dependency that has a major security vulnerability? Who is responsible for fixing that if the original developer is no longer around, or is too lazy to update to modern version of that dependency in the first place. Do upstream maintainers need to start patching old versions of their software for security vulnerabilities:? Or os it flatpak itself thats supposed to be in charge of fixing the problem? If you are like the bottles devs, and your response to this is 'not my problem', thats not solving the issue, thats just putting the work on someone else
This is incorrect. Flatpak deduplicates dependencies. You only have two copies of a library if you have dependency on different versions of said library.
Next time, please begin by stating what that "biggest flaw" is. Almost three minutes into the video, I still have no clue. I keep hearing the word portal but unless this is a "programmers only" video (and in that case, it should say so) it is not at all clear.
Hot take: permission systems begat app stores and app stores begat scam applications. So no - permission systems are bad and should be prevented as much as possible.
@@balsalmalberto8086 One of the richest companies in the world can't build something like Flatpak says it all. Maybe the flaw is to still use and support Windows
oh great, by the time 95% of device interactions are now wireless, we have security for usb on linux 👏 classic linux bullshit also why is flatseal not installed by default??? whyyy
KDE has a permission manager built in. Also, what are you talking about? Most of my stuff is wired. Even my Pro Controller because the battery is cooked.
@@spatiumowl need for usb security peaked when everyone had a dozen thumbdrives. shit was wild. These days I have bluetooth keyboard, bluetooth mouse, no thumbdrives in the house for over a decade.
I would love for the permission system to move more towards the Android/IOS/Macos system, where you need to explicitly give your permission. It could be optional on a system basis, but it would be an improvement imo
Yea, a big security flaw of flatpaks is the fact that applications are able to grant themselves permissions by default. Kinda defeats having a permissions system if the user doesn’t have to think about it.
Having prompts would be good since applications could dynamically ask for permissions instead of leaving it up to the user to set any needed permissions. Like if it needs regular access to a directory, instead of assuming the user knows to add it using flat seal, it can just be a permissions prompt.
As far as I know, this doesn’t yet exist and would be nice
Also would be handy for when I want e.g. file permissions to a different location, yes there's flatseal, but that feels more like a kludge.
Canonical is working on that for filesystem paths. I imagine other permissions will follow suite. Albeit that will be for snap.
Isn't that something that can be done already? I think just front ends do not want to bother the users. But I don't see any technical difficulty
Is this not a problem that has to be rectified on the portal frontend side? For example, if you were using the xdg-desktop-portal-gnome it would be responsible for prompting the user if they want to allow a program to use the camera.
I really like portals and the permission system and find myself going out of my way to use Flatpak apps as a result. Being able to have granular control over notifications, backgrounding, filesystem access, etc all from one place is an absolute game changer.
I'm surprised that KDE with Plasma Mobile, or you know Purism with Phosh, never thought of having the notification portal revised to be more adapted to mobile.
I want my adult toy to vibrate when I get a notification!
*enables notifications for all messages in a discord server with 800k members*
Useful for chess
ULTRAKILL moment
🤔
I love sandboxing and permission systems.... when they work. I hate them when they fail without good reason or notification and don't even mention a solution. (e.g. give the app access to a directory)
On windows I hated how Discord scanned all my processes, did god knows what with my devices, and could basically start a screen-capture any time it felt like it so I'd prefer that sand-boxed.
Did you run it in Sandboxie? It would be killer if Linux had a similar app.
@@balsalmalberto8086 Linux has plenty of sandboxing capabilities, and there are "similar apps" available. Most of it is very distro/application directed, not user directed though. In the sense that policies are not easily managed by the user. I'd like to see a split approach to it, where you have default policies which are wide, then you as the user can narrow down the confines on top of it (or open up additional if required). The problem is that it needs to be high-level enough for a user to understand and use in a GUI, but still allow for power users to logically apply more advanced permissions without studying a bible-length documentation first.
@@balsalmalberto8086Flatpak
@@balsalmalberto8086 in a nutshell, that's what flatpaks are. Sandboxed applications with very limited access to the system.
@@balsalmalberto8086 linux does have firejail, but i imagine sandboxie is a lot easier to use
The more control over my system and applications the better! I really don't get the naysayers who want to stay with just the user permissions. They make no sense on a single user system.
They're the ones also against systemd just because it doesn't follow the "Unix philosophy" and are also often against Wayland.
@@cameronbosch1213 I'm against systemd yet Wayland has been my goto for the past year, and I support the changes to the notification portal. I don't get your point
@AOSP-is-still-Linux What I'm trying to say is that those users are against ANY change, whether it's positive, negative, or even just needed.
I do see why some people don't like systemd because of no major alternatives on many big distros, but yeah, I agree with you otherwise. (I do use a distro that uses systemd by default btw. And yes, I also use Wayland and support desktop portals.
@@cameronbosch1213 people complain about systemd and wayland?
because it goes against the unix philosophy...? why??
@@cameronbosch1213 I use openrc on my desktop and systemd on my server (because of Arch :/)
My only problem with staying on Wayland, and using the Portals, is the fact that Applications can't remember their settings for manual given permissions between runs. Such as using OBS, you have to basically re-setup your screen caps on each run of OBS, because OBS settings cannot remember their given permissions, once they are given permission to do the captures. This is a major flaw in my opinion, and should be something that is recorded on a per app basis, that is not limited to 1 time run.
You should be able to grant permissions permanently with the "flatpak override" command. Or if you're on KDE you can install the Flatpak KCM to change Flatpak permissions right in the KDE settings panel
I think something like how web browsers / mobile OSes do it. Opening a dialogue window like "[application] wants to access [thing]. Don't Allow, Allow once, Allow while using the app, Allow always". This way you can select if you want the app to have access for just this time, or just give it access forever (until you explicitly disable it or reinstall or something)
@@bluesillybeard The usual explosion of problems there is similar to file choosers: what GUI should be used? Should the app present it, or the system? How would it be generalized if it has to be presented with different frameworks, like Qt or GTK?
@@XeZrunner This is a totally fair point. I think it would be handled by the window manager or compositor, but honestly I'm not sure.
Gnome hates having usable information available at a glance. That's why they hate systrays and notification bubbles on app icons.
Because GNOME isn't making their DE for autistic power users but normies who are going to shit themselves if they suffer too much info overload.
Flatpak is something very interesting and it's what Linux needs, but currently almost every application in Flatpak I have some problem with permission, theme or tray icons not showing... If it's supposed to be something simple that just works, there's still a way to go.
Themes is a big want to and not necessarily a need. As long as ui is not malformed and does keep bright / dark setting, I don't think it's the highesr priority issue
They don't keep dark and light theme though
@@VictorSouza02 sounds like a problem with your distro and their implementation
@@razzeeee yes, it's Arch + KDE issue, Flatpak is perfect and all the people complaining in the comments have problems with the distro too 😂
@@razzeeee Some flatpaks are by default misconfigured with their permissions for filesystem access, though. And it's really annoying, and something that is really preventable if package maintainers set the packages up right.
8:17 This is a weird example to use; apps don't have direct USB access to keyboard and mouse. I *don't want* any applications to have access to my keyboard directly, except for the configuration utility. If they did, they'd be keyloggers. You make it sound like the current state of linux desktop is that sandboxed apps have access to all USB devices because they need keyboard/mouse
On Apple it's normal that it has access to it. It needs to, otherwise you cannot close the app.
I'm the developer of a GTK4 app, portals are really really nice, I can just ask GIO or GTK to request a file picker, take a screenshot, send a notification and stuff like that, and it just works across any desktop
4:00 it is useful. KDE connect for example, you can reply to text messages from the notification on the desktop!
Notification deferral makes sense. You can snooze notifications in android. Something like this would be incredibly useful there.
'n unseen notifications' is important, especially on mobile. It would be shitty to not have. Android has it. I use it.
Persistent notifications are incredibly useful.
Notification urgency is useful. A call, alarm, timer etc should show up at the top of the list.
One thing I really want is the dialout group to be a portal. Things like Arduino are annoying to use because of it and it always made me feel insecure adding myself to it.
3:56 Iu se this quite often, because I use KDE Connect and quite like to use WhatsApp's quick reply in the notification that even works through the desktop notification through KDE Connect.
13:36 take your pick, thats all of wayland protocols
considering your recent video about the best PR ever for the 3DS emulator, I'd be surprise if there isn't a notification demon to vibrate those devices!
didn't you recently talk about a certain library utilized to vibrate something, surely useful for desktop notifications ....
KDE notification buttplug integration now!
They need something for sandboxed apps to interact with each other. Example, password manager and web browser.
Woah, giving developers money makes them do their job? 🤯
4:55 I think this prevents an app from scheduling notifications after they are deleted which might lead to some crashes because the app no longer exists
Icon badges should **not** be notification counters, they should be for app specific features like unread emails only. the only app that should ever show a notification count as a badge is the notification panel itself.
I always thought the lack of a proper permission system was weird, especially when GNOME settings has permissions on each app's page but there's usually nothing there
A notification that buzzes game controllers that are plugged in could make sense in certain situations, like you're gaming and it's a really important notification (or someone calling on some VOIP etc), or even simply you have audio muted, or have headphones connected to another device (telephone) etc. Might wanna avoid touching simracing wheels though; some of them have very realistic strengths, enough to break fingers, don't wanna have them jerk unexpectedly....
Definitely something that should be optional, and configurable per-importance, per-app, user selection of vibrating device, different profiles etc
My only issue, and its a pretty niche use case is my CAC(Military ID) doesnt work with flatpaks despite the "support" being there and it has access to PCSC. Or im missing something. But it just doesnt work. Tried countless articles and things I've found in comments.
Wayland and lack of drive to get something done. Name a more iconic duo
"Well, of course you would need to give permission to all of your usb devices. Its USB not MEB!"
In my experience as a dev that has a flatpak I can say that flatpak sandboxing hurts linux. Flatpak is a good way to release applications that work reliably across all linux distros, but many applications can either not be easily made to work in flatpak or cant be done at all without major hacking around flatpak (that's the case for my application). There should be an option to release a flatpak without the sandboxing (except the library sandboxing that makes the application work on all distros). Not all applications are made to be sandboxed. Not all applications are standard (simple) gnome applications.
What do I think of sandboxing? I run qubes OS.
Sandboxing is still useful even if using virtual environments. Belt and suspenders.
3:00 Brodie, they mean like a rumble motor in the device itself. Like what if you're running a wayland session on a linux mobile device. Example: pinephone-pro with the gnome wayland de.
I started that segment by talking about how most the changes matter for Linux smartphones
I find it interesting that no one seems to be giving vibration motors to laptops, specially gaming laptops...
I think you should release your "credit roll screen" as a short because sometimes I want to just put it on repeat or a full version with the full song :p
Thank you for the amazing video. I would love the permission system as I use Flatpaks often simply because of the fact that they are sandboxed and I only give them permissions for the Files which I ireally do need for that application. It gives me some feel of security and control over what an app may actually use.
I was hoping you were going to say they fixed the horrendous download speeds for updates and the inability to parallel downloads. O well, still way better than snaps.
Shouldn't there also be a "do not disturb" API for when one is using a full-screen app and doesn't want to be disturbed by notifications?
Do you know about the Pluton Chip? I heard its basically a backdoor built into our CPUs.
eh IME is always on since first i7 processors
15:30 those are two separate systems, permission review is not connected to showing permissions
My main issue with Flathub, is every application is marked as dangerous therefore the term is meaningless.
@BrodieRobertson I get that, but there is nuance, we have at least four levels right now and I still think being transparent is important
I know Flatpaks are objectively great but they are a NIGHTMARE for every linux beginner. Themes don't apply to flatpaks correctly so you gotta figure out how to correct that, flatpaks don't come with the correct permissions out of the box (Collector literally doesn't work OOTB), don't get me started on environment variables... and flatseal doesn't even come preinstalled with most distros so how would newbies even know it exists... sorry for the rant lol
I feel like flatpak is currently relying too much pre-defined behaviour to poke holes in the sandbox. This is fine if people are actually aware of how the package is defined, but I'm willing to bet not many people actively think about that. It needs more runtime prompting like pretty much every other modern OS have moved to. This is probably up to the the portal front end developers though.
You could potentially vibrate a haptic touchpad, that would be useful
🤓I have a very old 90's Logitech force feedback, multi-button joystick that became obsolete with Windows XP, although with a hacked driver and other hacking worked OK, but it's always worked well with Linux out of the box since when I first tried it ~2010. I haven't tried it in quite a while, I'm already surprised how well it's held up, and still expecting to pull it out and find all the rubber decayed to shreds, then turn it on and smell motor smoke, so I'm kind of scared to even look!
13:54 what about the WebExtensions portal? I follow that, and even though the checks are now all-green, I still don't expect to have that until at least Summer 2025. That's how much false hope I've endured from following that MR.
As for the usb portal, I'm so happy it got merged. I _finally_ have no need to layer Gnome Boxes on my image just because the stupid thing cannot do usb devices redirection on Flatpak.
I think it would be awesome to be able to control notifications sounds on desktop.
so uh.. I don't have source code or evidence for this, but a buddy long ago rigged up a playstation controller (3? maybe 2? dunno when they supported bluetooth) to vibrate whenever he got a notification on his gnome desktop, depending on the type of notification. I don't think it was really "supported" beyond a script was run that did something to make the controller vibrate.
My phone seems to dump notifications on me when I pick it up... I think that's a good feature.
What about resolving .local domains in flatpak apps?
I was very confused for a while because I thought he was talking about Wayland lol. I guess my ADHD activated and forgot "Flatpak" was in the title.
I had to create my own notifications in my application (that is in flatpak as well) because notifications dont reliably show on all desktop environments (especially kde plasma) in some circumstances. In my case the notification needs to always show and always on top of applications. I got bug reports because of this notification design in desktop environments that I had no control over.
Well, maybe they DON'T want that
Frankly, flatpaks need a giod theme portal.
Yesterday i indtalled kwrite & it couldn't pick my kvantum theme
Yeah yeah we can just copy the flatpak version of the theme or just copy themes from the /usr/sahre/theme dir to .themes but its a lot extra work to keep uodated both dirs and symlinking doesn't work. And as for flatpak version, most of the themes doesn't have a flatpak versison.
Does anyone know a notification daemon that just black-holes all notifications?
I despise notifications with my entire being, but for some reason quite a few applications don't work correctly if you don't have a notification daemon running, for example flameshot. Flameshot goes into a 15s-30s loop of trying to write something to the notification daemon over dbus and only once that time has elapsed does the screenshot get put into the clipboard. Similar things occur with other applications....
to be fair I am a person who's using from time to time the reply located in a notification. For example when I get a Microsoft Teams notification and all I have to say is "OK", "Done" etc, something short and to the point. If I could have that keyboard centered it would be even better (early days of exploration in this matter).
Flatpak's real biggest flaw, mandatory installation, is not being solved and will never be
Theming still doesn't work.
Theming works fine on Flatpak wdym?
Yes it does you just need to install a Flatpak of the theme (which should be automatic). Otherwise if it’s an obscure theme you just export the /usr/share/themes directory (or ~/.theme) to the sandbox using a command
@@PizzaLovingNerd Nope, not even overriding the GTK THEME variable. Theming in flatpak outside of gnome or kde is a myth.
@efeme04Got any examples?
@@lightechoes Flatseal itself, doesn't matter how many themes you install or how many overrides you put on it, it only works with adwaita or adwaita dark.
Fix the .var directory to use xdg
It blows my mind that "the API should not delay notifications" is even a conversation. In full screen applications and especially in games, that should be the user's choice, not the program's. What am I missing?
I think that means apps aren’t able to request a delay on their notifications, not that desktops aren’t allowed to temporarily hide notifications. they were talking about API features, not implementation requirements
@@justapotota4330 ah that would make substantially more sense, thank you!
All my homies love flatpak
Sovereign Tech Fund is Sovereign Tech Agency now.
1:57, @Brodie don't get locked out of your account ;)
Is the thumbnail click bait cuz its spelled license?
I used flatpak for steam and openmw
Never again, I opted for the tarball for openmw and suddenly it was able to find everything
I have had some tarballs fail to set all permissions correctly. Tarballs are also very slow to unpack compared with a zip file for example.
licence? i guess..
17:01 that's what she said
Strictly from technical point of view, Snaps are by far superior to Flatpak.
Snap is the only package format that works universally for desktop applications, server, IOT.
Permission systems always tend to move towards people just clicking on OK to get on with it. I can't think of the last time I pondered whether UAC was asking something useful. Then again, they tend to happen at expected times. Android permissions have been whack for a while but they seem to be a little better now than they were. The location access request for something that's not inherently a location access function is still a bit odd.
In my experience, the biggest flaw is performance
The biggest flaw is that it install the same dependency ten times. And will never be "fixed" because is not a bug, but a feature to handle dependency hell.
I think it's a worthy tradeoff, to be honest.
Considering how cheap storage is nowadays, i'd take it over packages that are unuseable cause they never updated to new version of framework (gtk, kde etc)
My biggest issue with flatpack is that it allows the use of old dependencies, so you completely miss out on any security patches or performance improvements that would be part of running up to date versions of those same dependencies.
Its alright (not great but alright) if the intent is to run older software which is no longer developed/maintained and just wont run on modern systems anymore (kind of like a wayback machine for linux desktop applications). Knowing that its always going to potentially be at least a little bit sketchy.
But what happens if a flatpack app has a dependency that has a major security vulnerability? Who is responsible for fixing that if the original developer is no longer around, or is too lazy to update to modern version of that dependency in the first place. Do upstream maintainers need to start patching old versions of their software for security vulnerabilities:? Or os it flatpak itself thats supposed to be in charge of fixing the problem?
If you are like the bottles devs, and your response to this is 'not my problem', thats not solving the issue, thats just putting the work on someone else
This is incorrect. Flatpak deduplicates dependencies. You only have two copies of a library if you have dependency on different versions of said library.
I will take redundant storage usage over glibc DLL hell.
I thought the biggest flaw in flatpak was the size of the runtimes 😅
Deduplication
"What do I think about permission systems?"
Is there anything more boring..... But unfortunately, necessary!
You got a loicense for that, guv'nah?
Don't get locked out of your account.
3:01 butplugio port 😂
minecraft linux players when thet hear "1.19.1"
Next time, please begin by stating what that "biggest flaw" is. Almost three minutes into the video, I still have no clue. I keep hearing the word portal but unless this is a "programmers only" video (and in that case, it should say so) it is not at all clear.
Check description
@@animainmilol I did. I guess I was right about this being a "programmer's only" video.
Hot take: permission systems begat app stores and app stores begat scam applications. So no - permission systems are bad and should be prevented as much as possible.
I feel like I can estimate your age within about 3 years from this comment.
guessing that your were born in 2001?
@jamesphillips2285 wow! So wrong. You're off by decades. I was already an experienced Linux user in 2001.
Flatpak's biggest flaw is existing, though.
Agree.
Unfortunately Flatpakt have more flaws.
With the biggest being the Limitations.
Flatpak has flaws because it has limitations 🔥🔥🔥🔥🔥🔥📢📢📢🔥
Flatpak has limitations because it has flaws 🔥🔥🔥🔥🔥🔥🔥📢📢
Only thing i wish is for better support for non-gui apps like snap is great for such cases but its snaps ughh
@@lucolescoThe emojis really sell it 😂😂😂😂😂
Thanks for the laugh
The flaw is that it runs on Linux instead of Windows.
@@balsalmalberto8086 One of the richest companies in the world can't build something like Flatpak says it all. Maybe the flaw is to still use and support Windows
This is why wayland is doomed.
X11 is feature complete.
Wayland is at this time not even cooked medium-rare.
Then contribute to X if you like it so much
this has nothing to do with wayland
it's not about wayland, it's about flatpaks/portals
You can literally use flatpaks and portals on X11.
I don't want to support Elon.
Last
but you were the first?
well i mean its technically not wrong though, even if you werent the first
That's what she said
oh great, by the time 95% of device interactions are now wireless, we have security for usb on linux 👏 classic linux bullshit
also why is flatseal not installed by default??? whyyy
Many wireless devices still make use of the USB protocol. What are you talking about?
KDE has a permission manager built in. Also, what are you talking about? Most of my stuff is wired. Even my Pro Controller because the battery is cooked.
KDE has its own flatseal, Gnome should ship flatseal by default or create their own.
@@spatiumowl need for usb security peaked when everyone had a dozen thumbdrives. shit was wild. These days I have bluetooth keyboard, bluetooth mouse, no thumbdrives in the house for over a decade.
@simonmaracine4721 I'm talking about ratio. USB is in use but far far faaaaaaar from being as popular as it used to be.
Upload on 0 D Y S E E as well please!