Its even worse when you force Firefox to use wayland its icon doesn’t even show.
Edit: Oh since everyone now is confused; I only have the flatpak version of Firefox installed yet it doesn’t use the pinned icon and doesn’t even use the firefox icon under wayland at all.
Very simple. Debian Testing is rolling distro and has fairly fresh versions, usually couple of months behind. Debian Unstable has all the bleeding edge stuff, also rolling. Neither is unstable and insecure as most would expect. If you want non-Debian, there’s always Arch and Manjaro.
I never intend to use a flatpak or snap, and avoid them like the plague. The whole concept is incredibly ugly to me, and wasteful of computer resources.
Depends on the viewpoint. As a software consumer, sure. As a software producer though, not having to deal with with tons of different packaging formats and repositories for different distributions and versions is a blessing.
You aren’t owed a native package for whatever OS you’re using. In fact, you should be thankful that flatpak exists because the most common alternative is piping wget into shell.
And if you care so much about security, just build your stuff from source. Whether flatpak or apt, at some point you will run third-party code.
It wastes resources on the consumer side to free up resources on the developer side, allowing for more time spent on improving the software instead of worrying about millions of different system setup combinations.
Pretty much typical these days. Developers will often use metric tons of middleware hell to avoid writing one function or using native library. What’s that, GTK or Qt require few days to learn. Naah, I’ll just include whole browser with my application and write interface in HTML/CSS. Who cares about people’s configuration, accessibility needs, battery life, screen readers, etc.
There are of course two sides of the story, and you are right that it causes performance/battery life issues. Including a browser does actually improve the situation with screen readers and such.
The big advantage of the “include a browser/large framework” solution is that it allows you to write the application once and use it on web, Linux, Windows, Mac, Android, iOS, some weird TV OS, a game console or someone’s car.
Without some middleware you’d be writing 10 different versions and every one would need it’s own native libraries that are “just a few days to learn” and “just a few dozen days to master” and only “a few hundred hours to implement and maintain”, and the result would be what we had in the 2000s: “Sorry, we do not support Linux.”
I’d rather developers don’t support Linux than make Electron application and say “there we go, good enough right”. Because it’s not. When it comes to accessibility, no those applications are not better. You might be thinking their UI is easier to scale and increase contrast but literally none of them respect system theme, colors, font choices.
Some middleware is fine, however blindly importing just about anything is very dangerous and lazy. Cargo cult programming is so widespread am surprised hardware is keeping up with the demand. There’s always the right tool for the job and the wrong tool for the job. Just because you can drive nails with a rock, doesn’t mean you should, nor you see any carpenter doing it.
I’d rather developers don’t support Linux than make Electron application
Hard disagree. I’d rather run an Electron application than having to side-load Windows for some application I actually need. Also, you don’t have to install Electron applications, so if you want you can just pretend they don’t support Linux.
Since when is theming aaccessibility? That’s customizability.
But you can have your wishes easily. If you prefer no Linux support over an Electron app, just don’t install the Electron app and you get the same result.
Because it’s the easy way out. Just like if Valve’s Proton ever gets good enough people will entirely stop making native ports. They will just ell you use Proton and you as a user lose in the long run.
You can downvote all you like. People will always take easier route, just how IE was default browser for decades just because people didn’t have to install it and it was already there.
Most native Linux apps have absolutely shit keyboard navigation and screen reader support, if they even bothered testing it at all. So yes web apps are far better for accessibility.
I’m sick of purists who don’t know they’re talking about. If it was up to you there’d be zero growth in Linux and you’d actually be happy with that. Electron exists to put software on multiple OSes at low cost. It’s a good thing. App devs are just jealous that they’re getting replaced by web and mobile devs, both of whom they’ve shat on for decades.
Karma’s a bitch. It isn’t the 90s anymore, the time to move on and learn a worthwhile stack was 15 years ago. If you’re so good then surely you can bring your genius level skills to a web team and show them how it’s done.
You assumption that I am clueless just shows you have no idea what you are talking about so I’ll end up all arguments there. If you wish to prove me wrong, find me one Electron based application which supports high contrast themes and actually took care not to use colors that are problematic to color blindness.
Am a developer and I can very much agree on package managers have nasty configuration, but at the same time flatpak is the exact same thing. No different that any other package. Except now you have to learn yet another standard that’s even less popular than major ones. You can even claim it’s easier, but the fact remains it’s not the defacto standard, so you still have to provide other packages as well as flatpak if you wish to do so.
flatpak isn’t the same because you only have to learn one packaging format and can distribute to virtually any system out there. I really don’t see why you’d also package for every distro individually then. Installing flatpak isn’t that hard, it not being “the defacto standard” shouldn’t be an issue.
Don’t know about the OP, but I only have one version installed. If I don’t have it open, a single icon shows on the task bar. If I press that icon, FF opens and a second icon shows up, that represents only the opened FF, while the original icon remains.
In that particular screenshot I believe you’re right: the one on the left is Firefox ESR while the icon on the right is whatever flatpak version available.
But I know what OP is referring to as it is a open bug currently, the DE don’t doesn’t recognize the launched instance as the pinned program due to the way Flatpak launched apps. Not an issue with Firefox in particular
I am having the same thing at the moment with the Firefox snap package under Ubuntu. Except as well as this, when it updates it seems to take out everything else pinned to the task bar with it. Maybe it’s not Firefox doing that, but since I stopped pinning FF it has stopped happening.
No no I only have the flatpak version of firefox installed yet in my taskbar it doesn’t use the pinned icon and on wayland it doesn’t have an icon at all.
"hey guys, I'm having a problem with my Linux install that doesn't seem very common--"
"YOU'RE STUPID AND I HATE YOU"
this is EXACTLY why Linux gurus have a bad rep. remember the human, for goodness' sake. don't act like you've never run into a strange problem in your entire computing life that required digging deep into some 2003 forum post to solve.
Please show me the QA process applied to flatpaks, so I know that besides it “working” is not full of obsolete vulnerable holes. Or should I just trust the Dev is not a lazy person?
the only reason to use flatpaks is if your system doesnt come with a good package manager and repositories (pacman+aur, nix, etc), and dont want to build from source.
snaps, on the other hand, should be avoided at all costs imo.
Tied to proprieatry backend, snap store looks like ass and runs like one, spawns loop devices that mess up the /mnt folder, tied to fake .deb packages that install snaps instead. Basically, a lot of proprieatry nonsense that St. Ignucius frowns upon.
i have no issues with flatpak, once i found out how to fix gtk scaling and theming issues on kde. here’s a link if anyone has those problems as well bugsfiles.kde.org/attachment.cgi?id=135846.
I use the Firefox flatpak on multiple different desktops and distros and I’ve never seen this issue. All on wayland (no difference on x11 either). Weird.
Basically you install the application inside a little OS with dependencies each time you install a flatpak, that OS is rarely updated with security patches and most of the time has full access to the host OS. flatkill.org
This is a lazy and insecure way of distributing applications with no real benefits.
I don’t know what distro you use, but packages in their repos have “maintainers” that are usually volunteers. Downloading from repos from the distro is trusting whoever the maintainer is there. I don’t see how that is any better than a flatpak… At least with Flatpak many packages are maintained by the developer. I believe that would be more secure.
Major distros are usually backed by a compamny which provides enterprise version. Maintainers are actually employees paid for their work. Even if you pick a derivate distro you will inherit that testing process. So please get your facts straight before talking, you obviously need it. Here how it is done: openqa.opensuse.orgEach package update, distro install process goes through automated testing. This detects bugs, dependency issues, you name it. If something fails package goes back for human review. And as you can see it is an open process which YOU can review any time.
So… how are the flatpaks tested? Please show me some facts. I am interested in this new “trust me bro” QA framework.
You are very confrontational. I love being proven wrong so that I can learn more. But, your language is belittling. I hope my message didn’t come across that way.
Either way, looking at DistroWatch OpenSuse is about the #10 most popular Linux OS. MxLinux, Linux Mint, Debian, and Ubuntu are all debian based and above OpenSuse. Debian is by volunteers according to the Debian Package Maintainers Guide. So, I would think that the most-popular distros (especially in the non-professional world) are maintained by volunteers.
That comes with nuance though and I understand that. For instance, debian is celebrating 30 years. In that time I am sure many package maintainers have probably done this for very long amounts of time. So they are probably more worthy of trust than some Flatpak maintainers. But, when a flatpak is maintained by the developer (not that common in my experience) I would trust them the most.
Now, something I wasn’t aware of until someone else linked it is how bad Flatpak is as a sandbox. But, I never used it wanting a sandbox. I like it for the isolation of libraries (Dependency Hell). Updating my OS never breaks any packages, because the libraries are separated.
As for qa testing. It would be on a per-package stand point. I see how helpful that is. But, I’m not installing any command line utilities through Flatpak. Just desktop apps, like browsers, game launchers, etc. So, maybe we are talking about different types of packages…
I’m not convinced Flatpaks are inherently worse than packages from the OS’s repos themselves. But, I will be trying nix package manager as a replacement.
You were responding to my reply to someone else… but ok I guess. I am not here to convince you about anything. It’s not my problem what you install on your thing. I just don’t like misinformation spread based on ones believes and feelings, belittling work of whole teams of maintainters and QA staff which is core of why you can trust Linux ecosystem. Them being paid or not is not being relevant.
Exactly. The QA of flatpaks is done in “trust me bro” framework.
Then you belittled anyone using Flatpaks.
You can just go back to windows at this point.
All I said was that they are not too different. You are right about some OS’s having paid staff who have setup some great QA to handle it though. But, at some point you are "trust me bro"ing someone, paid or not.
Not a single person including you here was able to show any hint of package maintenance process, QA standard any kind of security awareness.
All I said was that they are not too different. You are right about some OS’s having paid staff who have setup some great QA to handle it though.
And I am saying it’s an uneducated statement which fails to back itself miserably.
But, at some point you are "trust me bro"ing someone, paid or not.
Dude… really? Quite a desperate attempt to make an argument. Yes at some point people are just atoms stuck together … a human being is not different from rock if you twist the point of view enough. This is just you pushing smoke in the room because you have nothing to back up what you are saying. There is a huge difference in trusting blindly and trusting because you have transparency in processes and standards which are followed.
So if flatpak and distro repository is not so different… please show me any published standards or processes that are followed to ensure that flatpak is secure, up to date, without obsolete libraries. Would be cool to see there some transparency. Please show me that I am as secure and stable as while running OpenSuse on my machine at home.
Flathub has verified apps. This means the build either comes directly from the developer of the app itself or someone that they approved to distribute their app through Flathub. That’s kinda the ultimate QA to me. If the developer of the app can’t be trusted then who can? Other than that, the only checks are the community.
Package managers like apt or rpmn(or whatever for your distro) are the standard way to install software. If there’s a good reason to avoid them, OK, but no good reason was stated here.
There definitely is a problem that flatpak is trying to solve. That problem is dependency hell.
This most often (or rather most famously) occurs with python packaging. Sometimes you can have one package that requires a version that is incompatible with another version that another package requires. That's why people use python venv these days (or just use pipx).
IMO a better way of solving this is with nix. With nix, it doesn't require a container, it just builds in isolation.
Thing is, this will probably end up a VHS vs Beta Max.
I am very impressed by nix. I have tried nixOS and it was very nice. But, I might have to try the package manager as a standalone to see how I like that.
@lambda a lot of people do nix-env -ia nameOfPackage. I would recommend doing it properly with a file, and you just direct that command to the file (I would probably setup an alias). It gives you that declarative nature that nix is known for.
@lambda they should if you use the single user command. The command that does it for the whole system requires root access, something you don't have on the deck.
You can get root very easily. But, updates wipe out all but your home directory. So, I think you’d do the single user that you are referencing for that reason.
Oh I didn't know, I just remembered reading that it utilizes an immutable filesystem and thought that it also doesn't give root access as well. That's good to hear though.
Imo a better alternative to flatpak is the nix package manager, but as I said to the other guy this'll most likely end up a VHS/betamax situation.
Both things are trying to solve dependency hell in different ways. Flatpak just builds and runs everything in a container, where as nix sets up virtual environments and builds things in isolation with per package dependency trees in an effort to make builds entirely reproducible (to the point that no matter what system you compile on, you will get the same hash).
Edit: as the other guy said, just use your systems package manager unless it doesn't exist in the repo and you can't be bothered to package it yourself. It's the standard recommended method.
The problem with dependencies, that’s the only reason for people to look at flatpak.
no, not really, flatpak is a distro agnostic way to build and distribute packages, which is HUGE for developers and distros, since those dont have to waste time to repackage (built+test) software to work on their systems and instead use that time to deal with other issues.
flatkill.org
The author should really take that site down. AFAIK, all the points are now invalid.
Not really, if you think about how many distros there are and how many people are currently wasting time with re-packaging software over and over for them i think you’ll come to realize that this is a very clever and efficient move. The way it is done currently seems rather silly in comparison.
Sidenote: You keep using the term OS … which is false in the sense, that flatpak doenst come with a direct hardware layer / kernel
just thought you wanted to use the term OS in a way that people will understand you. Saying OS without the kernel … sounds to me like i want a sandwich without filling … .
Next evolution will then be to use flatpak from within flatpak or what?
Is this a joke about para-virtualization? - anyway, i think flatpaks abstraction and isolations make sense. Not to much and not to little. Just enought to keep an application isolated from the basesystem while using portals to interact with necessary apis.
Using the word OS puts across my point, because when you start packaging your toolchain with glibc and whatever libs you need for your application, you end up with a good part of the Linux file system. Yes there’s missing services and so on but they could run if needed.
It’s not a virtualization joke, it’s more of a “we put flatpak in your flatpak so you can flatpak while you flatpak” recursion joke.
Sounds more and more like flatpak is a distribution atop of a distribution.
Good you can share libs, although I can’t see sense in sharing more than the absolute basic libs, and even then some applications will need different versions of the basic libs.
From what I gather nix is more of a next generation package manager than a application container/sandbox which means potential security problems with old libs could be less, or rather they are probably at the same level as rpm/deb.
I don’t see any problems with rpm/deb/etc. ending up getting the boot by nix or another package manager just because they are better, that’s just evolution.
As someone said about flatpak/snap that their ‘hidden’ strength is distribution of proprietary software, that’s fine by me if that’s the main usage of them.
The sandbox feature can be solved by SELinux/docker/and several other ways depending on usecase.
Sandboxing is not the main feature of Flatpak/Snap, being able to ship an app for various distributions without having to configure them separately is. Docker/Podman can do that, but then you would actually be shipping an entire distro.
Regarding docker/podman that’s why I wrote depending on usecase, for servers it makes sense to distribute because of scalability, on a single user OS it does not.
From what you write I guess that nix does the distribution part of flatpak, so that seems fine, there’s probably a catch/limitation somewhere, there usually is, but it could be an acceptable one.
Docker is made for servers, it’s totally a different usecase.
I am not anti VM and docker, I just don’t think we need more levels of indirection in the OS, I also don’t think a distro based heavily on flatpak will be any good, one thing is sure it will be using a lot of diskspace and memory, as there’s no sharing of libs. And if flatpak starts sharing libs it just re-invented the GNU linker.
Flatpak does support sharing ‘libraries’ (although not in the way you mean), however from my perspective the main problem is developers referencing Kde-Framework-420.69.1, and others referencing Kde-Framework-420.69.1-rc1 or various other variations of very similar dependencies, which tends to eat up additional disk space. I’m personally not too bothered by it, but that’s only because I have the storage space for that.
With flatpak’s shtick being isolation and a consistent runtime environment, I doubt there’ll be true sharing of linked libraries and the associated memory space, so excess RAM usage and disk space as you’ve mentioned.
The distros based on Flatpak (can’t remember the names right now sadly) are mostly immutable ones, where the base system remains untouched, and in that scenario I think it makes the most sense, particularly in education.
The instances I use flatpak are slightly similar to that, with the difference being the libraries available in the base system may be too old to run the application natively
I’m using KDE + Firefox Flatpak + Papirus Icons and I haven’t had this issue (so far). Could it be an icon pack issue or something similar? Otherwise yeah it’s either KDE or the flatpak
Why would you need another package manager next to the one supplied with the distro? The one that is supplied has packages that are tested and guaranteed to work (when on a stable release).
Yes, they are (sometimes very) outdated, but those packages are working. Additional package managers just add to the dependency hell (introducing bugs).
It’s kinda one size fits all solution. It allows Devs to build their package one way and have it on pretty much every distro, which is a major sticking point for Linux apps. I don’t see why you would use a flatpaks if your distro has the software already though. I use flatpaks alot less now that I’ve moved to endeavour from fedora. The AUR is a godsend.
Also flatpak doesn’t add to dependency hell, the dependencies it installs are also flatpaks and are completely separate from the system. Recently the arch package of steam simply stopped launching proton games for some reason, I thought I messed something up on my system so I rolled to an old btrfs snapshot and it still didn’t work. However the flatpak version of steam just works.
Do you realize why is that? That Dev will build the package once lifetime and dont give a shit about proper testing nor updating libraries. And your home dir is probably exposed to this buggy craphole.
openqa.opensuse.orgThis is what an update goes through when a proper QA process is applied in a standard distro packaging system. This is what flatpak does not ever comes close to. Flatpak is just windows approach ported to linux. Quality and trust comes from package to package and can vary from good to dogwater.
Btw not sure you realize you are complaining about broken package on bleeding edge distro.
Lmao, why are you so agressive? It’s a packaging format not bloody politics. I never complained about anything, I stated that one package format was broken and the flatpak wasn’t. The mere existence of flatpaks does not and will never threaten the traditional packaging method, or it’s QA. Flatpaks merely provide smaller developers an easy way to get their application published, as well as end users a stress free way to install said apps. And yes, they can range from good to dogshit, that comes with the territory of leaving it entirely up to the publishers, but I think Linux users are capable of identifying which flatpaks are dogshit and which aren’t. Also what do you mean my home dir is probably exposed? Like it isn’t exposed when I install a regular package? Remember the steam bug that just completely wiped your install because they made an assumption with a single variable? Buggy software will always exist, at least with flatpak you can limit an apps access to your system
Please stop projecting on others, that would be nice.
Yes, your home is exposed on both sides. One side tested in proper QA, the other in “trust me bro” env. Lol…. one moment you say that bugs happen and right after that you generalize everything based on one shit that happened on steam package. First you say you are not complaining about anything but then you go to “flatpak better!!!”. Fisrt you say flatpak security is good and when you should back your claims you go with “Linux users detect bugs and security holes very good. Of course they do… after the system goes tits up :D
So… either please stop talking nonsense or present some facts that try to back that nonsense at least.
Flatpak is a last resort. Only used when the package is not available on the repository or the version is too out of sync with the environment. If I really really need to run the latest version of that software, it’s easy to run a Flatpak. But that is only and exclusively for final user software, never for services or background running application, or a new can of worms is opened.
Add comment