I think the reason I started doing it on the iPad is that the keyboard focus is sometimes inconsistent, so clicking or tab-tab-tab-enter is slower and less reliable vs. just touching the screen. Definitely feel the gorilla arm though.

I regularly back up my Photos library using rsync to prepare for the worst. From the files I see it looks like all the originals are there under /originals, albeit renamed to some UUID hash. However the EXIF data and contents seem to be intact. The number of files and their names are also stable. The database seems to be a basic sqlite DB.

I think it might make sense to extract the files directly that way, and try to see how the DB stores the original filenames. Might not be too hard. The edits though I think are applied "live" (at least for video) so it's probably impossible to get them out this way.

That one also wasn't a hardware limitation as it ran my displays just fine in bootcamp, but macOS would just produce fuzzy output all the way.

It's infuriating.

In TFA it's set to a measly 2MiB, yet tried to allocate 2TiB. Note that the PG default is double that, at 4MiB.

What the setting does is offload the responsibility of a "working" implementation onto you (or the DBA). If it were just using the 4MiB default as a hardcoded value, one could argue it's a bug and bikeshed forever on what a "good" value is. As there is no safe or good value, the approach would need to be reevaluated.

The core issue is that there is no overall memory management strategy in Postgres, just the implementation.

Which is fine for an initial version, just add a few settings for all the constants in the code and boom you have some knobs to turn. Unfortunately you can't set them correctly, it might still try to use an unbounded amount of memory.

While the documentation is very transparent about this, just from reading it you know they know it's a bad design or at least an unsolved design issue. It just describes the implementation accurately, yet offers nothing further in terms of actual useful guidance on what the value should be.

This is not a criticism of the docs btw, I love the technically accurate docs in Postgres. But it's not the only setting in Postgres which is basically just an exposed internal knob. Which I totally get as a software engineer.

However from a product point of view, internal knobs are rarely all that useful. At this point of maturity, Postgres should probably aim to do a bit better on this front.

Doesn't help that most tuners are still dog slow, none of the beginners courses properly tell you how the guitar actually works, or what a "chord" really is. They're all just "play this and don't worry about it". To be fair it does get you going.

I noticed the "memory" too and it's turned Gemini into a useless syncophant for me, but so subtle that I almost didn't spot it.

I loved those courses, great memories.

I see plenty of tourists with winter gear that is either insufficient, or completely over the top. Whereas if you buy locally you'd generally find the right stuff.

1. Do what everyone else does, when they do it. And don't, when they don't. You could die.

There is usually a reason even if you don't understand it right now. You don't want to find out why when you're out in the cold and freezing.

2. Buy gear locally.

There's sometimes reason a certain item is on the shelf and not the stylish one from California, or the super heavy-duty one from Norway. Unfortunately, often this is only obvious in hindsight. Does not depend on price, but it does apply across the board from clothing to cars.

Literally every slow Postgres statement I worked on in the last few years was due to lack of accurate statistics, missing indexes, or just badly designed queries. Every one was fixable at the source, by actually fixing the core issue.

This was in stark contrast to the myriads of Oracle queries I also debugged. The larger older ones had accumulated a "crust" of plan hints over the years. Most not so well thought out and not valid anymore. In fact, often just removing all hints made the query faster rather than slower on newer Oracle versions.

It's so tempting to just want to add a plan hint to "fix" the suboptimal query plan. However, the Postgres query planner often has an actual reason for why it does what it does and overall I've found the decisions to be very consistent.

I wish I'd gone more into theoretical computer science, quantum computing, cryptography, and in general just hard math and proofs.

I took a few such courses and some things have genuinely been useful to know about at work but were also mind-expanding new concepts. I would never ever have picked up those on the job.

Not to say the practical stuff hasn't been useful too (it has) but I feel confident I could pick up a new language easily anytime. Not so sure about formal proofs.

Those summaries always existed, in the past you could buy them as little books for most of the classic literature we read. Thing is they were always the same trite points even back then.

Our teacher would see right through any BS, but never call it out directly. Instead there would be 1 precise and nicely asked follow-on question or even just asking their opinion on a talking point. Not details, but a regular discussion question.

If someone hadn't read the book they'd stutter and grasp at straws at that point and everyone knew they hadn't actually read it.

On the other hand if you had read the book the answer was usually pretty easy, and often not what the common summaries contained as talking points.

So cheating not only didn't work, the few regular cheaters we had in our class (everybody knew who those were) actually suffered badly.

Only in hindsight did I realize that this is not the normal experience. Most other literature classes in fact do just focus on or repeat the same trite points, is what I've heard from many others.

It takes a great teacher to make cheating not "work" while making the class easy, intellectually stimulating and refreshing at the same time.

has never worked consistently. For literally 10+ years now, I've always had a few emails per day go into spam even though that rule is in place.

And the ones doing it have no say in how it's done.

Being involved and in the loop is how great software is made. Otherwise you can just outsource and have tickets completed.

It's deliberate, I'm sure. People say they want the vegetables, but then go on to watch hours of fast food / Shorts. Clearly the algorithm knows.