That’s not true for Postgres however: due to its usage of a shared memory pool, whenever a subprocess is terminated unexpectedly, Postgres will kill all other processes and enter recovery mode, replaying the WAL, during which time it will not accept connection requests.
It does this because it can’t possibly know whether the dying process did bad things to the shared memory pool.
A migration like this is a monumental undertaking to the level of where the only sensible way to do a migration like this is probably to not do it. I fully expect even worse reliability over the next few years before it'll get better.
it's also very tricky to do given the current architecture on the server side where one single-threaded process handles the connection and uses (for all intents and purposes) sync io.
In such a scenario, listening (and acting) on cancellation requests on the same connection becomes very hard, so fixing this goes way beyond "just".
Firefox is not in a position where it is the only browser allowed to run on a platform.
On iOS, you’re either doing a native app, sharing 30% of your income with Apple, or you’re restricted to Safari’s feature set. No browser in iOS can use anything but WebKit
I wouldn’t post some random vulnerability report, but the disclosure timeline at the end was very interesting to me and not putting the vendor in a great light
what's especially strange to me is that in the more distant past, he was a pretty normal guy - at least as normal as any other linux user. Heck, he had a super great podcast (Linux Action Show).
Something changed in the 2014ish time-frame when it got more and more politically extreme.
> As for the fact that one cannot resize from inside the window,
if you check the screencast I posted, you'll see that you can indeed resize from inside the window. Not by a huge margin, but definitely from inside the actual window boundaries.
It wasn't meant as a rebuttal. Just as a point of thought: By showing that at least one application doesn't exhibit the problem, I thought I was showing that the problem might not be related to the Tahoe redesign at all but might have other causes.
It definitely serves to prove that this is not a design-issue but just a simple bug and thus has at least some chance of being fixed.
FWIW, I cannot reproduce the issue demonstrated in the original article with any window of any application on my machine (M1 Mac Studio), but I thought that listing a very commonly used application alone would be enough to challenge the article's assertion ("the macOS designers are stupid because they make me do something that doesn't make sense in order to resize windows").
As much as I like to hate on a new OS like the next person, I think it's worth pointing out we're probably not seeing the full picture here:
When trying to reproduce the problem as shown in the article by resizing the Safari window currently displaying the article, the drag cursor changes shape at the visible border of the window, not the shadow and consequently, dragging works as expected.
One thing that’s not quite clear to me is how safe it is to generate v7 uuids on the client.
That’s one of the nice properties of v4 uuids: you can make up a primary key of a new entity directly on the client and the database can use it directly. Sure: there is tiny collision risk, but it’s so small, you can get away with mostly ignoring it
With v7 however, such a large chunk of the uuid is based on the time, so I’m not sure whether it’s still safe to ignore collisions in any application, especially when you consider client’s clocks to probably be very inaccurate.
I understand this as an argument that it’s better to be down for everyone than have a minority of users switch browsers.
I’m not convinced by that makes sense.
Now ideally you would have the resources to serve all users and all the AI bots without performance degradation, but for some projects that’s not feasible.
[ my public key: https://keybase.io/pilif; my proof: https://keybase.io/pilif/sigs/yHf-RJm7d2dmr7kcjUe4g3m9d2dB0u2Nsu8kpLFFBtQ ]