That site isn’t RedHat/GNOME. From the bottom of the letter:
Note: Even though some of us are Foundation members or work on GNOME, these are our personal views as individuals, and not those of the GNOME Project, the GNOME Foundation, or our employers.
They aren’t against user theming. Again, from the site:
If you like to tinker with your own system, that’s fine with us. However, if you change things like stylesheets and icons, you should be aware that you’re in unsupported territory. Any issues you encounter should be reported to the theme developer, not the app developer.
They’re against distributions shipping custom stylesheets by default. Which makes sense! If a user has a stock installation, and an app looks broken, they aren’t going to assume the distribution messed it up. They might not even know that the distribution changed the theme. It can also cause confusion for users when their app doesn’t look like the screenshots from the developer. These cause issues for app developers.
That’s it. That’s all the letter is saying. It’s not a crusade against you theming, it’s asking for theming not to be done by distributions.
(P.S. I don’t intend for this to be aggressive. Just wanted to explain a bit more, because the name does sound… not great.)
Yes, but only for apps that which I want to be on the very latest versions. One might ask why I don’t use a rolling release distro, that’s because I prefer a solid LTS base.
I usually use the terminal, so that is something I need to make sure of. Otherwise, using the Software Store I can explicitly choose which version to use.
I want to be on the latest Firefox and to have the latest LibreOffice and some other apps. I want the latest applications, but I don’t want them come at the expense of having my system randomly lose its Wifi at the next boot or some other trash.
FreeBSD had this figured out 25 years ago. Separate the base from the user apps. When I was a teenager, I built -current ports on top of -stable FreeBSD and it was fine.
Now we have the equivalent option in Linux, and it comes from a centrally managed repository i.e. I’m not downloading tarballs and managing my own packages. I’m too old for that crap.
First Linux servers I installed were RedHat 4.2. I stick with RH until 8.0. Then they stabbed us all in the back, starting to charge for it.
Have you RH users been fooled twice?
I switched to the then (and still?) distro that was most strict in commitment to FOSS - heck, they forked FireFox just because of the logo copyrights - Debian.
(RH to kubunto at home, because Debian then was (is?) too “enterprise” for home, and I wanted to stick to the same packaging)
The only other distro I’ve been using is SUSE (SLES), because that’s what SAP suports for HANA database servers.
SUSE should gradually morph the RH fork into becoming SLES, and always provide an easy automated way to migrate, a one way only route to leave RH.
I like the quotes she put up on the screen about Canonical and System76.
I’ve kept coming back to Ubuntu over the years, but ultimately, they are a corporation, and they need to satisfy their shareholders. Someday they will likely be bought out, then who knows?
Some apps automatically pick up your theme some don’t. For these I give the specific app access to my theme folder with a :ro at the end of the path.
IDEs should work ootb. If some extension doesn’t work, maybe it’s because of poor support for Flatpak. 9/10 times you’ll find the issue is that app is calling the traditional /usr/bin path etc. when Flatpak installations use different paths.
Appimages are nice. I just would like there to be some hub for them which also enables the appimages to be updated through it. I know about zap for example but it’s not up to par with flathub or the snap store.
Flatpaks (and Snaps, and Appimages and Docker containers for that matter) are essentially designed for app developers who grew tired of distro maintainers demands to fix certain things about their build systems and their applications that broke when their apps were used on distros other than the exact distro and version the developer was using. They are designed to take a “kill the messenger” approach to the problem and now people are wondering why the work that the distro maintainers did before doesn’t get done any more.
I have enough money to buy a more modern Lenovo laptop, but I’m definitely considering getting one renewed simply because of how cheap it is. I’d prefer newer age specs tho. Thank you!
I also had one and not because of any money restriction. It’s just an amazing machine with a few tweaks and the CPU limitation are actually a plus since it will push you towards cli/tui and that’s where the fun begins
Tl;dr it’s likely that some of your hardware isn’t well supported in Linux or have vendors downright hostile to open source (fuck you, Broadcom and Nvidia) and causes you weird issues that almost always get fixed by the community but may not always work “out of the box”
I’ve been in Linux since 2008 and have asked this question in many ways over the years. To get a real answer I’d dig more into the errors you’re encountering. I think that a lot of the “simple fixes” you mention are simply options that some hardware configurations need and some don’t.
Flatpak and Linux in general deal with the same huge task as Windows, which is “support any hardware configuration with one universal solution”. While Windows is given every advantages by cooperative hardware vendors releasing official drivers, Linux is mostly supported by open source reverse engineered drivers.
This means that no “universal” system is likely to work all the time in every case, but that’s ok because it’s all open source and the community finds a way.
You mentioned themes and some graphical packages, do you have an Nvidia GPU? I never had anything but trouble on Linux with them.
It has nothing to do with my hardware. Like I said fixing the theme was done with a simple command that basically mapped my user .icons folder to the flatpak one. My point is just that why isn’t this done automatically. Why isn’t there a system in place that will deal with this.
I can't say with any specifics but flatpaks are sandboxed on purpose, when you override something you're giving it more (or less) permissions than the developer thought they'd need. "Automatically giving permissions the developer didn't think they'd need" seems like a crazy thing to try to automate, no?
Check out Flatseal if you haven't already. It's a GUI for flatpak permissions. Might make your life easier in the future.
Yeah I understand the reason why it is the way it is. I think it should be simplified. Just a pop-up box asking the user if it’s ok if flatpak gains Access to path x. That’s what I have in my mind. Maybe with time it will improve.
It was mostly rhetorical. There's no way to know that you want the application to have extra access to some folder needed for your theme. That's the exact kind of thing that would be better handled on a user-input level. You applied your theme, you notice that it is broken with the app, you apply the new expanded permissions to get it to work with your theme.
I can feel your anger and frustration in your messages here and I just wanted to say I think your idea is fantastic and you have an ally here to fight with you.
If it bothers you that much, write one. 85% of Linux was constructed by frustrated nerds deciding to write their own solution to a problem they found. There is no parent company to complain to, just fix it yourself and distribute the solution. Else, you'll need to wait for someone else to do exactly that.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.