Not op but that's missing the forest for the tree. Those devices are not meant to be e-waste conscious at all, which is the undertone here: you can't replace the battery yourself, you can't expand storage when you need, you can't safely expand their life when they are outside of Apple support period because they are soft and hardware black boxes. Instead, you just buy anew.
True, Apple is no more no less guilty of this than the competition, but they are also not shifting the needle while pretending to do so, with so many untaped opportunities.
Not true at all. I have a close friend (not an electronics or programming nerd in any way) which has replaced the battery (and a screen) on multiple iPhones with nothing more than iFixit instructions.
> you can't safely expand their life
Again, not true. See above.
> with so many untaped opportunities.
Which is obvious I agree with, since I said they absolutely should be better at repairability. But consider the dismissive tone of the original comment, which is justified with false information.
To give you an exaggerated example, let’s say someone is telling you about all the awful practices Nestlé engages in. All of them are true, but then they end with “and their CEO is literally Hitler, who survived and changed his face due to an agreement with the Beelzebub, and is going to control humanity through chocolate”. At that point most people would dismiss them as a nut job and ignore the other true valid points as fabrications too.
Which is why we should criticise, yes, but based on truth, not lies and rage bait.
They didn't say "nobody can replace the battery themselves", and "you" here was probably intended to mean "a normal consumer". Relative to items with replaceable batteries (a TV remote control, a camera, a pre-iPhone mobile phone), the batteries are extremely hard to replace.
The batteries are also not safe to replace, relative to items with replaceable batteries. There is a very low chance of me accidentally damaging my TV remote control while replacing the batteries.
None of the information you're responding to is false, and it's perhaps worth asking yourself why you're here defending Apple.
There's an easier argument that is simply "But Samsung!".
> and "you" here was probably intended to mean "a normal consumer".
Which is why I used a normal consumer as an example.
> None of the information you're responding to is false, and it's perhaps worth asking yourself why you're here defending Apple.
I’m not defending Apple, I’m defending accuracy. When someone says something inaccurate about someone or something I oppose, I try to correct that too. It’s important that arguments are based on truth, because when they are not people start dismissing the true with the false.
My comment history shows I’m an Apple user but am constantly criticising its current state and Tim Cook. You’ll find more comments of mine criticising than praising them.
Perhaps it’s worth asking yourself why you see someone making an argument once and immediately assume they may have ulterior motives, and why you’re actively ignoring the arguments which do not feed your view, including my clear and repeated assertions in the thread that Apple should absolutely do better.
> There's an easier argument that is simply "But Samsung!".
Which was not once my argument. I abhor whataboutism.
Exactly, "automate your WhatsApp/Signal/..." sounds like "use XMPP for that use case", that's my go-to for bots and notifications, it works as well if not better, and I sleep better at night.
not OP, and indeed git is fast-enough in many cases, but git not cutting it at Google and Facebook scale, combined with the versatility of mercurial (monkeypatching and extensions system) was the reason why they both invested heavily in mercurial instead of git.
Among the tricks being used was remotefilelogs, which is a way to "hydrate" content locally on-demand, which was mimicked in git many years later with Microsoft's git-vfs. Same goes with binary/large files that git eventually got as git-lfs.
It's funny to think that a big reason for git to be "fast" today is by playing catch-up with mercurial, which carries this "forever stigma" of being slow.
> I think there are (or perhaps were) some product issues regarding the specifics of various workflows.
I love jumping in discussions about git branching, because that's a very objective and practical area where git made the playing field worse. Less and less people feel it, because people old-enough to have used branch-powered VCSes have long forgotten about them, and those who didn't forget are under-represented in comparison to the newcomers who never have experienced anything else since git became a monopoly.
Yes, every commit is prefixed with the branch name. Because, unlike mercurial, git is incapable of storing this in its commit metadata. That's ridiculous, that's obscene, but that's the easiest way to do it with git.
Just because there is one project apparently using this in a way that indicates someone could perceive something as a weakness... It doesn't mean it's a real weakness (nor that it's serious).
You can just not move branches. But once you can do it, you will like it. And you are going to use
git branch --contains COMMIT
which will tell you ALL the branches a commit is part of.
Git's model is clean and simple, and makes a whole lot of sense. IMHO.
> Less and less people feel it, because people old-enough to have used branch-powered VCSes have long forgotten about them, and those who didn't forget are under-represented in comparison to the newcomers who never have experienced anything else since git became a monopoly.
I'm old enough to have used SVN (and some CVS) and let me tell you branching was no fun, so much that we didn't really do it.
> one that they're able to represent in Git's model, with Git's features. They're even able to do it without exposing me to it. But the same isn't true in reverse. Strictly superior?
not sure what you mean to say, but for thoroughness' sake, no: git and mercurial concepts are not interchangeable, with git having mostly an inferior model.
To give examples: git has no concept of branching (in the way every VCS but Git uses the term). A branch in git is merely a tag on the tip of a series meant to signify that all ancestors belong to the same lineage. This comes with the implication that this lineage information is totally lost when two branches merge (you can't tell which side of the merge corresponded to which lineage). The ugly and generalised workaround is to abuse commit message (e.g. "merge feat-ABC into main") to store an essential piece of the repository history that the VCS cannot take.
Another example is phasing: mercurial records at commit level whether it was exchanged with others or not. That draws a clean line between the history that's always safe to rewrite, and which that is subject to conflicting merges if the person you shared those commits with also happened to rewrite them on their end.
> Then one day I was getting ready to go on a work trip with a half-finished feature on my work laptop, and realised there was simply no in-model way for backing that wip up to the repo. If I lost my laptop, I lost the progress. mercurial-scm fails at SCM.
Sorry to be blunt, but that's a skill issue: hg is no different than every other VCS in that regard. If you want your WIP changes to leave your laptop, you've got to push them somewhere, just like you would in git.
I'd like to fill up some inaccuracies in your response:
- rebasing in Mercurial simply means chopping a subtree off of the history and re-attaching it to a different parent commit. In that sense, rebasing is a very useful and common history-rewriting operation. In fact, it's even simpler and more powerful/versatile than in git, because mercurial couldn't care less if the sub-tree you are rebasing belongs to a branch or not: it's just a DAG. It gets transplanted from A to B. A may or may not be your checked commit, or be the tip of a branch, doesn't matter.
- that mercurial requires a configuration toggle before rebasing can be used (i.e. that the user need to enable the extension explicitly) is a way to encourage interested users to learn their tool, and grow its capabilities together with their knowledge. It's opinionated, it may be too much hand-holding for some, but there is an elegant simplicity in keeping the help pages and autocomplete commands just as complex as the user can take it.
Sure, but since commits have a branch attribute attached to them, "rebasing" does not appear to be "first class". It is something that has to be bolted on with an extension.
> because mercurial couldn't care less if the sub-tree you are rebasing belongs to a branch or not
IIUC Git also does not care much about the rebase target being a "branch".
I agree that Mercurial provides more value out of the box than git because it preserves branch info in commits.
I can live with Git because Git is "enough" if used carefully and after coming to terms with the non-intutive UI.
> Sure, but since commits have a branch attribute attached to them, "rebasing" does not appear to be "first class".
Again, that's orthogonal: you may or may not use "named branches" (the kind of which persists at commit level), rebasing works either way consistently and predictably.
> It is something that has to be bolted on with an extension.
The extension ships in core, UX is why it's not enabled by default.
> IIUC Git also does not care much about the rebase target being a "branch".
Indeed, it's just that things likely get weird (for no good reason) when you don't (detached head, "unreachable" commits)
> I can live with Git because Git is "enough" if used carefully and after coming to terms with the non-intutive UI.
That's our sad state of affairs. JJ helps a bit, though.
reply