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.
>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.
Consistency is important but is not like the majority of the apps are GTK3 (or whatever is latest) with the GNOME styles even if those GNOME designers pretend nothing else exists and nobody should remove the GNOME branding from the GNOME apps.
Just want to mention that GNOME are the bad guys, KDE distributions will provide GNOME integration with packages and themes that attempt to keep Qt and GTK application consistent in look and feel but I never seen GNOME distros attempt to integrate with the non-GNOME apps.
They're making their desktop environment and apps into a walled garden on a platform like Linux. Most GTK4 apps won't be usable outside the intended desktop environment for which they're built.
They also engage in carefully crafted doublespeak when it comes to things like extensions and user choice regarding configuration.
Call it what you want but they certainly don't intend to play nice with anyone and have adopted the approach of "my way or the highway". Perhaps they're emboldened by all the corporate backing they have from Red Hat and SUSE. They also have the advantage of being the default DE on most distros. Hell, even distros like NixOS encourage users to use GNOME, which is absolutely insane when you think about it.
> Most GTK4 apps won't be usable outside the intended desktop environment for which they're built.
There have always been apps more heavily integrated with GNOME vs GTK apps.
Gtk4 is easier to port to other platforms, if anything it should be less painful than it has been before.
> Gtk4 is easier to port to other platforms, if anything it should be less painful than it has been before.
Oh, how desperately I wish this were true. My evidence is purely anecdotal, but I've found GTK4 to be almost completely unusable in my time working with it, so much so that I've basically decided to skip this release altogether and just stick with GTK3 for all intents and purposes. It started when I wanted to pull my Glade projects in to the new framework so I can build my apps with XML instead of writing it by hand... oops, that method has been unsupported. But don't worry! There's a replacement app right around the corner that's... not finished yet. Okay, I guess that's not a big deal, I'll just re-write everything by hand! Now it's compiling and doesn't look the least bit native on my system. And there are compositor issues. And the text looks ass-ugly too.
Asking around on IRC, I was told everything from "use Flatpak" to "stop trolling" to "your workflow is unhealthy/insane/unsupported". It would appear that GTK4 is only intended for GNOME extremists, unfortunately. If there are any portability improvements I won't likely see them.
If you depend on having a GUI builder then I agree it makes sense to wait for that to be stable before switching to GTK4. It's being worked on but progress is slow because of a severe lack of contributors. I don't know anything about compositor issues but it's aimed to give the text a substantial fix in GTK 4.6.
>I was told everything from "use Flatpak" to "stop trolling" to "your workflow is unhealthy/insane/unsupported". It would appear that GTK4 is only intended for GNOME extremists,
I don't see how that has anything to do with "extremists". The GNOME IRC is probably a bad place to ask for help with distro packaging, the focus is on Flatpak because that's realistically the only distro-agnostic packaging that upstream can support. For help with packaging apps for your distro you'd have better luck asking on your distro's IRC.
> If you depend on having a GUI builder then I agree it makes sense to wait for that to be stable before switching to GTK4.
Correction: traditional XML stylesheets were removed with the release of GTK4 so they could introduce a new paradigm, one that was not ready to replace it. I really don't know what to tell you here, because it's such a vast departure that it's going to make the porting process to GTK4 nearly impossible for most people. It's such a braindead, no-holds-barred move that it simply feels disgusting to me. Here we had this perfectly functional feature, and the GNOME devs, being the impractical idealists they are, said "let's get rid of it, offer a replacement and not develop the replacement". Same thing happened with LibAdwaita, GNOME 40 and pretty much everything else they seek to """improve""".
> It's being worked on but progress is slow because of a severe lack of contributors.
Who's fault is that? Is it the aggressive, unfriendly leadership? Or maybe it's the GNOME superstar celebrities, who make completely bonkers changes and expect the rest of the community to follow their lead without question? Maybe it's the lack of directive in their issue trackers, where their lead contributors decide to waffle on major issues instead of taking the directive to just shave the damn yak?
I don't care that they lack contributors. I really don't. That's a grave they've dug for themselves by ostracizing the rest of the community, and it's one they're going to have to deal with for years to come. They had opportunities to build bridges, and they tore them down. They harassed other distribution maintainers when they tried offering help of their own. They've shot themselves in the foot here, plain and simple. GTK2 and 3 weren't remotely this bad or unusable at launch, and it just makes me sad to see people clinging to elitism instead of pragmatism when building an inclusive, accessible desktop. If their ship is sinking, I'm perfectly contented to stay onboard GTK3 and watch as they sink beneath the surface. Several people said this was a bad idea, but it was their hubris that ultimately ruined GTK4. If they need "extra contributors" to fix that, then they should have thought about that before telling everyone else to screw off.
> The GNOME IRC is probably a bad place to ask for help with distro packaging
1. I was in freenode.
2. I wasn't asking about packaging.
My concern was getting my app to look right on every desktop that it ran on, which it most clearly did not. The text was distorted and completely unacceptable for distribution, there were black bars drawn around the window on half the desktops I tried it on, and the look-and-feel was inconsistent across systems. Utterly unbelievable for a toolkit that was trying to pride itself on accessibility.
> the focus is on Flatpak because that's realistically the only distro-agnostic packaging that upstream can support
The issue is that they don't even support that. Flatpak has over 600 open issues of it's own, and implementing it can oftentimes lead to more work, nonfunctional features (like distro-native features in Bottles, for example) and infinite bikeshedding. Every argument I've seen for using Flatpak is bogus. Every one. You can cry "it needs more maintainers!" and I'll probably agree with you, but it's become such a politicized and broken mess that, once again, very few people see the value to contributing to it anymore. Mark my words (and you're welcome to call me out when I'm inevitably wrong here): Flatpak will never get "finished". It has too many esoteric features, unfixable bugs and ideological missteps to compete with package managers that existed just fine 20 years ago.
>Correction: traditional XML stylesheets were removed with the release of GTK4 so they could introduce a new paradigm, one that was not ready to replace it.
Not really, the XML format is pretty similar. In my experience it works very well, even better than the GTK3 XML, but yes it's lacking a good GUI builder.
>I really don't know what to tell you here, because it's such a vast departure that it's going to make the porting process to GTK4 nearly impossible for most people.
I can't agree, I've talked to some GNOME developers and they don't have much of a problem with it. Glade on GTK3 is not very popular among GNOME developers anyway because it causes some other issues, hopefully those will be fixed with the new GUI builder too.
>said "let's get rid of it, offer a replacement and not develop the replacement". Same thing happened with LibAdwaita, GNOME 40 and pretty much everything else they seek to """improve""".
I'm very confused to what you're saying, there are replacements for all that being developed, but it takes time to do it.
>Who's fault is that? Is it the aggressive, unfriendly leadership? Or maybe it's the GNOME superstar celebrities, who make completely bonkers changes and expect the rest of the community to follow their lead without question?
I'm also very confused what you're talking about, I've talked to the Juan (the person working on the new GUI builder) and he's a pretty nice guy working as hard as he can. I've never seen him harass or ostracize anyone or refuse questions. You're generalizing and I wish you wouldn't do that, it's rude to the people who work hard on this and offer no ill will. I've never seen any aggressive leadership or superstar celebrities there either, this is mostly self-directed volunteers working in their area of interest.
>If their ship is sinking, I'm perfectly contented to stay onboard GTK3 and watch as they sink beneath the surface. Several people said this was a bad idea, but it was their hubris that ultimately ruined GTK4.
Well you lose some other improvements in GTK4 if you do this. Those improvements are very unlikely to be brought to GTK3 because they needed an API change. That's why it's a bad idea. Of course you can continue to use GTK3 if you want but you'll continue to miss out on those improvements. It's up to you to say how long you'll be OK with that, but you should know upstream has said that GTK3 will not gain any new features anymore.
>If they need "extra contributors" to fix that, then they should have thought about that before telling everyone else to screw off.
I don't know who was told to screw off, there are open calls for contributors in all these areas.
>I was in freenode.
Well Freenode is not the GNOME IRC so I have no idea what this has to do with GNOME or GTK. Yes there are trolls and unhelpful people in random freenode channels, I never used freenode much myself for that reason. GNOME has its own IRC server, and actually I think they switched to Matrix recently.
>The issue is that they don't even support that. Flatpak has over 600 open issues of it's own, and implementing it can oftentimes lead to more work, nonfunctional features (like distro-native features in Bottles, for example) and infinite bikeshedding.
I know about some of these issues and I'm personally affected by them but what you're missing is that there is actually no other option. Getting rid of Flatpak would leave them with no real way to deploy these apps at all. It's a choice between something buggy that's being worked on (slowly) and leaving app developers out in the cold with nothing. Distro package managers don't solve the problem, they created the whole problem that Flatpak exists to solve.
I'm not going to stop you from pretending like nothing is wrong if that's your prerogative. I'm letting you know here and now that there is an expanding sentiment among developers that GTK4 is a regression from GTK3, and if there are any improvements coming down the pipeline I have yet to see them. I'm not going to argue with you about this when my app is irreparably broken right now, though. Every attempt I've made to reach out to developers has either gone cold or been rejected. I fully intended to start contributing to GTK back in the v3 days, but now? The current leadership has made it clear that they don't have my best interests at mind. They'd rather scrap everything I used and promise a replacement instead of iterating on it or fixing it, which is unacceptable for a toolkit that is currently in active use. I refuse to donate my time or effort to people who disrespect me like that.
I'm a pragmatist, not an idealist. Promises mean very little, especially coming from the modern GTK team.
>I'm not going to stop you from pretending like nothing is wrong if that's your prerogative.
Please don't jump to this conclusion, I'm not doing that. If some GTK3 users want to continue developing GTK3 or use some other toolkit then that's absolutely fine with me. I said that before, I could even recommend some other toolkits for you to use. But I think it's a bad idea to view GTK3 as some kind of resistance against GTK4 because that's missing out on many years of improvements that would be very difficult to backport. Yes there are bugs in GTK4, but I've also talked to the developers and they are aware of them and are working on solving the issues even if progress seems slow. You can read some of the GTK4 blogs to see some of the enhancements that were made in GTK4 and decide if they're worth it to you or not: https://blog.gtk.org/2020/12/16/gtk-4-0/
>I'm letting you know here and now that there is an expanding sentiment among developers that GTK4 is a regression from GTK3
This is not really surprising or new or that much of a big deal, people complained when GTK2 was released because it changed stuff from GTK1, then they complained when GTK3 was released because it changed stuff from GTK2. It's totally understandable and normal for some to want to avoid or delay making the switch, but many others have been willing to make it for the improvements.
>Every attempt I've made to reach out to developers has either gone cold or been rejected. The current leadership has made it clear that they don't have my best interests at mind.
Well if you were on freenode then those probably weren't the upstream developers or any of the current project leadership so I think you might have a wrong impression; you're saying a whole lot of negative things but the underlying logic just doesn't really add up to me. I'm not interested to argue with you either, if you can just mention what the issue is with your app I might be able to help you.
>They'd rather scrap everything I used and promise a replacement instead of iterating on it or fixing it, which is unacceptable for a toolkit that is currently in active use.
This statement is also confusing to me, the replacement is the iteration and fixing. It's being worked on. It can't really be any other way, Glade is a very old application from the GNOME 1 days that's been continuously ported and it still inherits some old design flaws from that. To finally fix the design flaws the program needs some major breakage or a rewrite, so they decided to go with the rewrite because it's actually easier than hacking apart all the internals of Glade and breaking the whole program. And by "they" I mean the one person who has been working on Glade for the last few years and is now working on the replacement. I don't know what "promise" you're talking about either, I think it's a bad situation that only one person is working on this. He could stop working on it at any time and then you'd have no GUI builder at all, the "bus factor" on these projects is a concern right now.
>I refuse to donate my time or effort to people who disrespect me like that.
I'm not suggesting you do that, it seems more like you were asking about taking time or effort to fix your own application.
>There have always been apps more heavily integrated with GNOME vs GTK apps.
From my experience GTK2 apps were not "GNOME" apps, like there were many apps that did not installed the entire GNOME dependencies to work, I don't know if this changed lately since I so far only had the need for qt or GTK2 apps.
That's more because GNOME has completely dropped GTK2 while other projects continue to use it. In the past that wasn't true, GNOME 2 apps depended on a separate library called libgnomeui that had widgets specific to GNOME 2. All the actively-developed GNOME apps ported to GTK3 long ago and so they dropped that dependency which is why you don't see it anymore. The only apps left using GTK2 are non-GNOME apps and so they never depended on that in the first place.
>They're making their desktop environment and apps into a walled garden on a platform like Linux.
This is a rather empty statement as all these apps and the whole platform still continue to be open source.
>Call it what you want but they certainly don't intend to play nice with anyone and have adopted the approach of "my way or the highway"
I don't see how this is any different from how it was before. I've also found that KDE apps don't really work well outside of KDE, XFCE apps don't really work well outside of XFCE, etc. There is a clear line where an app developer has to decide if they're making a cross platform app (like LibreOffice, Blender, etc) or if they're making an app that integrates with a specific platform. Every single desktop I've ever seen has drawn this line somewhere because this is what users want, a KDE user prefers to use the KDE file manager and finds the GNOME file manager not so usable, a GNOME user prefers to use the GNOME file manager and finds the KDE file manager not so usable, etc.
>Most GTK4 apps won't be usable outside the intended desktop environment for which they're built.
I think you're confusing GTK4 with libadwaita, libadwaita is the library for GNOME apps that are only tested with GNOME and don't intend to be used outside it. GTK4 itself is not tied to any environment. And even then a developer could likely get libadwaita apps to work reasonably well in other environments with some porting work, similarly to how Krita depends on some KDE widgets and libraries but has been ported to other platforms.
>They also engage in carefully crafted doublespeak when it comes to things like extensions and user choice regarding configuration.
I don't understand, the stance on extensions has always been pretty obvious to me. Extensions are a third-party customization, they can work well and can do pretty much anything but because of that it's the user's responsibility to ensure their configuration is a working one.
> as all these apps and the whole platform still continue to be open source.
I mean, what is that even meant to convey? Do you mean to say that one can always create hard forks of non-trivial packages like GTK or develop extensions for GNOME shell the change the way it works like the PopOS guys did? We all know how well that turned out.
> I've also found that KDE apps don't really work well outside of KDE
Funny, because I use i3wm on an old NAS and KDE apps like Spectacle, Gwenview, and Dolphin work fine and use whatever theme and font I tell them to use and don't make decisions for me by assuming I'm incapable of making them. Can't say the same for GTK4 GNOME apps. They're not built to be used outside GNOME because GNOME is now a "platform", which is just doublespeak for a walled garden.
> the stance on extensions has always been pretty obvious to me.
It's obvious to me as well — we don't care about GNOME extensions[^1]. It's rather unfortunate that the extension system exists at all. People waste so much time and resources on making elaborate extensions like the Pop Shell or Dash to Dock under the impression that their extensions are somehow welcome but then they have to keep fixing them after every new GNOME release. What's even worse is that unsuspecting users use these extensions.
I'm conveying that no party can actually restrict this, GNOME/KDE apps might look ugly and bad on the other desktop but that's different from a business/legal restriction stopping you from running it or even trying to improve the ugliness.
>Do you mean to say that one can always create hard forks of non-trivial packages like GTK or develop extensions for GNOME shell the change the way it works like the PopOS guys did?
Well they don't have to make a hard fork, downstreams can just apply a few modifications here and there like Ubuntu currently does. I think Pop!_OS was trying to do too much with a small team and that was where they ran into trouble, I'd expect their progress to be even slower if they try to develop their own desktop.
>Funny, because I use i3wm on an old NAS and KDE apps like Spectacle, Gwenview, and Dolphin work fine and use whatever theme and font I tell them to use
I've also had KDE apps break quite badly with certain themes so I don't really know what you mean they work fine. In my experience KDE apps only work flawlessly when using Breeze, some themes like Kvantum make heavy modifications to the apps and so can cause pretty bad breakage.
>Can't say the same for GTK4 GNOME apps. They're not built to be used outside GNOME because GNOME is now a "platform", which is just doublespeak for a walled garden.
No, KDE and GNOME were both platforms for some time. What that means is they provide certain services and APIs for app developers that you can't get without using those APIs. There is little overlap between them, but that doesn't make them a walled garden. Historically I don't think KDE/GNOME developers have ever spent much time testing KDE/GNOME programs outside their respective desktops. You can try to get them to work in something else like i3wm but it's always been on users of those other window managers to figure out how to integrate it. Why would they bother making a KDE or GNOME app if they don't intend for it to be used with that desktop? You're confusing a walled garden with a simple case of developer intent. A walled garden would be if the app developers were forced to use these APIs, but they are not; it's actually the opposite of that, app developers can use whatever they want and that's why you're having trouble getting something to integrate with another environment. Not every API can integrate with all potential environments.
>It's obvious to me as well — we don't care about GNOME extensions
It's worth noting that blog is one developer's opinion. Tobias is also not a shell developer and does not make decisions for shell developers on what to do about extensions. He is of course free to give his opinion on extensions, as are you.
>It's rather unfortunate that the extension system exists at all.
No, I think it would be worse if there would be no extensions. Then you'd have no way to modify the shell.
>People waste so much time and resources on making elaborate extensions under the impression that their extensions are somehow welcome but then they have to keep fixing them
This is a misconception. Some more complex extensions that modify the shell in complex ways do need to be fixed every release. But a large number of extensions don't need anything more than some minor changes or some testing and a version bump. There is also some efforts to reduce the amount of work needed by extension developers, you can read about it here: https://blogs.gnome.org/sri/2020/09/16/the-gnome-extensions-...
> Your use case seems to be unusual, an old FAQ entry suggests that i3wm users prefer text-based file managers:
This is an old NAS that I don't really use much.
It's true though, I've mostly stopped using GUI apps on my primary workstation except Firefox because of how messy the situation is with GUIs on Linux. GTK wants to enforce its decisions on me and KDE Qt apps don't work well on my Wayland window manager.
> I've also had KDE apps break quite badly with certain themes so I don't really know what you mean they work fine.
I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps. I'm not using Android or iOS so I don't expect to be treated like an idiot.
> You can try to get them to work in something else like i3wm but it's always been on users of those other window managers to figure out how to integrate it.
It's not the uphill battle you're trying to project to make KDE apps work on non-KDE environment. Sure, some themes aren't built well but some are and all I have to do is install Kvantum+qt5ct to make the app look how I want it to. This isn't possible with GNOME and elementary apps because they chose to become their own isolated silos.
> It's worth noting that blog is one developer's opinion.
Is it? The opinions on that article are almost always shared by all the core GNOME developers I've seen commenting on issue trackers. Even the stopthemingmyapp guys resonate those opinions.
Doesn't sound like "one developer's opinion" to me.
> No, I think it would be worse if there would be no extensions.
Judging by the general disdain towards extensions by GNOME developers and many users, I doubt that's the case.
BTW for an example, here is what the KDE system settings looks like for me when I try to run it using qt5ct in GNOME: https://i.imgur.com/pxEKXye.png
I think we can agree that this is unusable, it also appears that it is attempting to load 3 or 4 themes at the same time which are all conflicting with each other. To me, trying to run KDE apps with a GNOME style or GNOME apps with a KDE style has always been a risky endeavor. Perhaps you got lucky running some apps that played nicely with themes but some apps just don't work at all outside their intended environment because they were not designed to use themes.
> BTW for an example, here is what the KDE system settings looks like for me when I try to run it using qt5ct in GNOME: https://i.imgur.com/pxEKXye.png
I don't get why you'd want to run KDE system settings outside KDE. The system settings app also has a lot of optional dependencies. I don't know which distro you're using but if any of those optional dependencies isn't installed, the system settings app misbehaves.
Typically, you'd run apps like Spectacle and Gwenview and Dolphin, standalone apps that serve a purpose, and from my experience, those have always worked on i3wm without issues.
Well again that's great for you that all the apps you use worked, but a lot of the KDE apps I use are broken with some themes :) I'm sure they would work fine in i3wm if you used Breeze but I have had very mixed results on any window manager with qt5ct, some apps play nice with it and some don't. It's not just the system settings that are broken for me, I just picked that as an example. Sometimes it's useful outside of KDE because it's the best way to configure global settings for some KDE apps, not just the shell and window manager. I've looked into it and it has nothing to do with optional dependencies, there are actually just issues with some themes and some apps.
But generally I think it's a bad idea to try to run any KDE apps outside KDE, or any GNOME apps outside GNOME, etc, those apps work much better when used with their respective desktops.
>I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps.
Well you can also use any theme you want on GNOME apps, libadwaita didn't break that, or rather it's just as bad as it is with KDE themes. Some themes will work but other themes will break everything.
>It's not the uphill battle you're trying to project to make KDE apps work on non-KDE environment. Sure, some themes aren't built well but some are and all I have to do is install Kvantum+qt5ct to make the app look how I want it to.
I can't agree here, I have had qt5ct break really badly with some apps and themes. It just doesn't work if the app wasn't designed to use it. I don't even bother with KDE themes anymore and I just use Breeze, if you ask me third-party theming is a total waste of time on any platform. For me it's always broken things or caused very strange glitches.
>I meant to say that, unlike GNOME apps, they allow me to use my own themes and don't enforce their decisions and choices on me when I use their apps. This isn't possible with GNOME and elementary apps because they chose to become their own isolated silos.
Again I honestly have no idea what you're talking about here, GNOME and Elementary apps can still be themed through unofficial third party methods. Developers of apps for those platforms do tend to focus on supporting the official theme for those platforms but that's the same as KDE where developers focus on supporting Breeze.
>I'm not using Android or iOS so I don't expect to be treated like an idiot.
Funny you mention this because I used to have jailbroken Android and iOS phones that were hacked to install third-party themes. The themes were just as broken as with GNOME and KDE. They might work OK with some of the built-in apps but would break quite badly with any third-party apps or when an OS update happened. That was another reason I just stopped trying to use third-party themes altogether.
>Is it? The opinions on that article are almost always shared by all the core GNOME developers I've seen commenting on issue trackers. Even the stopthemingmyapp guys resonate those opinions.
I'm not sure what you mean by core GNOME developers. IIRC Stopthemingmy.app was signed by some independent developers that decided they don't want to support third party themes that break their apps. It's not even related to the shell or extensions. You're conflating several things here. That petition didn't change anything technically about themes, it was a public acknowledgement that themes can break apps badly and that they won't be supporting them, which they never did before anyway.
>Judging by the general disdain towards extensions by GNOME developers and many users, I doubt that's the case.
You may have a biased view, I've heard complaints but the reason they happen is because users really like extensions and want them to stay. I've also heard lots of good things from users and extension developers, it works well when extension developers can test and update their extensions in a timely manner. Besides you can already have that if you want; just don't install any extensions.
> Well you can also use any theme you want on GNOME apps, libadwaita didn't break that
Happy to correct myself but unless there's a supported way to change themes for libadwaita apps using GNOME tweak tool or something similar, this is just doublespeak.
For example, I wasn't able to change the theme of this app using GNOME Tweak Tool the last time I tried.
I think you are misusing the word "doublespeak", I would suggest against using that word. There are some technical reasons why tweak tool will not work anymore but you can still use gtk.css and GTK_THEME, see here: https://blogs.gnome.org/alatiera/2021/09/18/the-truth-they-a...
Worst case it is the same as KDE, you have to set some environment variables and it still may not work correctly with some apps because third-party theming is inherently unreliable. The tweak tool method was also an unsupported third-party thing with most of the same limitations. It has been in a broken state for a while but you probably just didn't notice it because you weren't unlucky enough to end up in a situation where it affected you.
I'd still like to emphasize my other comments though, third-party theming is quite broken on every single platform I've ever used and I suggest against using it if you want to avoid apps randomly breaking. If you plan to continue that route then you may have to get more involved in development to the point where you can fix theme bugs and patch the apps without asking other people for help. That's been my experience with third-party themes anyway, they are essentially hacking the apps and so are not really for average users to mess with.
> The tweak tool method was also an unsupported third-party thing with most of the same limitations.
Interesting, so what was and is the supported first party method to change themes and set keyboard shortcuts and use Emacs keybindings and make the Caps Lock key behave as Esc on GNOME?
AFAIK there has never been an officially supported way to set those in the GNOME GUI and that's true of everything else in the tweak tool including the themes, that's why they're technically in "use at your own risk because this can break everything and mess up your apps" territory. Those are only implemented as hidden settings that the tweak tool modifies. Not sure about other desktops, XFCE might have a GUI to set them.
Interesting, I'll remember this the next time someone tells me to just use GNOME Tweak Tool to use Emacs keybindings or change the theme or keyboard shortcuts because they're unsupported features and maybe disabled anytime without notice, despite the apparent impression most people seem to be under when they use GNOME Tweak Tool.
Yes, you should also remember that when using third-party KDE themes like qt5ct, or hidden KDE settings, or anything else really that wasn't intended by the developer. In my experience with all of those settings, they do work sometimes but with certain apps they can break. That's mostly what unsupported means. I've already said my piece on themes but with keyboard shortcuts, the app can set key bindings that conflict with those and then you'll end up with a broken app again. It's a bad idea to use those settings unless you're willing to revert them at a moment's notice when they break some apps, or unless you're ready to become a developer and fix some of the underlying issues that are causing the breakage.
>despite the apparent impression most people seem to be under when they use GNOME Tweak Tool
I'm not sure what that impression is, GNOME Tweak Tool has always been this way. Other desktops like XFCE can of course expose the setting and make it supported but that's only guaranteed to work with XFCE apps that they've designed to work with that setting.
> Yes, you should also remember that when using third-party KDE themes like qt5ct, or hidden KDE settings
I don't have much skin in the game to be honest because I've given up on using any GUI apps on Linux wherever possible. If I do use GUI apps, I keep looking for ways to quit using them too. The attitude exhibited by GTK and GNOME developers on their issue trackers and the unstable nature of KDE apps on Wayland has made me cynical about GUI on Linux.
I wouldn't know how to differentiate between "supported" and "unsupported" features on GNOME. If basic features like changing keyboard shortcuts are "unsupported" on GNOME, I'm not sure who the target audience of such a DE is, except maybe grandmas, managers, and people with attention deficit issues. Then again, I fail to see why such people would bother with using Linux in the first place.
And yeah, I would use KDE apps but they're almost unusable on swaywm on Wayland so I've stopped using them as well.
I'll focus on creating and using only command line tools and TUIs. Unlike the GUI mess that we have, they are mostly platform independent and can be used almost anywhere.
>The attitude exhibited by GTK and GNOME developers on their issue trackers and the unstable nature of KDE apps on Wayland has made me cynical about GUI on Linux.
I think you're misinterpreting the attitude, or rather that attitude is the same anywhere. GTK and GNOME developers might just be more honest about it, they're fairly limited in what they can do so they can't really fix every single issue on the tracker in a timely manner. That attitude is the same thing with KDE, they have limited time and so can't stabilize things as fast as they'd like. I'd say use Windows or MacOS if you want an OS that is stable and don't want to deal with the limitations of Linux, it's quite far behind on the desktop, and using things like i3wm or swaywm is putting it even further behind because those don't comprise a complete desktop.
>And yeah, I would use KDE apps but they're almost unusable on swaywm on Wayland so I've stopped using them as well.
The problem there is the same, nothing is really native to swaywm or i3wm so you'll probably find that most apps suffer usability issues on them. That's been my experience with third party window managers. If you like KDE apps you probably should use KDE for the most reliable experience.
>I'll focus on creating and using only command line tools and TUIs. Unlike the GUI mess that we have, they are mostly platform independent and can be used almost anywhere.
TUIs have a number of other issues so I can't really suggest those either, you're forgoing a lot by making them. There are no perfect options for platform independent GUIs, everything is a trade off. I would personally suggest making web apps or Electron apps before I would suggest TUIs.
> It can be forked, it can be changed, your freedoms are enforced.
Sure, let's pretend that every user is a programmer who knows what a hard fork is and, even if he is a programmer, he's willing to create hard forks of each and every GNOME software he uses to support features that worked before and don't work now. This has worked out great for PopOS and Budgie right?
It's so much easier to just fall back on the open source argument and ignore the fact that it means nothing for the average user who doesn't know the first thing about C code or git to be able to make the changes he wants to.
It's not clear what you're talking about because there isn't a reality where this does whatever you want without programmers working on it. Average users are always going to need help from them, regardless of whether it's upstream or a hard fork. That choice also doesn't seem to be relevant to Pop!_OS and Budgie because for them it was a choice between hard fork or start from scratch, which is primarily a technical choice which needs experienced programmers either way.
There are multiple ways to get that though. One of them would be if a lot of hard forks existed, then you'd have a lot of options to choose from. Or those developers can contribute upstream and work on adding tons of options to the upstream project. My point is that there isn't a world where you just get the choice and options out of thin air without programmers, eventually someone has to program the options in somewhere or they just won't exist.
Honestly, I think they are going in the right direction.
The main problem with the Linux desktop has always been the insane fragmentation in my opinion. There's a million different options for every little thing and so developers don't have a platform they can count on and their option is to either provide reduced functionality (no integration with the desktop environment) or support a bunch of different things. And users don't get a polished JustWorks(TM) desktop experience.
> even distros like NixOS encourage users to use GNOME, which is absolutely insane when you think about it.
? NixOS doesn't have a default desktop environment. At the same time, the graphical installation media images have always come with Plasma as long as I can remember, and the example desktop environment commented out in the template given by nixos-generate-config has likewise always been Plasma.
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:
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.
> But I hope it makes that decision make more sense.
It does but it's rather unfortunate that the only choice we have when it comes to DEs is either GNOME, which is built by a group of arrogant developers who think there is no downstream for GNOME and GTK, and KDE, which has technical issues that prevent widespread adoption.
I think you're misinterpreting decisiveness as arrogance. GNOME developers would probably like to respond to more of them but they can't because of lack of developers, so they have to make tough decisions about what to support. When downstreams don't handle some of the burden then it's a loss for everybody. KDE also does not really like or benefit from having a ton of downstream forks either, the project is way too large and it's more useful to get upstream contributions. Maybe it would be better if there were more choices, but nothing is perfect. You and I could probably find more things to complain about in any third/fourth/fifth choice.
>and KDE, which has technical issues that prevent widespread adoption
Which KDE technical issues are preventing its adoption? I'm running KDE full for a long time and encountered no issues.
IMHO, the lack of KDE adoption is the inertia of GNOME adoption by the major distros combined with the inertia of hate over KDE with the stereotype that "it's bloated" which hasn't really been the case in the last versions of Plasma.
> Which KDE technical issues are preventing its adoption? I'm running KDE full for a long time and encountered no issues.
Some of them are linked by pxc post above mine.
There's also the issue that Qt apps can only be written in C++, a language that many don't want anything to do with. In comparison, GTK has bindings for a variety of languages including Rust.
>In comparison, GTK has bindings for a variety of languages including Rust.
Are those good bindings , or auto-generated or outdated ones ? I did not checked in a long time but I think only Python had decent bindings. I would avoid non-official bindings, those are most of the time garbage and you waste your time instead of focusing on your work.
I seen Qt in a lot of proprietary applications, including launchers for video games (the app that will let you setup a game configuration before launch) - I was surprised why a Windows only video game would not use the Windows APi directly, but it is obvious that Qt is better then whatever Windows has this days for c++ devs and game devs are not afraid of a bit of c++ or have some irrational disgust for Qt pre-procesor (I see this excuse all the time, we don't switch from GTK to Qt because of the qmake/moc I honestly prefer an honest explanation)
I guess this is just my opinion but NixOS is probably the most esoteric Linux distribution I've used. Anyone who intends to use NixOS comfortably probably isn't apprehensive about configuration and customization, things which are the antithesis of everything GNOME stands for.
I fail to see why GNOME, or any DE for that matter, is something that should be recommended by a distribution like NixOS.
Being the default and thereby “recommended” desktop in NixOS a lot different than in other distro’s.
In other distro’s, to get a non-default desktop, you have to download a whole different distro “spin”, like Kubuntu. Or add the new desktop packages and manually configure them all.
With NixOS you use the same install image, and just change two or three lines in the master configuration.nix file, and re/build. You can change back and forth between DE’s that use different window managers with a reboot, or between DE’s that use the same window manager with a relog [3].
Most the major desktops are supported in NixOS [1][2]. Gnome being the default means little, is easy to change should NixOS community ever form a consensus about changing the default (say in response to Gnome crossing some line), and is easy for end users to change any time.
on ubuntu, and then select cinnamon at the login screen after booting, and it'll work just fine. same for mate, plasma, etc. Same for debian, and most linux distros I've tried. installing another desktop isn't difficult at all, usually
Debian (and Ubuntu as a result) has "task-*-desktop" tasks (meta-packages) which install, configure and tune the whole distro for a new/additional desktop environment too.
Right, and I'm pretty sure you can use the same display manager with both (at least if it's lightdm), and then switching back and forth between gnome and KDE is literally a matter of switching between the words "gnome" to "plasma5" in one place.
> Just because you disagree with them, it doesn't make them the "bad guys".
Since the KDE 3.5.x days, it's always KDE guys who try to build corresponding GTK themes of the themes they default on the corresponding release, or build corresponding Qt themes of the GTK themes put forward as default by the GNOME guys.
Moreover, there are always ways to make GNOME subsystems work well on KDE systems, and KDE guys always make sure that the standards they propose work with the GNOME without much hassle. Also, KDE guys put forward cross-DE ways to make user experience better (XDG base folder specification, for example).
OTOH, GNOME people sit on their high thrones like they're the only game in town. I respect them deeply, but I can't appreciate them just because they auto-generated their JS introspection layer from C code automatically, but didn't bother to write any documentation, because you can try it all in the built-in JS console.
I have a couple of more, lower level stories with them, which caused a lot of all-nighters and project postponements, but that's for another comment.
What actually makes them the bad guys is that they parlayed the goodwill of the original GNOME (2 and prior) which was very open to change and community contribution into the restrictive community hostile thing that it is today.
I don't mind that it exists, but they should have changed the name and been more clear about the direction.
a. Their development team was more professional (locking threads when feedback starts coming in, making offhand derogatory comments about people's reading comprehension skills, trying to minimize serious problems to avoid dealing with merge requests/more work, blaming downstream actors like PopOS! for simply using their software and disagreeing with their ethos, etc.)
b. They used their funding to actually fix issues (GTK4 still has text rendering issues. 8 months later. Insert obligatory "thumbnail file picker" comment here)
c. They didn't regress features that previously worked (No more extensions, no more desktop tweaks, overall fewer settings in new releases, design upgrades that are decidedly opinionated)
d. They didn't treat their opinions as gospel (eg. encouraging Flatpak-or-die culture when Flatpak itself is still in it's infancy and wildly unstable, going out of their way to obfuscate theming interfaces, having "one guy" come up with a new design for something and implementing it before the community decides if it's something they want)
Yeah, I think I am comfortable calling them "the bad guys" in the current landscape of Linux. GTK's team is still fine (barely) but the overall effort to combine the two, add middleware like libadwaita, move fast and break things, and blame it on the user when things stop working is just getting to be asinine.
They can have a vision if they want, but it shouldn't have to come at the expanse of the rest of the community. That's how you burn goodwill.
Really? Isn't GTK where the CSD (client side decoration) is being forced onto every app, with no way to use native/normal window manager borders? It seems rather widely despised:
That's more of a GNOME effort, if I'm being honest. It's a feature that's provided via GTK's libraries, but the whole "we're going to add CSD and you're not going to do anything about it" has been more of a GNOME sentiment[0].
App developers will design their apps in a certain way and will add features that they think benefits the app. Some will add CSD if they think it's beneficial and others won't. What is it that you would want to do about that? That's always been how it is. If you were in charge of designing the app then you'd be the one going to meetings and writing the code.
The app developer gets to choose what decorations they support. Some app developers will choose to only support a certain type of decorations; that's an intentional design decision made as part of the app. In the past, GNOME app developers have chosen to use CSD and XFCE developers didn't, but there seems to be a shift from them towards CSD too. I've also seen some XFCE users saying they like the CSD.
>I prefer it, been a CSD user since before CSD itself, with Winamps rolled up UI.
That is it, but somehow you don't see it??? I mean is so obvious///
You could have Winamp or you could have an application with a window in the form of a circle but this days GNOME decided that you can ONLY have CSD and old apps that use SSD or non-GNOME apps that use SSD should switch to SSD... so you ahve 2 issues
1 GNOME is removing the option to have both SSD and CSD , and forces you into CSD only
2 GNOME does not provide(maybe things changed and someone forced those arrogant bastards to support some legacy app that RedHat needs) any support for SSD apps.
I don't understand how you're having those issues. GNOME has never had the option to have both CSD and SSD. When GNOME apps used GTK2, SSD was the only option. When GNOME apps started moving towards GTK3, CSD became the only option. What you're asking for is a new feature because GNOME never supported both.
Legacy apps using X11 will use the legacy X11 decorations. Those should still work. For Wayland apps, those were never working correctly if they didn't support CSD. What you're again asking for is a new feature, there are no legacy Wayland apps that will depend on that functionality because it never existed in GNOME Wayland.
> SSD was the only option. When GNOME apps started moving towards GTK3, CSD became the only option. What you're asking for is a new feature because GNOME never supported both.
Really? , You should just hide the Window titlebar , and paint your own CSD, titlebars were not forced on you https://developer.gimp.org/api/2.0/gtk/GtkWindow.html#gtk-wi... , this is how for example splashscreens are implemented or fancy non rectangular windows , but to be honest I am not 100% sure if GNOME2 was also an asshold and disabled this GTK feature just to be spacial, if you can confirm then let me know if I am right then you need to acknowledge the fact that SSD was not forced on you(not Qt,not GTK, not even Windows/OSX forced SSD on you )
Sure, the feature existed in GTK but what I mean there is that GNOME 2 apps didn't use that. They never painted their own CSD. Sure some apps did for splash screens but not for ordinary app windows. Then when GNOME 3 happened they all redesigned their apps to only use CSD. They didn't implement SSD in Wayland because it wasn't part of the design and by then all the GNOME 2 apps were already gone anyway. That API is even still present in GTK4, the reason you saw a change is because the apps (the callers of the API) changed how they use it.
But the issue we have with GNOME is not that they changed their own apps to CSD,
the issue is that their Window Manager does not paint the SSD for non-GNOME app, I hope this is clear now or let me try to simplify it
Before
- you could have both CSD and SSD application run on GNOME
After
- you are FORCED to implement CSD on GNOME because their Window Manager will not paint the SSD for you, even for old application that existed before GNOME3 was created.
It would make sense for GNOME to support this old applications or toolkits that do not implement CSD , I really hope sanity will prevail over designer ego (it happened at Apple so there is a chance it will happen at GNOME after a few years of feedback)
>you are FORCED to implement CSD on GNOME because their Window Manager will not paint the SSD for you, even for old application that existed before GNOME3 was created.
No, this is not true at all. Old applications and toolkits that existed before GNOME 3 was created will use X11, and the legacy decorations will still work there.
>No, this is not true at all. Old applications and toolkits that existed before GNOME 3 was created will use X11, and the legacy decorations will still work there.
OK, good news then for old apps and games , is there a solution ready for new applications like Qt,Electron ones that were not created for GNOME? Can you resize them on Wayland or you are forced on X11 ? If you do not use Wayland is he Window Manager still implementing the SSD or they removed the code (I think I read something about code getting removed but I am might be thinking about something else).
So my question if I were to test GNOME+Wayland will this work correct:
1 old games , games that use DOXbox or emulators
2 new games in Wine or native
3 Qt or other apps like Intellij,Thunderbird, Visual Studio Code, VLC, Slack (does GNOME still has no system tray for Slack/email clients ?)
4 is GTK still recommended for cross platform development? isn't cross platform support and GNOME design in a contradiction? any such example of a cross platform GTK4 complex application
I am sorry if my knowledge is a bit outdated, I am no longer reading Linux news ,podcasts or Linux reddits (I got tired about reading all the small drama stuff, the big news will reach me somehow anyway)
2. Wine apps will probably have to draw the win32 decorations. Native apps can implement their own decorations or can use GTK or Qt to draw their decorations.
3. Qt does have its own CSD decorations, VLC should be able to use that. Intellij is a Java app so I'm not sure about that one but Thunderbird should use GTK decorations. The rest are Electron apps and 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...
OK, so I am not doing any desktop app development this days but if I will do I will not write any special code for GNOME.
> GTK is not a cross platform toolkit like Qt where it tries to draw everything with native widgets
Just a correction, Qt does not use native widget, they have code that will adapt and paint the thigns too look and work as native widgets, so for example they have button groups that when you use it say for OK-Cancel buttons it will change it to Cancel-OK on different platforms (some platforms have the order reversed). Also Qt will paint the OK/Cancel button icons on KDE but not on Windows/GNOME . So in fact Qt devs put the effort in and wrote code and themes to get things look native, use the native file dialogs, use the native notifications, system tray, the native paths etc (not ike the other toolkit that doesn't care about integration, theming and configuration)
a. Some discussions become the target of trolling and it's necessary to lock threads, unfortunately it happens sometimes. If somebody has made a rude comment then you may want to report that as a code of conduct violation. The developers are volunteers and don't have infinite time to handle all the work that's thrown at them. The disagreement with Pop!_OS was disappointing but I don't know who else you can blame for that, if Pop!_OS wants to go their own way then that is completely their decision. They aren't forced to contribute upstream and I'd say that's good for them and their goals.
b. There isn't really any funding to pay to fix those issues. They're being fixed by volunteers, so progress is slow.
c. I have no idea what this means, extensions are still there.
d. There are issues with Flatpak but all the other options are worse and are more unstable. Before Flatpak, there was just no way for upstream developers to make an "official" packaging for apps. The theming interfaces haven't really changed because those didn't really exist, those were a hack for the entirety of GNOME 3. Having one person implement a design and then gather feedback on it from the community is how open source works. If the community wants it then they'll use it, if they don't then they'll use something else. I'm confused how else you'd expect it to go. Talk is cheap, putting working prototypes in front of the community and then gathering feedback from there is what gets things done.
I also don't really understand why you're saying this makes them the bad guys or comes at the expense of the rest of the community. Like, none of this affects KDE. KDE has their own middleware libraries and makes their own changes. They don't depend on any GNOME libraries. Even XFCE that depends on some libraries like GTK doesn't really have to deal with any of this. GNOME's issues with extensions don't affect them at all because they don't use the GNOME shell, they can package their apps with whatever they want and they don't have to use Flatpak, they probably won't use libadwaita or if they do they'll heavily modify it, etc.
>Just because you disagree with them, it doesn't make them the "bad guys".
I was replying on the consistency topic. some projects offer the user a consistent experience by offering both Qt/GTK support and others don't care and would rather force their branding on you.
As much as I think that GNOME is a joke at this point (and has been for well over a decade), is that really such a bad thing that they focus on supporting their graphical toolkit of choice?
Besides, the real solution here is for developers to switch to QT and stop using GTK. ;)
Qt, unfortunately, by nature of being C++, is much harder to link into a different language. GTK is a plain C API. So, if you’re using plain C, Rust, C#, etc, it’s a heck of a lot easier to use GTK than Qt.
The thing is that GNOME project and GNOME based distros should put just a bit of effort to support Qt programs, like have the same File Picker Dialog or even have GTK2 and GTK3 use the same fucking File Picker or at least with the same fucking File Sorting.
About easy of use I am sure that you are more productive with a professional toolkit like Qt and a mature language like c++ then fucking around with some broken/incomplete/buggy C# or Rust GTK bindings. Though I think you can do simple Python apps with GTK GUIs but for professional applications that are targeting crossplatform trust me Qt is the solution (I never seen a good GUI cross platform pro application , Linus Torvalds himself used Qt for his app because his Red Hat friends could not answer him on how to do some complex GUI in GTK)
This is a recent development and that was designed to support GNOME/RedHat's flatpack , we should not get tricked to believe GNOME would have done this for helping someone else then themselves(do they support this in GTK2 apps too?, I really hate having different file choser with different sorting order of files and folders)
It probably cannot be done automatically in GTK2 apps because of API differences. GTK2 apps could call the portal API manually or put the functionality in another library.
>we should not get tricked to believe GNOME would have done this for helping someone else then themselves
Well they actually did, the flatpak API was designed to support multiple toolkits.
Re consistency: Am I the only that finds all those burgerbuttons and cluttered window frames (I think they may even call them decorations!) anything but?
Give me a title bar and good old many bars please.
You can run manually any application you want. It just does not offer one-click install for non-games. I believe lutris offers better runner configuration.
I'm confused...Crossover (a commercial product using Wine as its backend and contributes back to the Wine project[1]) uses the term "bottles" for its container-like method to install Windows apps on Linux and macOS. Is this an offshoot or extension of Crossover, or is it a blatant ripoff of their already existing service and name? Codeweavers (the makers of Crossover) have been using the term "bottle" in this paradigm since at least the late 2000s[2].
The WineHQ official documentation makes reference to WINEPREFIX being termed a 'bottle', and there are quite a few previous open source projects listed with titles stemming from bottles, so I'm not sure that it's a crossover specific term (and if it is, it seems to have been adopted by the open source project too).
And let's be honest, although cute, it's a pretty obvious term for a project called Wine.
Especially considering that the wine project which Crossover relies in and contributes to also uses the term 'bottles' to encapsulate how they create different Windows environments.
Looks like a replacement for ye-olde PlayOnLinux, which if I ever move to Linux Desktop[0] was going to be something I would write my own tooling to replace[1].
It is not clear from looking over the website, but since bottles appear closely related to Flatpak I am wondering if they support being installed to a different path than the default. Flatpak doesn't allow you to do this in a piecemeal way[2], but it does allow you to set up more than one entire Flatpak environment to different paths[3]. I'm hoping bottles can at least manage that?
[0] There are dozens of tools on my list for this, mostly around application and container management.
[1] I am a very vocal critic of the way Linux Desktop does things, but Windows is becoming worse at an alarming rate so it will probably be the least-worst option in a few years.
[2] A regression from features we had in desktop OSs since the 80s.
[3] Not that any GUI frontend for it pays attention to that. sigh
Idk anything about bottles, but just curious why you would want that feature? Like, what is a compelling use case for it?
You probably know this already, but the point of Flatpak is to offer sandboxing and packaging of all dependencies in an isolated way. Being able to install and run flatpaks from any directory seems like it’d be difficult to implement for little benefit. It’s a bad fit for the tech IMO, and unnecessary since AppImage already offers exactly that functionality, but without the sandboxing (and other) features.
> Idk anything about bottles, but just curious why you would want that feature? Like, what is a compelling use case for it?
Being able to run some applications from super fast but small NVMe disk and less important ones from slow but huge spinning rust disk, being able to run applications from a network share, CD, USB stick, etc. Desktop OSs have been able to do these sorts of things since the 1980s without all the hoops Linux Desktop software makes you jump through to do them.
> Being able to install and run flatpaks from any directory seems like it’d be difficult to implement for little benefit.
If Flatpak had considered this ability from the beginning it wouldn't be. Hell it might not be that difficult now, I haven't looked at the source for Flatpak and how it does things behind the scenes is otherwise not documented as far as I can tell. As you mentioned, AppImage implements it without much difficulty, and AppImages can be securely isolated by firejail. Combining the two concepts in the same package shouldn't be that hard. 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?
> unnecessary since AppImage already offers exactly that functionality
If AppImage were fast becoming the new standard in Linux Desktop application distribution we wouldn't be having this conversation.
> Desktop OSs have been able to do these sorts of things since the 1980s without all the hoops Linux Desktop software makes you jump through to do them.
Linux desktops can do this. Flatpak maybe can't (Idk, I don't use them that often, but I'd be surprised if they couldn't), but even before AppImage, Flatpak, Snap, etc you could always just run an application from wherever you want. You could do that 20 years ago, and you can do it today.
Desktops in the 80s didn't have sandboxing, but modern Linux desktops do. You can either implement sandboxing yourself through syscalls, use something like Systemd, or use the significantly more user friendly Flatpaks.
...Or don't use sandboxing at all, and do whatever you want. Download a (hopefully statically-linked) ELF from the internet, chmod +x it, then execute.
> standard in Linux Desktop application distribution
There is no such thing. There never has been, and there never will be :P
Yeah, a lot of people would, but I honestly can't see why. Application management on Linux is already complicated enough without having to learn a new language to use it effectively. I get that many people find value in its declarative nature, but the reason I think that is so attractive is that the current paradigm is so utterly terrible it makes what should be a relatively niche requirement (declarative application management) look like a good general solution.
I can point out that Guix uses Guile, a scheme, something someone may already know before using Guix, but I think a more interesting perspective is that of the simple user.
What Guix and Nix give you are a package manager that can be used with a signature distro or installed upon another distro, and that package manager makes an effort to be the last package manager you'll need. Both of them are packaging the normal types of programs you'd expect, but also emacs packages, vim plugins, python packages, rust packages, go packages, and so on. Nearly every guix upgrade I do shows me that a bunch of new r-foo packages (R-lang stuff) got packaged. The way I see it, with enough time and manpower, these package managers will have just about everything you'd ever need (exceptions for things like proprietary software, mainly in the case of guix, although these can and do still exist in unofficial channels). Even in their current state they are good enough at doing this that I'm able to get all my emacs packages from the package manager and not use elpa/melpa at all. This also gives you rollbacks for free. If an emacs plugin breaks, you can roll back to a previous generation, and optionally do a partial upgrade to then re-upgrade everything except that broken package. This process is basically instant as it's just moving some symlinks around in the store. You can also have multiple versions of programs installed without issues, and until you do garbage collection, you likely do by default.
Declarative package manager is also cool even as a regular user. If you choose to use a guix manifest to manage your user's packages, you have a good visual of everything you've intentionally installed on your system (not cluttered up with the deps they pulled in), and you can easily add/remove them with a text editor + re-running a command afterward to reapply the manifest.
I don't consider myself a programmer, and I have not built packages for most distros (I have made a guix package or two locally with some help, but never submitted them upstream), so I thought my perspective as someone using these tools may be valuable. I wouldn't say I ever learned the nix lang or guile to any sort of level of fluency. I basically treat a configuration.nix or config.scm the same way I treat my sway config, neovim config, and so on. The syntax is a little complicated, but the community is there to help, and there's also the documentation. I just know enough to get by as a regular user and I still greatly appreciate guix.
> [T]he Linux community abhors the concept of managing applications like they were just regular files and prefers complicated tooling, gigantic databases of dependencies, and armies of maintainers.
> Flatpak is gaining ground, which is better than continuing with the current paradigm as far as I'm concerned, but it is still worse than the simple way things were done in saner desktop operating systems.
(and from your other comment:)
> Application management on Linux is already complicated enough without having to learn a new language to use it effectively.
Linux is the only system (maybe now FreeBSD, if they've completed the migration to a packaged base system yet) where every single piece of software on a complete and usable system can be managed uniformly with a single set of automatic tools. You are absolutely correct that people using such a system are loathe to return to the fundamentally unmanageable anarchy of a system like Windows, where
* every installer does basically whatever the hell it wants;
* you can never really be sure that an uninstaller does its job;
* much software simply cannot be installed or uninstalled non-interactively;
* managing non-interactive installation for apps which DO support non-interactive management is often achievable only through some bespoke process;
* every single fucking program feels entitled to litter your system with its own bespoke auto-update mechanism (sometimes one that runs in the background constantly!);
* a brand new system with virtually no desired application software takes up 20-40 GiB, instead of 4-8 GiB;
* it is difficult to even *discern* whether or not the whole system is up to date, and bringing a system up to date requires several manual processes;
* even in the year of our lord two-thousand and twenty one, whole system installs mysteriously become slow after a few years so that they must either be reinstalled (the only sure-fire way) or treated with a laborious, manual cleanup process just to achieve sane, normal performance again.
Software management on Windows is absolutely riddled with problems that are hugely minimized by traditional Linux package managers and can be more or less totally eliminated by more innovative ones. People who are already using Linux are opposed to your proposition because we've been there on other operating systems and you are asking to drag us back to hell.
Flatpak isn't a 'step in the right direction' which will eventually take us to the manual, repetitious, chaotic, redundant mess of managing software on other operating systems. It's a fundamental improvement over that model, because it retains
* very good deduplication of shared runtimes via OSTree;
* easy management by automatic tools;
* conventional and technical constraints on what applications can do to set themselves up;
* a single central interface for software distribution;
* a more complete specification of the dependency chain, unlike the implicit and unspecified dependencies on various Windows components from different eras that cause the base Windows installation (even without any applications) to grow and grow and grow.
Flatpak is not going to give those things up, and if it did it would not be 'advancing'.
> > > standard in Linux Desktop application distribution
> > There is no such thing. There never has been, and there never will be :P
> Did I mention the other thing I hate about Linux Desktop? It's community.
This is how you react to playful commiseration about the difficulty of coordinating unification between independent, distributed, democratically managed volunteer projects? Please, I urge you in the strongest possible terms: continue using Windows exclusively, forever and ever. :)
> Linux is the only system (maybe now FreeBSD, if they've completed the migration to a packaged base system yet) where every single piece of software on a complete and usable system can be managed uniformly with a single set of automatic tools.
Only the software that has been painstakingly packaged for that particular version of that particular distribution can be managed by said tools. This is one of its biggest flaws and part of the reason Flatpak even exists.
You rightly describe a lot of problems with the installer mechanism of traditional Windows, which is not what I am advocating for[0]. I'm advocating for something more like original Mac applications, or RiscOS AppDirs, or NeXT/current MacOS Application Bundles, or just folders with files in them in DOS, or you know, AppImage. Single object applications that can be copied, deleted, and moved the same as any file without a bunch of special tooling. I contend that the need for special tooling is to work around an overly complicated model, not inherent to the problem space.
> This is how you react to playful commiseration about the difficulty of coordinating unification between independent, distributed, democratically managed volunteer projects? Please, I urge you in the strongest possible terms: continue using Windows exclusively, forever and ever. :)
When someone asks me about my use case for features for the sole purpose of being pedantic and telling me things I already know that are entirely useless and that I have heard variations of for twenty goddamn years while literally using an emoji that represents a human face sticking it's tongue out... well let's just say I'm not inclined to have a high opinion of them. Frankly, there's good reason Linux is in a distant third place as a Desktop OS, despite how much Windows sucks, and it isn't because it provides a seamless experience and its community is so helpful and welcoming.
[0] It's weird that when you criticize something in Linux Desktop, for some reason its proponents always go all whataboutism on Windows.
> Only the software that has been painstakingly packaged for that particular version of that particular distribution can be managed by said tools. This is one of its biggest flaws and part of the reason Flatpak even exists.
Yes, that's true. This is a pretty marginal problem for F/OSS-oriented end users of distros with large package repositories, and that's probably why it's not a problem that gets the kind of focus you'd like to see within the Linux community. My needs are well-served by the package management model, and I don't use very much proprietary software, so for me personally, it feels very worth it to package whatever new hotness I need on my system and retain the management benefits of the package manager.
But 98% of end users (even fairly technical end users) don't want to package any software themselves, and it's not really possible for third parties to do so properly with proprietary software. (Although you can find many examples of shoehorning proprietary binaries into normal-ish packages in the AUR and in Nixpkgs.) The fact that ‘Linux’ is not really an OS platform is a real problem for publishers who might want to release software on the Linux desktop.
> You rightly describe a lot of problems with the installer mechanism of traditional Windows, which is not what I am advocating for[0]. I'm advocating for something more like original Mac OS applications, or RiscOS AppDirs, or NeXT/current MacOS Application Bundles, or just folders with files in them in DOS, or you know, AppImage.
AppImage has one big problem, which is that it basically just assumes but doesn't specify a fairly large base runtime. This is a serious portability problem, and it's why AppImages are not usable in their intended way on systems like NixOS and GuixSD, and instead require a wrapper/launcher. Flatpak doesn't share this problem because its design involves a launcher program that can be wrapped or provided with a special environment, and it's designed to more fully encode the runtime dependencies of apps packaged for it. (In principle, Snap is the same way, but I doubt it'll ever be packaged in Guix due to the proprietary server-side code and I just don't think there's much interest in it on the Nixpkgs side.) This could be solved by standardization, but I have to agree that that is very unlikely to happen.
Of the examples you give, macOS ≥10 application bundles are the only ones I've really used. Maybe this is nitpicking, but I don't think macOS .apps are a great model because
* they still leave us with the same update management problems as I outlined in the Windows case
* they don't really cover everything application packages or installers are expected to be able to do, like bundle kernel modules, modify the operating system configuration, or set up runtimes for programming languages (this is why you end up with executable scripts that run as root for macOS .pkg installers)
* AppBundles can and do have dependencies which are unmanaged
* real applications often involve multiple bundles, which is one of a few reasons that your tools again have no real uninstall capabilities (take a look at a few Homebrew Cask formulae[0] and you'll see examples of this, e.g., here[1])
* it's not hugely important, but AppBundles do still result in enormous application/installer downloads, and a base macOS install takes up 2-4x the space it probably could (this is less egregious than on Windows because at least Macs come with a fairly comprehensive set of basic GUI applications)
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. But there are two problems (for me, at least):
* 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;
* and where to draw the line between the runtimes and the application is not clear, since in Flatpak, runtimes can depend on other runtimes. The more you deduplicate, the more you lose the ability to manually manage your application storage. The more AppBundle-like you make Flatpaks, the less deduplication and internal dependency management you can do.
I'm not sure those problems are fatal, though. You could probably have something pretty good that lets you distribute Flatpaks as files, if you want.
> 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.
I think we pretty much agree with where the problems that I have with Linux Desktop application management largely come from.
> * they still leave us with the same update management problems as I outlined in the Windows case
Not necessarily, there are a lot of ways to go about discovering which applications need updates and where to get them. Off the top of my head: they have a manifest file (or header) that specifies a URL for acquiring the update and the OS maintains a list of paths for every application ever launched to be checked with a single command, as well as optionally being able to search for applications to update.
> * they don't really cover everything application packages or installers are expected to be able to do, like bundle kernel modules, modify the operating system configuration, or set up runtimes for programming languages (this is why you end up with executable scripts that run as root for macOS .pkg installers)
Agreed, but I'm mostly concerned with desktop applications, if that wasn't clear. Such add-on software needs some mechanism of being easily visible to the OS, which probably necessitates something like a fixed path, but I don't think it can't still be self-contained. IIRC Slax did something with AUFS that involved self-contained objects in a special directory that were applied as overlays over the base system at boot and on-demand, which is one way to do it. I think all Haiku packages kinda work like that too.
> * AppBundles can and do have dependencies which are unmanaged
I don't think they should. Or rather, the dependencies that are not part of the base system are considered part of the application and should be contained with it and updated with it. UI toolkits, system interfaces, cryptography, networking, and other such libraries used by a large number of applications should be part of the base system. As you mentioned, part of the problem here is that Linux Desktop has never had a concrete idea of the separation between platform (base system) and application. However, Flatpak kinda does, because it has 'runtimes'. If Flatpak managed the runtimes as it does today, but allowed self-contained portable application folders to run from wherever and use said runtimes, that'd be pretty close to ideal I think.
Out of order because related:
>> * 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;
Whereas I don't like the idea of developers and users being beholden to the whims of a repo to be able to distribute and consume software conveniently. We may just have to agree to disagree on that one.
>> * and where to draw the line between the runtimes and the application is not clear, since in Flatpak, runtimes can depend on other runtimes. The more you deduplicate, the more you lose the ability to manually manage your application storage. The more AppBundle-like you make Flatpaks, the less deduplication and internal dependency management you can do.
It shouldn't be that hard to find a reasonable balance I don't think. Some duplication isn't really a problem because, as I mention elsewhere, assets are a heck of a lot bigger these days than any binary. Further, many (some would say most) "shared" libraries are only really used by a single application. There are obvious candidates for the 'base system'/'runtime' platform: UI, system interface, networking, cryptography, etc. The problem there with Linux of course is that ABI compatibility is frequently broken in some of these so you'd have to have a bunch of versions to cover everything.
> * real applications often involve multiple bundles, which is one of a few reasons that your tools again have no real uninstall capabilities (take a look at a few Homebrew Cask formulae[0] and you'll see examples of this, e.g., here[1])
See above. To reiterate: I think this is just a poor way to do things. If you have some tightly integrated set of applications they should be managed as a single unit. Think an 'MS Office' application instead of a separate Excel, Word, and Outlook.
> * it's not hugely important, but AppBundles do still result in enormous application/installer downloads, and a base macOS install takes up 2-4x the space it probably could (this is less egregious than on Windows because at least Macs come with a fairly comprehensive set of basic GUI applications)
I don't really use a modern mac and haven't since the early 2000s, but as far as I can tell from using applications in general the actual binary portion of them is usually dwarfed by things like graphics and sound assets, which isn't helped by the traditional package management system anyway. Besides, we're living in an era when people voluntarily bundle an entire goddamn web browser to handle their application's GUI. There's no way native-GUI AppBundles are worse.
> 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 guess that's one way you could word it. Another one is that Windows does a lot of things wrong, and its application distribution mechanism isn't ideal, but overall the things Windows does wrong don't bother me as much as the things Linux does wrong. As I mentioned in the very first post in this thread though: Windows is rapidly become so bad that Linux might soon be the least-worst choice. When that day happens I will not be any more inclined to like the way Linux Desktop does things, I'll just finally hate Windows more.
> Not necessarily, there are a lot of ways to go about discovering which applications need updates and where to get them. Off the top of my head: [manifest file with a simple registry]
I generally like the centralization and vetting associated with Linux distro repos, but this would be a decent approach for desktop applications that at the very least wouldn't be annoying to use or deal with.
> part of the problem here is that Linux Desktop has never had a concrete idea of the separation between platform (base system) and application
Yeah. I kind of like that Linux is this way but I do see how it is also a problem.
> If Flatpak managed the runtimes as it does today, but allowed self-contained portable application folders to run from wherever and use said runtimes, that'd be pretty close to ideal I think.
I think that could be pretty nice. It would certainly be user-friendly, and it would still allow Linux distros to vary and experiment in all of the ways that they like to vary and experiment.
> we're living in an era when people voluntarily bundle an entire goddamn web browser to handle their application's GUI. There's no way native-GUI AppBundles are worse.
lmao true
> IIRC Slax did something with AUFS that involved self-contained objects in a special directory that were applied as overlays over the base system at boot and on-demand, which is one way to do it. I think all Haiku packages kinda work like that too.
There's a research distro called Distri that does some tricks like this, and I think the design is really good. It doesn't allow hooks and triggers (which I think you'd like) and distributes packages as SquashFS images. It does some union mounting stuff (and I think user namespace trickery) to handle shared dependencies.
There's also GoboLinux, which rethinks the shared global paths in a Mac-ish way that's pretty neat: https://www.gobolinux.org/
Neither is usable as a daily driver or has a sizeable community or anything like that (of course lol).
I do think that for some things, we do need to rethink the FHS, and if we want something that publishers can deal with, we need a clear separation between base system and end user applications on Linux. (We also need that for users who don't want to be system administrators, and who will be surprised and upset that installing what they think of as end user applications can result in dependency conflicts. See the LTT ‘do as I say!’ debacle.)
Imo, some day it would be great to have something like Guix or Nix generate a base system that is made available in what Nix/Guix folks would call an ‘impure’ way, and then for applications to be installable on top via something like Flatpak for desktop applications and an old-fashioned ports system for developer tools. The complexity of tools like Guix and Nix makes sense for distro makers, and sharing dependencies is actually valuable on a base system where you want tight integration. But then publishers and users who don't want to deal with that complexity can use distribution mechanisms like we've discussed, and the door to the packaging system is open for people who want to intervene in the base system instead of just building on top of or alongside it.
I think we will probably get there, very, very slowly.
> Being able to run some applications from super fast but small NVMe disk and less important ones from slow but huge spinning rust disk
1TB NVME drives aren't very expensive on the order of $80-$100 US. This is already big enough for your entire OS even with several very large games installed. The natural split if you have multiple drives would be between OS and backups/multimedia.
I see this immediately being used for pirated software and games. It could also be used to implement a cross platform app store like interface to install legitimate software. It could even be integrated with the same store interface as one uses to install traditional packages and flatpaks for a true one stop shop.
> 1TB NVME drives aren't very expensive on the order of $80-$100 US.
That isn't the point. I have in my possession several small form factor computers that have 16GB disks in them. "just spend $80-100 each on them" is not a good excuse for having such an inflexible system that it demands everything be on one disk.
The original Mac did this on floppies in 1984. It is 2021, our software should be able to do better.
You have several toys. The purpose of software isn't to optimize for an interesting use case you have devised for your toys it's for actual machines to provide useful work and engaging play. Faster file access for limited files is accomplished by
- caching in ram
- on disk cache
- an explicit read cache device
All of these are broadly applicable and effective to the other 99.9% of actual devices.
Right...I get where you're coming from but I think where you're coming from is indicative of the why things changed.
It's neat old Mac's from the 80s could to do that...but they had to be able to do that in order to be useful. In other words, it wasn't a "cool feature", it was something they had to be able to do.
I imagine that when storage became more plentiful OS developers became less interested in implementing solutions to problems of this nature and who can blame them really. Supporting a use-case that almost no one cares about anymore is rather unrewarding.
As others have mentioned, there are plenty of ways to achieve this on Linux today, they just seem to involve more fiddling than you'd like. That, unfortunately, is the nature of the beast.
Linux is a tinkerers OS (that just happened to become popular for servers) and expecting it to change its stripes is asking a lot :-)
> I imagine that when storage became more plentiful OS developers became less interested in implementing solutions to problems of this nature and who can blame them really.
You say this like making an application this way is some difficult problem. The whole point of me pointing out that it was the way applications worked on a Mac in 1984 (or indeed any of a dozen other desktop OSs) is that it isn't actually difficult at all. The difficulty it appears to have on Linux is all artificially induced by the culture of Linux software development.
> Linux is a tinkerers OS (that just happened to become popular for servers) and expecting it to change its stripes is asking a lot :-)
I don't expect it to change. I've been hoping Linux people would see the light for 20 years and it hasn't changed. That doesn't mean I have to like it or pretend that it's a good idea.
> [0] There are dozens of tools on my list for this, mostly around application and container management.
Could you share that list? I've had precisely the opposite problem with container management - whenever I have to use Windows, I find container management so unwieldy. And what do you mean by "application management"?
That's fantastic! I've been trying to package as many apps as I can as flatpak (because flatpak rocks, fight me), I will definitely look into winepak to package Windows-only software. The fact that it uses a standard and common-place technology, it just needs more exposure IMO. This is the first time I have heard of it.
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 BST
> 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?
The flatpak hate gang strikes again. Seriously, more bugs than Wine? For the first time we have a cross-distro packaging system, and I still hear people complaining that the olden days were better. Are you kidding me?
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.
no-one here said the olden days were better. it is possible for something to be generally in the right direction, but still in great need of improvements. dismissing anything not as positive as you'd like as unconstructive is itself unconstructive.
Ah, because saying that flatpak has more issues than Wine _is_ constructive. It is not even close to being true. Yes, I flew off the handle a bit there, but I'm quite done with the useless snark from some commenters, especially since it's pretty common on this forum regarding certain technologies, and in my eyes, completely unwarranted.
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...
Flatpak is only exciting Redhat who wants to easily provide up to date software on a very old stable base and to be the Google of linux software distribution and to prospective developers who don't at present already have a method of getting debs and rpms to end users easily. This is a small group.
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.
I am excited about flatpak for multiple reasons, which boils down to sandboxing:
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.
You will have to elaborate instead of throwing easy accusations like these. Linux namespaces are pretty tight, and I make sure that flatpaks that need sandboxing have the right sandboxing mechanisms in place.
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.
I'm going to go ahead and presume that anyone intending to release a malicious app or compromised update to a non-malicious application has access to a similarly configured system.
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.
I don't know why you're getting down-voted, it's a legitimate question since the main page doesn't mention wine once.
It is a Wine frontend though, seems to also integrate wine-tricks for dependencies, DXVK and other things from the wine eco-system.
Bottles are isolated Wine environments, similar to containers or VMs. This allows you to install components (e.g. msxml3) to, and modify the configuration of that environment to make the program work without having it affect other applications.
Every WINEPREFIX defines its own Windows disk drives, so the filesystem is effectively sandboxed. Conventionally, there's (often? always?) a Z:\ drive which points to / on the Linux filesystem, but there doesn't have to be. You can add or remove drive mappings without any additional tools beyond WINE itself, and applications running under WINE can't see files that don't have drives mapped to them, afaik.
>Every WINEPREFIX defines its own Windows disk drives, so the filesystem is effectively sandboxed.
No, it is definitely not effectively sandboxed. You only need to access / instead of Z:. Wine has no sandbox mechanisms built in. It is also a fairly large codebase which definitely has a bug or two that could be exploited to get around such mechanisms if they existed.
To effectively sandbox, you need the kernel's help. Linux offers namespaces and control groups.
The way you use these comfortably behind a layer of abstraction is through containers. Bottles uses flatpak for the purpose.
> No, it is definitely not effectively sandboxed. You only need to access / instead of Z:. Wine has no sandbox mechanisms built in. It is also a fairly large codebase which definitely has a bug or two that could be exploited to get around such mechanisms if they existed.
If you don't have Z:\ enabled, how do you actually access those Unix-like paths? When I launch a WINE command prompt in a prefix with no Z:\ enabled, I get:
wine: could not open working directory L"unix\\home\\pxc\\", starting in the Windows directory.
Microsoft Windows 6.1.7601
unix\home\pxc>dir
Syntax error
unix\home\pxc>cd ..
unix\home>dir
Syntax error
and so on. What Windows APIs are Windows programs supposed to use that will let them see parts of the Linux filesystem that are not mapped as Windows drives in WINE?
> To effectively sandbox, you need the kernel's help. Linux offers namespaces and control groups.
> The way you use these comfortably behind a layer of abstraction is through containers. Bottles uses flatpak for the purpose.
This is an improvement for sure, but I've never, ever had some WINE program run amok on my hard disk outside of the drives letters defined for it in the WINE configuration.
Thanks for pointing out the more thoroughgoing sandboxing that Bottles uses beyond just the WINE drive mapping, though.
WINE will automatically create the WINEPREFIX directory for you if it doesn't exist, so it's even simpler than that :)
The real value of bottles (or crossties, or PlayOnLinux definitions, or whatever) in in encoding all the tips and tricks required to get some piece of software running under WINE in a form that lends itself to easy distribution and automation.
Is it still blocked for you? I'm on ACT broadband and the site is available to me, but i think Jio is generally more restrictive.
(For anyone reading from outside India, yes, the government blocks a lot of websites, different internet providers seem to implement different lists, and nobody afaik knows what the actual official list is - or maybe there isn't one, just general instructions from the government about what sort of websites to block, hence the variance.)
I'm curious, how does this work? It's a HTTPS site, so it's basically a MITM attack, which is not technically possible, is that right? Are you required to install some certification from gov?
But if SNI based blocking is the case, it should give ERR_CONNECTION_RESET, here the page appeared with apparently a (cloudflare issued) Valid SSL Certificate with the given text. Isn't that supposed to not happen?
This is what curling the output gave me earlier: https://pastebin.com/Ae5DMn04 , Now the site has mysteriously started working.
This should only be possible if the request is being intercepted somewhere between Cloudflare's server (which might have a unicast location in India) and the actual server that might be happening over HTTP, which is a serious issue! This would also explain why it works sometimes and fails the other times. But that won't explain why it shows my ISP in the blocked message.
To further support this theory, Wireshark showed nothing weird in the TLS exchange, So it either suggests my ISP has cracked encryption (unlikely) or the link between cloudflare middleboxes and the "Internet" should be treated as insecure.
The initial TLS handshake contains the hostname in plaintext, also DNS queries can be sniffed.
On the other hand, MITM would be like changing a certificate in an attempt to alter traffic, this case is simple traffic blocking by doing packet inspection. (Which is also not nice obviously)
Amusingly we're getting to a point where it's easier in many cases to just target Windows than ship native binaries for Linux.
So then the question arrives: since there's going to be a native Windows binary regardless what's the point of putting in the extra effort if it works well enough?
I think compatibility layers (Wine/Proton) are very useful especially considering many developers don't want to put the effort into making a well supported Linux binary (or make something open source so it can be compiled/patched against updated system libraries), but it very well may be a snake eating its own tail situation that hampers further adoption if things are "good enough".
Is this surprising? It has been the default format for 25 years, and a lot of experience and tooling has been developed to support it. It would be very hard for a competitor to overtake that head start advantage.
So is this a Libc issue? Or other standard libraries?
Can we not just try to have a fixed set of interfaces for these libraries or am I insane to think that they don't need to change really any more? (In 99% of cases?)
It feels like everyone doing their own thing in these areas is just making everything totally painful for application authors and so people are coming up with insane bundler systems that just hide the real problem.
I feel like if you could take an application compiled for Ubuntu 4.10 and run it on Ubuntu 21.10 without recompiling it or putting it in a VM then maybe this probably wouldn't be the case. Sadly we don't live in that world.
> The Wine runner is used for all Environments and is therefore in all bottles created, but also for external prefixes imported into Bottles. We support 3 different runners:
I haven't used this software, but FWIW i almost never have to create isolated Wine (well, Wine-staging) environments. I've installed pretty much everything - applications, games, etc - on the default wine prefix and things tend to work just fine. Though i do have installed DXVK and VKD3D-Proton as well as the windows media framework files for games to work properly, but i do not see these as anything different to what i was doing on Windows anyway - including using DXVK to run some D3D9 games that were otherwise broken.
I think in general Wine and Wine-staging are good enough nowadays to not need game-specific hacks that affect the entire wine prefix anymore.
+1 for Bottles. Have been using it for a while. Its excellent. It also has an inbuilt task manager, command line access, and so on for a container/bottle.
First impression is that the gui is beautifully designed, installation on NixOS was (as always with prepackaged Nix packages) painless.
I'm not sure what I should use it for though since I don't really run any windows applications other than games, and I use QEMU for that, only game that hasn't worked in QEMU is "Halo Infinite".
The reason I don't use proton is because compability isn't 100%, whereas actually running windows gets you to a 100%, if we don't count games with predatory anticheats, but those don't work on proton either (For now).
I'm REALLY superstoked about Intels new HPG GPU's, it's rumored they'll have SR-IOV support, meaning I could partition the GPU to run both Windows and Linux at the same time. (There's support for it in my 11th gen Intel CPU on my work laptop, but the software isn't there yet, so I'm not certain it'll work)
Yeah I read the website and thought Bottles for winning Ng windows apps on Linux is already a thing - looks like this is a different company that’s ripped off the name.
Ooh this looks very nice. I love how wine “just works” but it means I’m sometimes just really unaware of what’s going on or how my system is configured.
I admit I sometimes just open winetricks and more or less randomly click on a bunch of things to see if it will fix issues when I have them… this might help me out with that
I've tried this on PopOS and unfortunately it was really unstable and couldn't start applications.
But otherwise I think the interface is already better and simpler than some other GUI frontends for wine.
this could be a completely different issue to yours, but i ran into a problem with some software where i selected the .exe installer to run but it wouldn't work as bottles didn't have access to the other installer files in the same folder.
when i moved the installer files inside the bottle it worked no problem. alternatively, flatseal will let you set up permissions for bottles so that it can access your home folder
It (optionally) uses a fork of Proton, the Valve-developed compatability layer. All containers use Wine, but Proton and Lutris are more complex and support more modern titles
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.
Kinda rediculous that they tell people to install Flatpak for "the best experience" when their docs say things like:
"After multiple requests, it is now possible to generate the desktop entry for a program directly from Bottles.
...
this feature is not coming for Flatpak users, due to lack of permissions. So if you’re using Flatpak, please don’t worry about this feature, we still have other plans for you."
Sounds like Flatpak isn't the best experience then, is it?
Then I tried to install an app, launched .exe installer
My PC froze, I couldn't even move my mouse, so I had to hard reset.
I tried a second time: this time I was able to move my mouse for about 10 seconds while seemingly nothing happened (other parts of the system froze). Then it, too, froze. So, hard reset again and hard pass on the bottles.
After reboot I had to run fsck on my disk, not a great experience
Why is this better than playonlinux (contains "quirk" solution for lots of productivity software and is also based on fully managed invidiual wine prefices) or lutris or steam w/ proton for games?
Can this run office 365 on Linux. I don't really care about alternatives, I need Teams, One Drive, PowerBI and Excel or I can't move. Otherwise I have to stick with WSL
WSL2 is probably hard to beat. They've added GPU passthrough, and now have Wayland built-in with wslg. Some buggy stuff remains, systemd support is a bit rough, etc. But they do keep iterating. I do wish they had a full-screen mode where you could use your own window manager, like many Windows X11 servers optionally allow.
But it's good enough now that I rarely find things that don't work. At least for now, it's also a bit of an escape from corporate over-management of desktops. Most companies haven't yet figured out how to overmanage it in the way they do with regular Windows, Linux, and MacOS.
They move to linux to be in control of their OS, to manage their dependencies and to embrace an open platform that scale from embedded to IoT to datacenters
If your goal is to use a proprietary OS that spy on you and is bloated, only to run a linux VM, then you don't understand why cloud native is 100% linux
That's the problem of the people who work at Microsoft have, they became blind and don't understand the real intent of people using linux!
Bloat driven development is certainly not one of them!
I agree that set of people is one group of users. I use WSL to write code for work, where I also need Windows for Office and some drawing tools. I imagine I'm not the only one.
I downloaded the installer from a windows machine. After trying to install and run, it still complained about a missing implementation. The tutorial explains how to install using wine 5.11, to make it run correctly, simply run it using wine 5.12 after installed.
I used bottles to install wine versions my distro wasn't shipped with. Also used winetricks to install fonts. At the end it works, but be aware: it is slow and buggy.
It's been getting much better over the years, I remember Pivot Tables making it in being the hot shit in the online version a couple years back, but it's still not to parity for advanced use. The biggest pain point probably being limited data sources though I think there is still a file size limit too (30 MB last I remember, better than at first!). New features still get cooked in the desktop previews first as well e.g. even if your account is set to insider preview lamdba won't work in Excel Online at the moment.
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.
Android office apps seem to work for me via waydroid. Otherwise, web office seems to be enough for 90% of people (where libreoffice and onlyoffice already seem to cover the needs for 70%). Of course, you might have a very specific need for MS Office, no judgement :)
Looks terrific. I have actually not needed to use Wine for so long due to the proliferation of web software and cross platform applications but perhaps if I were to play games!
Yes, this would be great for gaming, but I personally play almost all of the games from Steam. I even add shortcuts to native Linux non-steam games to Steam library, so all of them would stay in one place.
I just wanna ask if i download ubisoft connect (gaming service) or epic game launcher, using this app, would it be easily to run? btw, I'm using linux mint.
I wonder if this will work for running Java GUI scientific apps (Gephi, Concept Explorer) that are pretty much impossible to get running correctly on Linux.
I haven't tried it so take this with a grain of salt, but it seems that terminal-only apps are supported fairly well. I see from the docs that you can even use Brew from inside Darling.
Many people (like myself) are very happy with Linux and have been for years. We have no interest in "auto rebooting for security patches", "treating file locking like it was security" or having "relevant ads" shown to us. However, there might be 1 or 2 Windows apps we wish to run, so things like this are nice. I assure you that my overall experience is not "more difficult" than Windows (the exact opposite in fact).
People keep saying that, but the only stable experience I have had is with Windows. Every single Linux distro I have tried (Ubuntu, Debian, Manjaro, Fedora) has been inherenty more sluggish and painful to use than Windows for me (even if you were to ignore the initial setup problems with various hardware).
Windows unactivated is actually free to use (just use a generic key from its official documentation) and most of its preloaded bloatware can be removed with single-use scripts.
It’s so much of a surface area that it’s hard to be objective on all fronts, nothing is perfect and I could come up with 1000 ways that Linux is better or that macos is better or that windows is better. But it largely doesn’t matter.
The parent postulated “why not use windows”. Well, I don’t like using windows but often I need to run software developed for windows.
The same way that windows now has an emulation/virt layer for Linux, people want to use Linux programs from windows.
I dont begrudge those users for using Linux software on windows or look down on them for that.
Enjoying the Experience of the operating system you use is just so incredibly subjective…
I recently had the mispleasure of reinstalling a windows machine and kept getting frustrated at the requirement to have a Microsoft account, drivers that didn’t seem to find my drives (?) but could with an Intel computer from the same brand (and similar model) of motherboard. I got frustrated when trying to use the win32 api because it expects WTF16, padded and null terminated strings but only passed as mutable pointers.
And if you want to pass a strict to a function, you must pass a raw pointer. Which is inherently unsafe in rust.
These things annoy me.
Then: I tried to activate windows and saw the jaw dropping price. The price is more than a quarter of a reasonably priced home PC. No wonder the OEMs install bloatware to get the price down.
Because we need some Windows-only software and some Linux-only software. And the occasional Mac-only (or whatever else) software too. Life is less difficult when it all works in the same window manager and accesses the same filesystem, if that is possible.
not sure if you are trolling or not but i have around 60 programs that i use on linux and 1 program that only supports windows, so having to dual boot just so i could run 1 program would make things a lot more difficult
Windows can run Linux in the subsystem and has a better Android emulator than Linux. Windows doesn’t run old windows programs as well as wine though, and if it hasn’t happened yet I can’t wait for the day you run legacy windows programs in the Linux subsystem through wine.
You’re not wrong, using virtualization like a Windows VM in Linux is still using windows and is the best way for compatibility. Wine either works ok (mostly), needs lots of weird configuration to get it to intergrate into Linux or look ok, or it doesn’t work at all most of the time.
mainly reason 11 (DAW, music making software), then also mp3 tag editor, a gpx editor, jpegview, and a few others a can't remember. they all have pretty messed up ui but some of them are still better than any of the linux alternatives ive checked out so far and some i just haven't bothered looking around yet
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/