...and there's clearly huge market-demand for Windows LTSC amongst retail customers, and yet, MS's C-levels already decided for them that no amount of love nor money - excepting a sufficiently large enterprise licensing contract - can legally entitle you to a license - or even official media - for Windows LTSC.
It reminds me of when Adobe ended perpetual licensing and switched to cloud(TM)-only, subscription licensing for Photoshop, et al: many of us (myself included) assumed that Adobe was surely making a foolish mistake to abandon perpetual-license customers, but it turns out[1] that was the plan all along: those customers are a vocal minority who can demonstrably afford to pay more, the rest of the customer-base doesn't care enough to switch to a competitor. Over 10 years later (2013), we haven't seen any of Photoshop's then-promising upstart competitors come close.
...on that basis, I don't think MSFT's recent backpedalling on Windows 11's disrespect for its own users is in any way a response to us power-users complaining online - or even because any number of us did fully migrate off Windows and onto Linux, but instead because of all the recent talk overseas from foreign governments (France, Germany) taking active steps to secure their digital-sovereignty and deploying more Linux desktops; and a good way to get people (and decision-makers in government and large businesses) personally interested in digital-sovereignty is by pointing out how shitty their own corporate desktop UX has gotten.
I'll gladly eat my hat when/if MS graciously allows regular retail consumers, and not just large organizations - and those of us with a $2000/yr MSDN Subscription - the privilege of paying for an OS without advertising built-in to the shell and having hard dependencies on proprietary online services.
I think siblings point needs to be made more sharply: this could've gone somewhere good, "I evaluated it and found the gain was not worth the cost to change", but instead went to "the gain from a change is insignificant 99% of the time, so it's not worth understanding it".
As someone else said, jj comes into its own when a reviewer insists you split your PR into many commits, because they don't want to review 13k lines in one chunk. In that case it is easier because there is no rebase. To change a PR commit in the middle of the stack you checkout a PR commit, edit it - and done. The rebase happened automagically.
Notice I didn't say "edit it, commit, and done" because that's another thing you don't do in jj - commit. I know, `git commit` is just a few characters on the cli - but it's one of several git commands you will never have to type again because jj does it without having to be asked.
If the rebase created a merge conflict (it could do so in any PR commit above the one you edited) - it's no biggie because jj happily saves merge commits with conflicts. You just check it out, and edit to remove the conflict.
Jj does grow on you over time. For example, when you start with jj you end up in the same messes you did as a git beginner, when you recovered with 'rm -r repository', followed by 'git clone git@host/repository.git'. Then you discover 'jj op restore' which compared to git's reflog is a breath of fresh air. And while you might at first find yourself chafing at the loss of git staging, you gradually get comfortable with the new way of working - then you discover `jj evolog`, and it's "omg that's far better than staging". Ditto with workspaces vs worktrees, and just about everything else. It might be difficult to lose work with a bad git command, but actually impossible to lose work with a jj command.
It is a steep learning curve. We are talking months to use it fluently instead of treating it as git with better porcelain. If all you ever do is work with one commit at a time, it's a lot of effort for not a lot of return. But as soon as you start managing stacks of changes, duplicating them, splicing them, it makes you feel like a god.
That said, if you are starting out - I'd suggest starting with jj instead of git. You've got to go through a learning curve anyway. You may as well do it with the kinder, gentler, more powerful tool.
Git rebases don't work if there are conflicts, jj doesn't have this problem. Also idk if you can rebase onto multiple parents with git but jj can do it.
JJ can save conflict related state with the change so that you don't need to resolve a conflict in the middle of a stack of changes for rebasing to continue for the remaining changes. Concretely, it uses a "conflict algebra" where it can track the impact of a conflict as it propagates through the stack of rebased changes: https://docs.jj-vcs.dev/latest/technical/conflicts/
You have to fix them at some point, but not in the middle of doing other things. Right now. With no possible way to make progress elsewhere while deferring this decision.
Not really very similar at all for the scenario discussed here. Rerere remembers how you have resolved a conflict before. It doesn't let you rebase a stack of commits that result in different conflicts. You will have to stop and resolve each conflict and then `git rebase --continue`.
Avoiding manual conflict resolution isn't really a good thing though - conflicts are an indication that multiple different changes affect some code and you really should think hard about what the combination of them should be. Even what git does automatically already can be dangerous.
i get wanting to make money, but if i don't get all the benefits of tooling until i start paying a ton of money...why benefit do i have by using this at all? especially when there are other avenues that are all free
We're very aware that we need to balance our need to make money with the need to make Avalonia accessible for everyone. For this reason, for 12.0 we've made our VS Code extension totally free to use with no account needed and no usage restrictions.
reply