Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Autodesk-Fusion-360-for-Linux
This is a project, where I give you a way to use Autodesk Fusion 360 on Linux!
-
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
This looks great, I love the clean GTK for this user interface. Say what you will about GTK and Gnome... for beginners on an operating system such as Ubuntu, having a consistent application concept is very important.
Curious how this compares to Lutris[1]. I can see it has support for it as a runner, however as far as I can tell it achieves the same thing by maintaining separate wineprefixes.
[1] https://lutris.net/
It looks like the only officially supported program that isn't a game is amazon music [1]. The main project for running windows on Linux has a partially working distribution of Office 365. My impression is that it sometimes works with significant manual effort, wouldn't be reliable enough to depend on without a backup system [2].
When I need Office apps to communicate with clients I use a combination of Google Docs download as docx, Office Online, and a VM.
[1]: https://github.com/bottlesdevs/programs
I was going to point to the WineHQ AppDB also but the person most active in updating the Fusion360 entry seems to be working on this. https://github.com/cryinkfly/Autodesk-Fusion-360-for-Linux It looks like it's been fairly active over the past year so it's probably what I would start with to get Fusion running.
Wow! I can't believe I've never noticed that. For many years, the only graphical installation disk was based on Plasma, and I think it also had that tag. NixOS only started shipping a GNOME iso for installation purposes a little over a year ago (for 20.09), and I kinda never noticed.
Looks like the main reason GNOME is recommended for installation media at the moment is that it does a better job of autodetecting HiDPI displays, and then scaling appropriately: https://github.com/NixOS/nixos-homepage/pull/643
There are also some packaging issues for Qt with NixOS, because Qt plugins fundamentally rely on ‘impurity’ at runtime, and the Qt framework makes promises it doesn't keep about binary compatibility.
Here are some of the relevant issues for historical context and some of the tradeoffs Nixpkgs developers have faced when it comes to handling Qt and KDE packaging:
https://github.com/NixOS/nixpkgs/issues/86369
https://github.com/NixOS/nixpkgs/pull/54525
https://github.com/NixOS/nixpkgs/pull/44047
I realize that may not be a fully satisfying answer as to why the GNOME-based installation graphical ISO is recommended over the Qt one because one can imagine that the Qt packaging issue should be resolved some other way, or see the difficulty of packaging Qt plugins and applications in Nixpkgs as fundamentally a Nix defect. But I hope it makes that decision make more sense.
FWIW, afaict Plasma is the more popular of the two major DEs on NixOS, and it's what I've always used on NixOS myself, including now. It is definitely usable.
Wow! I can't believe I've never noticed that. For many years, the only graphical installation disk was based on Plasma, and I think it also had that tag. NixOS only started shipping a GNOME iso for installation purposes a little over a year ago (for 20.09), and I kinda never noticed.
Looks like the main reason GNOME is recommended for installation media at the moment is that it does a better job of autodetecting HiDPI displays, and then scaling appropriately: https://github.com/NixOS/nixos-homepage/pull/643
There are also some packaging issues for Qt with NixOS, because Qt plugins fundamentally rely on ‘impurity’ at runtime, and the Qt framework makes promises it doesn't keep about binary compatibility.
Here are some of the relevant issues for historical context and some of the tradeoffs Nixpkgs developers have faced when it comes to handling Qt and KDE packaging:
https://github.com/NixOS/nixpkgs/issues/86369
https://github.com/NixOS/nixpkgs/pull/54525
https://github.com/NixOS/nixpkgs/pull/44047
I realize that may not be a fully satisfying answer as to why the GNOME-based installation graphical ISO is recommended over the Qt one because one can imagine that the Qt packaging issue should be resolved some other way, or see the difficulty of packaging Qt plugins and applications in Nixpkgs as fundamentally a Nix defect. But I hope it makes that decision make more sense.
FWIW, afaict Plasma is the more popular of the two major DEs on NixOS, and it's what I've always used on NixOS myself, including now. It is definitely usable.
To get decent software management on macOS, you end up having to build automation on top of the AppBundle system, and what is required for every package can be totally custom. Homebrew Casks are neater than something like Chocolatey, but they're essentially the same kind of wrapper around custom install tools which come from publishers and can basically do whatever they want. (Casks get to be neater and faster because the AppBundle design almost works, so most .pkg installers only do a few extra things around the edges.)
Something like Flatpak can address the problems with AppBundles in a way that clones like AppImage can't.
That said, this:
> Keep runtimes in "installations" and let applications exists as single-directory self-contained units wherever the user wants them. What is fundamentally difficult about this?
basically sounds okay to me and I don't see why it couldn't be done. (Although I don't really like the idea of Flatpak applications being distributed as files becoming popular, because I'd rather developers submit their apps to Flathub or somewhere similar so that they're still usable via remote management tools.)
> It's weird that when you criticize something in Linux Desktop, for some reason its proponents always go all whataboutism on Windows.
You mentioned that Windows is the desktop operating system you're currently using, so it seems Windows' application management norms must be acceptable to you. I thought about including a section about the case on macOS (similar to the one in this comment), but I didn't do so because you mentioned Windows and not macOS in your original comment here.
—————
0: https://formulae.brew.sh/cask/
1: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/ad...
> Seriously, more bugs than Wine?
It was mostly tongue in cheek, but a quick search reveals that Flatpak has 650+ open issues[0] which is kinda insane for a package manager that's supposed to be more secure than it's contemporaries. For comparison, pacman, one of the most notoriously unstable and reckless package managers, has only 137 issues.
> for the FIRST TIME in Linux history there is people packaging an application and it works exactly the same everywhere
This is just plainly untrue. Portable formats like AppImage did this for years before Flatpak was even conceived. Furthermore, static linking has been possible on Linux for decades, so when I hear this argument that containerization is the only way forwards, my eyes sorta glaze over.
> and some can only meet this achievement by unpaid volunteers with _snark_ because it's not "perfect".
Well, yeah. They're pushing it as a finished product, they're marketing it as "the best way" to use the software, when Bottles literally has features that straight-up don't work in Flatpak. So, not only does it not work exactly the same as it's contemporaries, it's arguably a downgrade from traditional packages. No package manager is (or will be) perfect, but if your "next gen" software fails to compete with functionality from decades ago then yeah, I will call you on it.
> It's tiring to see any effort to make the Linux desktop a reality met with unconstructive opposition from daily Linux desktop users.
The Linux desktop is a reality, it has been since the 90s. I suspect when you say "any effort" you're exclusively referring to the GNOME developers and their push to 'unify' the Linux world under their desktop. There have been plenty of cross-system efforts that turned out just fine, take PipeWire for example; they had the herculean task of unifying 4 different audio backends into one interface, and they pulled it off, released a feature-complete, stable build on day-1. Meanwhile, projects like Wayland, Flatpak, GTK4, GNOME 40, and many more 'contemporary' desktop Linux projects flounder around for years on end, with neither developers who want to touch the code or users who want to brave the bugs they offer.
I'm not going to stop you from using Flatpak, that's your ordeal and I want nothing to do with it. But if you think I'm going to ignore it's issues? Your time would be better spent making pull requests instead of online rants, if you feel that strongly on the topic. Otherwise, Flatpak will continue to be a second-class citizen in the package management world.
[0] https://github.com/flatpak/flatpak/issues
1. Those will probably use SDL which has got support for wayland CSD: https://github.com/libsdl-org/SDL/pull/4068
2. Wine apps will probably have to draw the win32 decorations. Native apps can implement their on decorations or can use GTK or Qt to draw their decorations.
3. Qt does have its own CSD decorations but most of those are Electron apps. Electron has a PR open for CSD: https://github.com/electron/electron/pull/29618
A system tray can be added to GNOME with an extension.
4. GTK is not a cross platform toolkit like Qt where it tries to draw everything with native widgets, but it is a portable toolkit meaning that you can port applications to other platforms and they will more or less look the same. I don't know anyone using it ship Windows applications, some improvements have been made to get it working better on Windows though: https://www.collabora.com/news-and-blog/blog/2021/03/18/buil...
1. Those will probably use SDL which has got support for wayland CSD: https://github.com/libsdl-org/SDL/pull/4068
2. Wine apps will probably have to draw the win32 decorations. Native apps can implement their on decorations or can use GTK or Qt to draw their decorations.
3. Qt does have its own CSD decorations but most of those are Electron apps. Electron has a PR open for CSD: https://github.com/electron/electron/pull/29618
A system tray can be added to GNOME with an extension.
4. GTK is not a cross platform toolkit like Qt where it tries to draw everything with native widgets, but it is a portable toolkit meaning that you can port applications to other platforms and they will more or less look the same. I don't know anyone using it ship Windows applications, some improvements have been made to get it working better on Windows though: https://www.collabora.com/news-and-blog/blog/2021/03/18/buil...