yooogurt

if you want to back this file up regularly with something like restic, then you will quickly end up in a world of pain: since new mails are not even appended to the end of the file, each cycle of takeout-then-backup essentially produces a new giant file.

As I'm sure the author is aware, Restic will do hash-based chunking so that similar files can be efficiently be backed up.

How similar are two successive Takeout mboxes?

If the order of messages within an mbox is stable, and new emails are inserted somewhere, the delta update might be tiny.

Even if the order of the mbox's messages are ~random, Restic's delta updates will forego large attachments.

It would be great to see empirical figures here: how large is the incremental backup after after a month's emails. How does that compare for each backup strategy?

The pro of sticking with restic is simplicity, and also avoiding the risk of your tool managing to screw up the data.

This risk isn't so bad if it's a mature tool that canonicalises mboxes (e.g. order them by time), but seems risky for something handrolled.

companies that can afford inflated prices will take advantage of the situation to pull ahead of competitors who can't afford tech at inflated tech

These big companies are competing with each other, and they're willing and able to spend much more for compute/RAM than we are.

I don’t know what we can do as normal people other than making do with the hardware we have and boycotting Big Tech, though I don’t know how effective the latter is.

A few ideas:

* Use/develop/optimise local tooling

* Pool resources with friends/communities towards shared compute.

I hope prices drop sooner than projects dev tools all move to the cloud.

It's not all bad news: as tooling/builds move to the cloud, they'll become available to those that have thus far been unable or unwilling to afford a fast computer to be mostly idle.

This is a loss of autonomy for those who were able to afford such machines though.

If you haven't heard of Rich Hickey, then you're fortunate to have the opportunity to watch "Simple Made Easy" for the first time: https://m.youtube.com/watch?v=LKtk3HCgTa8

I have seen similar critiques applied against digital tech in general.

Don't get me wrong, I continue to use plain Emacs to do dev, but this critique feels a bit rich...

Technological change changes lots of things.

The verdict is still out on LLMs, much as it was out for so much of today's technology during its infancy.

Isn't this more easily explained by supply-demand? Supply can't quickly scale, and so with increased demand there will be increased prices.

Alternatively, we'll see a drop in deployment diversity, with more and more functionality shifted to centralised providers that have economies of scale and the resources to optimise.

E.g. IDEs could continue to demand lots of CPU/RAM, and cloud providers are able to deliver that cheaper than a mostly idle desktop.

If that happens, more and more of its functionality will come to rely on having low datacenter latencies, making use on desktops less viable.

Who will realistically be optimising build times for usecases that don't have sub-ms access to build caches, and when those build caches are available, what will stop the median program from having even larger dependency graphs.