ezst

Funny, I have it exactly the other way around!

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.

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.

Cory Doctorow made a whole CCC speech about this.

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.

Anyhow, let's pick django as a project that was using a VCS with branches before moving to git/github, and have a look at the repo history: https://github.com/django/django/commits/stable/6.0.x

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.

> 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.

Or subsidize nuclear because it complements beautifully solar & wind as cheap and clean energy?

Or the plethora of languages compiling to WASM, for that matter

> Are we back to "programming language X is slow" assertions? thought those had died long ago.

Yes we are? The slow paths of mercurial have been rewritten in C (and more recently in Rust) and improved the perf story substantially, without taking away from the wild modularity and extensibility hg always had.

This isn't an apology or a deflection, but different VCSes strike different trade-offs in terms of speed per workload. The mercurial storage model is comparable to video encoding in that it has a somewhat equivalent of "key frames" and alternates differential and full revisions¹. This makes workloads like bisecting or jumping to long-distance commits more efficient, at the expense of the time to create new commits.

For your use-case, mercurial has had a `largefiles`² extension for a very long time (long before git-lfs).

> I liked its features better, but chose git, and that was the correct decision.

Anyhow, my personal story with git is that I bought into the hype and social effects without really challenging my assumptions ("it must be the best, everyone says so"), until I got very fed-up with its obnoxious UI, and someone on IRC told me "ehh, give hg a shot". Nowadays, I mostly interact with git repos through hg-git and jj.

¹: https://www.kernel.org/doc/ols/2006/ols2006v2-pages-91-98.pd...

²: https://wiki.mercurial-scm.org/LargefilesExtension

Every success story and happy conversion to jj is evidence that hg should have won the DVCS war, but more importantly, that VCSes and their inherent merits and tradeoffs were always secondary to the social networks underpinning them. GitHub as a defacto monopoly really killed innovation in the VCS space, but also shifted the focus and attention elsewhere. That's why I don't think there'll be so much of a "post-git" without as much as a "post-github".

Wasn't CATIA running on unix even before it ran on Windows?

I obviously don't have a horse in this race, but this seems... more correct this way? And with Holland being a region (or two) and not the majority of the territory, how do the Dutch not living in Holland feel about it? It would seem like referring to Canada as "Québec", way to piss-off the non quebecers...

Why not?

Or you were just reading confabulations, without a way to tell, corrupting your knowledge in the process.

In general, I believe the problem of our time (sociopolitical divide, echo chambers, propaganda, people getting pulled to extreme viewpoints ...) isn't so much about the difficulty to access truthful information (most people would know how to fact check their beliefs and assumptions given enough time and motivation), but about the constant information overload that makes this process impractical. You are essentially softening your brain into accepting large volumes of information as facts, unchecked, and pretend that it's a good thing. You essentially don't know anymore the extent of what you know. Worse, you no longer know how you came to know, because the underlying principles and processes of knowledge (natural laws, models, theories, ...) were not involved in the learning (you could assert that day means light, and that night brings darkness because you have seen it repeated extensively and convincingly, but you wouldn't internalise this knowledge through the model of the earth orbiting the sun, and so you wouldn't know how to generalize from this knowledge into thinking about seasons or do any abstract reasoning on your own).

That is to say, we should be much much more cautious about what and how we read and learn about stuff.

Have you tried paperless-ngx, a true and tested open source solution that's been filling this niche successfully for decades now?

> Why we need these careful thought, abstraction and architecture?

your answer focused on maintainability, but you are overlooking what I think is the bigger problem: those components will eventually interact with one another (technically, by nature of living in the same code tree, sharing the same storage backend, framework, common libraries, …, or logically, by referencing the same entities for slightly different and complementary features). With that comes the need to centrally control what they should/can/cannot do. There is no shortcut to having to clarify (with your customer) and formally document what those layered interactions are, or, before you know it, you have multiple incompatible user access controls, row-level access policies, competing master/reference data, or different parts of the application interpreting differently the same data.

