No I actually hope that industry becomes infeasible. I hope enough people get off their platforms so they go out of business. That industry needs a complete overhaul.
atyaz
I think in this context "the ice" means the ice cream
I'm not sure what you mean exactly but I think you might be missing the point. Google is using chromium's ubiquity to exert control over how the internet works. Chromium being so ubiquitous makes it so web servers can lock out other web browsers.
If you want the entire internet to work like an adobe product, where one company has absolute control over it, then yeah your analogy works. But the whole point is people don't want that.
Okay. But google controls chromium, and everything that goes in it. And they're using that control to change how the internet works. So just saying that "chromium is a problem" can be considered a useful shorthand so you don't have to explain that every time.
Yes but it was changed quite a bit, it supported way more standards and was getting way more updates to keep it up to date. The issue is that was expensive and also people complained that it some websites didn't work on it, so it made more economical sense to switch it to chromium. I really wish they had kept it though.
"Reapply" is rewriting it on the other branch. The branch you are rebasing to now has a one or multiple commits that do not represent real history. Only the very last commit on the branch is actually what the user rebasing has on their computer.
In this thread lots of uninformed people rationalizing why it's actually okay to use chromium.
It would be a monumental effort for smaller browsers to keep chromium extensions working, while the rest of the ecosystem moves to the new APIs. The only way that could work is if they all fork chromium and base their browsers on this new fork, and even then it's not guaranteed to develop a real ecosystem of plugins since chrome has more users than all of those other chromium browsers combined.
So yeah you have to use Firefox if you want to avoid that, at least for now.
Always merge when you're not sure. Rebasing rewrites your commit history, and merging with the squash flag discards history. In either case, you will not have a real log of what happened during development.
Why do you want that? Because it allows you to go back in time and search. For example, you could be looking for the exact commit that created a specific issue using git bisect. Rebasing all the commits in a feature branch makes it impossible to be sure they will even work, since they represent snapshots that never existed.
I'll never understand why people suggest you should default to rebasing. When prompted about why, it's usually some story about how it went wrong and it was just easier to do it the wrong way.
I'm not saying never squash or rebase. It depends on the situation but if you had to pick a default, it should be to simply merge.
That is absolutely not what rebasing does. Rebasing rewrites the commit history, cherry picking commits then doing a normal merge does not rewrite any history.
That's fine but the point of the post is that you have to use a non chromium browser to avoid wei. Once it's implemented it's likely that edge and others will have to implement it too.
Right but it would be an even better alternative if you had the choice who to block.
Btw blocking instances at the user level is a feature that will be coming to lemmy soon.