It's a shame winepak never really took off https://www.winepak.org/
To make this clear, there hasn't been much activity since 2018: https://github.com/winepak/winepak
To make this clear, there hasn't been much activity since 2018: https://github.com/winepak/winepak
EDIT: nevermind...
$ flatpak remote-add --if-not-exists winepak https://dl.winepak.org/repo/winepak.flatpakrepo
error: Signature made Fri 20 Jul 2018 03:30:34 BST using RSA key ID A959831C080B608F
BAD signature from " <julian@richen.io>"
Key expired Tue 09 Jun 2020 19:16:34 BSTI don't have much interest in windows apps, but I wouldn't mind donating a bit of money (as opposed to free time) to the project.
Edit: https://github.com/winepak/winepak/issues/23#issuecomment-64...
> The biggest issue with winepak, which is why I haven't been working on it, is that it all revolves around me building things instead of a remote server doing it and having people contribute. I really just need to get the buildbot & sdk in a place that it can auto build an push out. Then it can do all the signing and building again and this shouldn't happen. I just need to find the time.
Maybe a few PR around automation, and/or donated CI runtime could help a whole lot?
Honestly, I don't even care to entertain this discussion, as for the FIRST TIME in Linux history there is people packaging an application and it works exactly the same everywhere, and some can only meet this achievement by unpaid volunteers with _snark_ because it's not "perfect".
It's tiring to see any effort to make the Linux desktop a reality met with unconstructive opposition from daily Linux desktop users.
/rant
Nowhere in my comment I said Flatpak is perfect and doesn't need more work to be really good, and I certainly didn't resort to hyperbole to discredit the work of other people, that's for sure.
I should probably take a walk and not angrily comment on the Internet, I agree...
For end users its meant slower startup, apps that ignore user themes, concern that a rogue developer will poison the well with outright malware, concern that a legit developer will get hacked and instantly disseminate malware to all users with their flatpak installed, flatpak only bugs, permissions issues, and additional complexity in managing software.
For developers who already have their software widely available via traditional packaging its something else they have to do in addition to traditional packaging not an alternative because its not universal. In fact last year only a single digit percentage said they used it.
If your prospective users aren't excited about your product perhaps one needs to reconsider if its the users fault for not being excited.
1. Proprietary software: most proprietary software authors do not play well with packagers. Moreover, I want any proprietary software properly sandboxed
2. Software that you need sandboxed for various reasons: I've been running flatpak nightlies of stuff I otherwise have installed on my system
3. Installing a program without installing a whole bunch of dependencies, hard to clean up after
4. Cleaning up my home directory
Sandboxing (I know most flathub packages have leaky sandboxes, but that's a start) limits the effect of compromising one flatpak. To be clear: I treat any piece of proprietary software as a possible RCE by the author.
User themes issues are probably fixable.
Slower startup as well, to an extent.
Unfortunately, developers are pretty bad at packaging generally, and don't have distro maintainers watching over their CVEs and upgrading dependencies with the flatpak model... Although users could still dig in and fix these by themselves, and sandboxing still gives a few protections.
In order:
1. Filesystem access is one of the most critical pieces (to me). Flatpaks on flathub often restricts this by default, except for a few packages. Portal mechanisms offer on-demand access to external files and folders.
2. X11 access: I use wayland, and make sure the program I'm launching does too. There is a X11-fallback scheme that blocks access to X11 if wayland is being used.
3. Network access: I usually leave it enabled when needed, there is not much to exfiltrate if filesystem isn't accessible, and that's the main threat I'm concerned about.
I am not very concerned with Pulseaudio, pipewire socket or access to select D-Bus paths.
Sure, it is not an air-gapped computer, nor a virtual machine. The attack surface is bigger, but not that much.
They are thereby incentivized to attack via a method that is successful on their test systems. In particular applications set their own initial permissions (can they also update themselves and acquire greater permissions without user input?) and often contain old outdated and potentially insecure known insecure versions of software already patched or updated in distro repos.
If you put up $1000 and offered to install any malicious app on a current fedora gnome default install VM and see if someone could pwn it your money would be gone in a few hours. You could do this once a month between now and 2025 and I would be surprised if you were ever able to retain your money.