kirk781Linux is the reason Windows apps are bloated these days
Lembot_0006Why did you cut out the author’s name? :)
It is a generic one at a forum. The screenshot is from the comment section of Windows Latest site.
Back in the day on Reddit, some subs had a rule where names had to be blurred or removed. Since then, it is reflex for me to just cut out the author’s name (not that it mattered in this specific case).
I found the article and the comment, if you’re curious:
Onno (VK6FLAB)Wow, that’s some serious misinformation.
Screenshot might have been taken early
Who is Tod and why are we thanking him?
Welp, that’s an opinion one can have. whatyoujustsaid.gif
MoogleMaestroElectron is the only cross platform gui toolkit…
If you ignore QT, GTK and everything else.
I’m so glad that Microsoft makes an awesome cross platfor— wait, no, but they contribute code to— hmmm … Hey, what does Microsoft do to make apps more portable again?
The real reasons often are:
- They want be able to hire much cheaper webdevs instead of software devs.
- Electron has a lot of built-in data collecting metrics, which they urgently need for creating a real-life KITT.
Also a lot of Windows-only apps are Electron apps, only because the manufacturer wants to go “fuck you”, even putting protections into the code just in case you wanted to run it on Linux.
Flax
nymnympseudonymFlatpak
AppImage
Snap
Hell, let’s not forget
Python
Perl
Java
POSIX
teolanAlso each is pretty bad in terms of usability and practicality, either losing integration because “containerized” or taking GBs of space or both
NatanoxAppImages can get quite large because each app is self-contained, but the “losing integration” part is nonsense these days for any of these formars. That’s why we have portals, and if those aren’t enough you can still give the app full permissions.
Appimages are usually quite reasonable in size, it’s Flatpak that usually require 2/3 GB per app since every package has its own version of KDE/Gnome or other runtimes so every app still has to download a new one.
That’s simply not true, if the required dependencies are already downloaded they get used by every Flatpak app. If you have three apps requiring the Gnome 46 libs those only exist once.
I don’t know where this myth about Flatpaks always being gigabytes in size originates from or why it’s so persistent, but it’s wrong.
I’m not saying that’s not true.
I’m saying I’ve almost never downloaded a Flatpak that didn’t require a new dependency downloaded.
When I removed all my flatpk some time ago, I had: Steam, Viking, Discord, FreeCad and Flatseal to manage them. All of them and their dependencies used something arounx 17 GB of disk space (most of which was of course several versions of dependency runtimes), and that was after I removed all the unused runtimes that forn some reason it doesn’t remove after I uninstall or they are upgraded.
I’m sure if I installed more Flatpaks, some dependencies would eventually be reused, but you still need a good collection of them at any given time. So in pracrice you still need a lot lf space unfortunately.
I don’t know where this myth about Flatpaks always being gigabytes in size originates from or why it’s so persistent, but it’s wrong.
Alright, here is ~25 GUI apps flatpak vs appimage:
- 6 GiB flatpak.
- 2.7 GIB appimage.
If you do not have such filesystem (ext4), then it is more like 15 GIB vs 2.9 GiB lol.
This comparison is missing the flatpak equivalents of kdeconnect, deadbeef and a few CLI tools that I have on right btw, flatpak-dedup-checker for some reason doesn’t check the /var/lib/flatpak/repo directory which is usually another +1GiB in best case scenario.
losing integration because “containerized”
Bollocks. I’ve seen that many times with Flatpak (can’t speak for Snap), and every single time it was either because the packager failed to set up permissions or because the user messed with permissions that the application needed. Break off the tip of a screwdriver and it will no longer function as a screwdriver.
And I know you’re talking out of your ass because AppImage isn’t even sandboxed.
taking GBs of space
That part is true and accurate, and for a very good reason: dependency pinning. System packages can break if they don’t have the correct versions of shared libraries. If a package requires a very old version of a library, and doesn’t link it statically or supply it with the package, it can misbehave, have missing features, or refuse to even start. Flatpak (and probably Snap too, can’t speak for it) solves that by letting the packager specify (pin) the exact version of a dependency. If five separate packages require five different versions of the GNOME application framework, then they will download five separate packages of the correct version. AppImage solves it by being monolithic: everything is packaged together into a single executable.
I don’t know if it’s still the case, but up to a couple of years ago, Flatpak was configured so that externally mounted folders were not accessible. I discovered that when Steam on flatpak refused to install games on my hdd, and it was quite frustrating to figure out how to enable it.
Snaps integration is even worse as I’ve seen browser extensions state they straight don’t work on snap’s browsers. Also desktop integration on gnone (even files drag and drop between snaps) are broken on the ubuntu installations I tried.
yet they still miss a central package repository, and that’s a big problem.
GitHub - ivan-hc/AM: AppImage Package Manager: AppImage sandboxing, local and system installation, update all AppImages, an extensible database of AppImages and portable apps, lists for AppImages and other GNU/Linux binaries, integrate AppImages by drag/drop or install unlisted AppImages, conversion of old AppImage types... and more! Manage AppImages like never before!
AppImage Package Manager: AppImage sandboxing, local and system installation, update all AppImages, an extensible database of AppImages and portable apps, lists for AppImages and other GNU/Linux bi...
It’s a package repository, but I would hardly call it “central”
Well, upstream is now considering either merging or just pointing to the AM repository because it is bigger and better maintained.
That’s good, AppImage is still my favourite of the “distro-agnostic” package systems and I think it really is missing a central repository solution.
losing integration because “containerized”
Bollocks. I’ve seen that many times with Flatpak (can’t speak for Snap), and every single time it was either because the packager failed to set up permissions or because the user messed with permissions that the application needed. Break off the tip of a screwdriver and it will no longer function as a screwdriver.
Well then I guess you haven’t tried to get a password manager like KeepassXC to work with a Flatpak browser, because none of the solutions I’ve seen are “fix the permissions”.
From what I’ve read it seems you shouldn’t run a browser as a flatpak anyway, as this somehow weakens the built-in isolation.
I think I originally read about this somewhere librewolf-related but can’t seem to find it now.
I did find this similar discussion: https://discuss.privacyguides.net/t/correct-way-to-install-browsers-on-linux-securely/27046/6
Correct way to install browsers on Linux securely?
Does not interfere with the sandbox You can use Snaps on other distros, for example on Arch. Simply layer the browser with ostree or similar. That’s not always true. There is an official Flatpak for Firefox, yet it does not have the same sandboxing as via non-Flatpak installation. Same for Tor Browser Launcher Flatpak.
GTK is not accessible anywhere other than Linux and is therefore not a serious option outside of Linux.
XenGiI said accessible not available. If you don’t know what it means, accessibility means integrating with the OS screen readers and other similar tools so that everyone can use your app, not only people by people with good eyesight, and capable of using a mouse.
I mean… Windows could probably contribute to GTK if they wanted to expose their accessibility APIs. This would in theory be a good use of time.
It is. It’s just not particularly good outside of a X11/Wayland environment.
I think this being worked on though.
mittorn@jollyrogue @XenGi it is not particularly good outside of Gnome environment
Gtk2 and Gtk3 is fine outside of gnome. Gtk4 especially with Libadwaita is heavily focused on Gnome.
@XenGi while gtk2 can be adapted to qt/kde/win/mac look&feel with theme engines, gtk3 does not support it anymore and will work outside gnome, but will not look good. Yes, it's possible to make css theme, but this will require much work to manually adapt every theme to gtk3/css, and moreover, may break on updates. Most of Redmond-like gtk3 theme implementations are broken now and even actually supported themes looks partially broken. Ideas like "Please don’t theme our apps" makes situation even worse, they literally want turn desktop to some inconsistent zoo.
lime!one of the funniest (and sadly accurate) things i’ve heard said about linux backwards-compatibility is that its most stable API is Win32. you can run really old windows software on wine because they support stuff even windows doesn’t anymore.
of course this is because the expectation is that you can just recompile old software to work on new systems, which is not really a thing on window.s
The most stable system is one that is out of support. No updates == No breakage! 😄
I Cast FistLazarus gang, this is your chance!
DacoTaco.net
.net cli apps are cross platform and can be portable :p
Gui in .net isnt fully cross platform ( maui is everything except linux ) but frameworks like avalonia and imgui fix all that :')
.net cli apps are cross platform and can be portable :p
Gui in .net isnt fully cross platform ( maui is everything except linux ) but frameworks like avalonia and imgui fix all that :')
Thanks for reminding me why Maui doesn’t support Linux. I saw Maui mentioned in an earlier comment and was naffled why KDE would make something not working that doesn’t work in Linux.
It’s because Microsoft stole the Maui name from KDE:
www.phoronix.com/news/Microsoft-KDE-MAUI
Microsoft And A KDE Project Spar Over "MAUI"
A few years ago it was GNOME developers frustrated with Microsoft over naming a project GVFS (later renamed to Virtual File System for Git) as it collided with their GVFS (GNOME Virtual File-System) while now there is a similar situation brewing between Microsoft and KDE camps.
@DacoTaco @MoogleMaestro there is a port of mono winforms implementation to modern dotnet and it's really works:
https://github.com/DanielVanNoord/System.Windows.Forms
https://github.com/DanielVanNoord/System.Windows.Forms
GitHub - DanielVanNoord/System.Windows.Forms: A .Net Core implementation of System.Windows.Forms based on Mono's System.Windows.Forms for Linux and Windows
A .Net Core implementation of System.Windows.Forms based on Mono's System.Windows.Forms for Linux and Windows - DanielVanNoord/System.Windows.Forms
Winforms of all things haha. Eeuw xD
But thats flipping awesome! I know xamarin was wpf being cross platform with mono, but thats a dead horse thanks to microsoft haha
But thats flipping awesome! I know xamarin was wpf being cross platform with mono, but thats a dead horse thanks to microsoft haha
@DacoTaco Yes, it's Microsoft decided to kill classic win32 widgets and any XAML support in Mono, forcing new WinRT platform and not providing any GUI support in netcore. It's sad that nobody made some crossplatform WPF implementation for modern dotnet, Maui is not incompatible with existing source code, IIRC
It’s sad that nobody made some crossplatform WPF implementation for modern dotnet
That’s basically Avalonia UI. I believe Uno Platform is similar, but less of a WPF variant, and closer to Xamarin or MAUI in the style of Xaml that they use.
@hdsrob
>That’s basically Avalonia UI.
no, avalonia cannot help you run existing applications. Also. Avalonia is a crap, taking minutes to parse xml crap on poor hardware
Yes, there are many implementaion of WPF-like UI, but no implementation of existing Windows UI.
mono's winforms allows you run existing winforms apps without single line change or even without recompiling (just replace related System.Windows.* assembies)
>That’s basically Avalonia UI.
no, avalonia cannot help you run existing applications. Also. Avalonia is a crap, taking minutes to parse xml crap on poor hardware
Yes, there are many implementaion of WPF-like UI, but no implementation of existing Windows UI.
mono's winforms allows you run existing winforms apps without single line change or even without recompiling (just replace related System.Windows.* assembies)
Nope. The ui framework doesnt support linux at all. None of its cross platform claases and enums have linux. Its stupid because .net and aspcore just work on linux…
Android, iOS, iPadOS, macOS, and Windows
Everything but Linux, that’s funny.
I look at MAUI a year or so ago and IIRC, “official” Linux support was made by the community.
GitHub - dotnet/maui: .NET MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop.
.NET MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop. - dotnet/maui