Can you elaborate what you mean by "cancel culture?" I have seen that term used so much for various things that the definition seems very vague and slippery. In this context, it seems to refer to someone acknowledging a personal failing and then voluntarily stepping down from a position?
The answer to that isn't putting all stores but one out of business, it's having a single-sign-on provider.
Also, I doubt you would criticize an embedded OS for only having process scheduling and hardware access, because that's probably all it was designed to do. Similarly, a low-cost store may want to skip on providing all those extra features so they can keep prices down.
Is all of that really a problem when the companies seem to have shown that none of that matters? The increased cut is apparently more valuable to them.
And I also should note, half of those items don't need to implemented in a store. People ask for them because they are implemented as extras in other stores, but strictly speaking the distribution and support are the only things the store needs to have to be called a store. Achievements, friend lists, user reviews, and cloud saves can be provided by separate services and work just as well, and could result in a higher cut for the vendors if the store doesn't have to shelter the cost for that.
I don't see how the current MacOS is any different from Linux there. For end-user applications you can have the user download an app bundle (equivalent to AppImage) or get it off the app store (equivalent to flatpak/snap). For random open source libraries and utilities, you still would want to use Brew or Macports, which are package managers.
Me too, that's why I'm asking about ways we can solve it for real so we can avoid the circular discussion. I've seen a great many people complaining that the Linux filesystem is "broken" but putting forth little effort to communicate their requirements or fix things. Please, let's be better than that.
So just to be clear, what would be relevant to you and what could be done to solve this? Since you already knew about AppImages and consider them a solution, could we say your criticism is essentially that not enough applications are using AppImages? (And if you were wondering, I am not associated with AppImages in any way, I'm just another person trying to talk to you about problems on Linux)
Please don't make these insulting and condescending comments, this is against the site guidelines. If you think my understanding is wrong then just explain it, you don't have to insult me. Again, there are solutions to these problems and there are people who are working on making it "nice" for whatever your definition of that term is. AppImages (or really any similar packaging method) also technically run on very nearly every single distro on the planet so if those were improved, it seems like that would change some of your criticism. You don't have to value my suggestions, that's why they're suggestions and not requirements.
Although I guess I don't understand, where is your criticism coming from if not from a period of past or current frustration with the filesystem organization? I'm only responding to the criticism as you wrote it because I think there are ways that the core problem can be solved. From the point of view of how we solve it, it doesn't seem like it is a different thing. Does that make sense?
It seems like you were having trouble with your Linux filesystem so I'm offering solutions that I've seen or heard of. Is there something else I can offer that would work better for you, or am I misunderstanding what the complaint is?
Edit: If you weren't asking for help with this that's fine, however some other interested reader may want to hear the suggestions. Feel free to ignore me.
I haven't "pretended otherwise" or evangelized anything, please don't make these accusations at me. I can only offer you suggestions on what to do, I'm not going to argue about what the "right" way to do is as that's simply not interesting to me. The vast majority of Linux distributions may not do things the "right" way but they also support AppImages, so use that to your advantage. If you had no success in getting upstream to make AppImages then you'll have to make them yourself. It seems that's what a lot of flatpak and snap packagers ended up doing, just my observation.
To put this another way: We can sit here making the same complaints about Ubuntu and RHEL that have been made for decades, but what's the point? Let's do something about it. And if that doing something means we turn the whole system into AppImages, then... what else would you really want? It sounds like your problem would then be solved.
Please do not baselessly accuse me of being "disingenuous," I'm trying to help you. If you won't use GoboLinux or ask packagers to make AppImages for the apps you want then I don't know what to say, those are solutions to your problem. If you're saying you want all other distributions to be like GoboLinux, I doubt that would happen because that comes with its own set of other problems. Edit: You can do some pretty interesting things here with Nix/Guix too although that still requires a package manager. The reason I said AppImages is because that's currently the best method that doesn't require any package manager at all.
It's popular for Linux distributions to have a scattered hierarchy with a package manager, but it certainly isn't a requirement. Take a look at AppImages.
There are numerous serious usability issues with the XEmbed tray icons [0], even if you stay on X11 you will eventually want to switch over to the StatusNotifier API [1]. This is supported by KDE, Ubuntu's Appindicator, and I believe XFCE now too. Thanks for your hard work in Budgie BTW.
I wasn't speaking of the trademark, you don't need a trademark to publish and promote a public definition of a term. Misusing that term doesn't have legal consequences but it won't stop people from getting upset at you for misleading them, e.g. your customers getting miffed when they learn the "open source" option you provide actually means they can't do anything with the source at all that they would expect to be able to do with the popular Apache/MIT/GPL/BSD options. (Correct me if I'm mistaken, but just those 4 licenses seem to be used for the vast majority of open source now)
Sorry I didn't clarify -- They came up with a phrase that, while it existed, didn't have a concrete definition. To give an example, if someone right now wants to create "Source Available Initiative" or something like that I think that would conceptually be fine, even though the term is already in use, there is no organization that is clearly defining what it means. Does that explain it better? (Although I think creating more organizations like this is a terrible idea for other reasons, mostly having to do with license proliferation)
I'm not saying they came up with the term before anyone in the world. While the term was used previously, it didn't have the concrete definition it does now. That's why they were able to do what they did.
You're right, but that misses the point, they put in the work to define and promote the term over a span of more than 20 years. If your plan is to undo that 20 years worth of work, you had better be prepared to take on the same amount of work over the same time span, and I hope the only reason it's done is because we can verifiably prove the results will be better for everyone.
I would agree with you if anyone was saying "hey the term open source doesn't mean anything and you can use it for whatever you want" but that's not what I've ever seen happening, and I doubt anyone wants that because it would make the term useless. What we actually do see is other groups trying to promote their own alternate definition of the term and trying to deny the OSI's usage, for equally arbitrary reasons. It's the same form of gatekeeping. Please just come up with another phrase, that's what the OSI did after all when they found the term "free software" to be inadequate.
Because they had a criteria and they conducted a review of lots of licenses. It's not any less "gatekeepery" if some random person or company takes their random license and says "here, we say this one license is open source based on our own criteria that we invented for ourselves, accept it."
I don't think that's important. In practice you can also use the pulseaudio API and that will work everywhere because of this: https://github.com/i-rinat/apulse
I think that's completely different from what was said in the GP post, but I'll address it anyway. I agree there should be anti-trust action taken against Google and Apple for their behavior with the app stores and there are actually solid claims to be made there. I can't say the same about them running a free email or social media service that has crappy support.
>If they had competition, they would be spending billions on customer support, but because they have a monopoly, they can get away with having virtually none.
I can't agree with this, there is so much competition in this field already and and it doesn't seem to make a difference. There will always be ad-supported free services with minimal support and few security/privacy guarantees, that is the entire low end of the market.
I can't say I've had the same experience, I've been using jackd successfully for around 15 years now. The modern Linux answer to audio fragmentation is Pipewire, and that should actually have less fragmentation than on Windows because it preserves ABI compatibility. (It's not entirely stable yet though)