It's a pretty bad value proposition, if you ask me, to have to do so much hand-holding for a result that comes with no guarantees whatsoever (you will never know the extent of which your clean spec "made it in").

I can totally wrap my head around that, and it's an interesting thought experiment, though:

- building functionalities as components that are swappable on a whim requires a level of careful thought, abstraction and architecture that essentially is the exact opposite to ai slop

- in this day and age we still don't make software for the sake of it, and who's financing it doesn't generally require such levels of functional flexibility (the physical world commandeering the coding isn't nearly as volatile as to justify that)

- this comes loaded with the implication that "stuff needs to work": if you are developing software that manages inventory, orders, resources, ... you just can't take the chance to corrupt your customers data or disrupt their business processes. Shipping faster than you can test and with no accountability and no oversight is a solution to a problem I've personally never encountered in the wild

Any mid- to high-end pro-line laptop from the usual manufacturers (dell latitude series, lenovo T series, hp pro/elitebook series) gives you that, really (rigidly built body using magnesium/aluminum alloys, good input devices and IO, high-end config, …) and some practical perks (hot swappable batteries, repairable/expandable, on-site warranty, …)

That people on this forum convinced themselves that it's a reasonable take to vibe code a useful geometric kernel is profoundly depressing.

I haven't used a laptop in the last decade that wouldn't last a whole day on battery, or would hold any of those qualifiers for that matter, from Apple or other manufacturers. Not that Apple are bad devices, but they are flawed like the rest of them (often less, and sometimes more in areas that may matter less to you, the software being a major and increasingly one to me).

Also good to remember that Apple is a company of good devices and tremendous marketing, not a company of tremendous devices per se. That entails a lot of subjectivity and awkward tribalism.

> After I got used to working in windows instead of full screen all the time, I can't really go back.

Sorry if this comes across as disrespectful, but it smells like Stockholm Syndrome. You are choosing not to use the full extent of your screen estate, and that is your fine choice, but that is no excuse for making it hard. If you compound the whitespace, the thick borders and the generally oversized UI controls, not much of "productive space" remains available to get the work done. I am not interested in macOS as a content-consumption-first vehicle, though that's clearly where Apple is steering.

I don't understand how we keep hearing so often here about Apple OSes being so amazingly simple, approachable and cleverly designed with a lot of attention paid to detail, while every practical productivity advice involves some undiscoverable trick, or combinations of tricks, that seems so arbitrary and obtuse. I don't like Mac, in large parts because of that. No amount of marketing and peer pressure will convince me of the superior elegance and sophistication of something that hates you for wanting windows maximised. Those hidden tricks only add insult to injury as pervasive reminders of your presumed inadequacy, that you need to suffer to have things your way, and that Apple is magnanimous to even let you have them.

>> This was costing us ~$300K/year in compute, and the number kept growing as more customers and detection rules were added.

> For something so core to the business, I'm baffled that they let it get to the point where it was costing $300K per year.

And this, this is the core/true/insightful story the executives will never hear about.

Probably the one elephant in the roomy thing that matters: failing to say they don't know/can't answer

it seems indeed better in some ways, but the scoring is still way off,

for example, for my second criteria:

> - works on partial matches (e.g. inputting "ma in" matches ("make install", "cd main")

typing "ma in" I would expect "make install" to come before "cd main" to come before (what's currently the very first hit) "cd Binaries/Multimedia".

I'm now reading about https://docs.atuin.sh/cli/configuration/config/?h=fuzzy+daem... while not managing to really get what would seem natural. Sigh.

I never found a satisfying search algotithm with atuin (iterating over time between fuzzy, skim, fulltext, and maybe others). Is there one that is both:

- case insensitive (e.g. inputting "make" matches ("make install", "vim Makefile")

- works on partial matches (e.g. inputting "ma in" matches ("make install", "cd main")

?

Wouldn't a solution be to have the opening on the side and pull it toward you, like a "box on wheels"? As long as the sides of the "box" are thermally insulated, it seems like a sound solution for the stated problem (but certainly not one that's mechanically the cheapest/simplest).