pilif

Two explorer windows are independent of each other. Any move or copy requires two keyboard actions or the use of the mouse

3 years later, Apple releases the OS 27 versions and Siri got improved to the point where it can’t work on-device any more on said Ultra 2

So to get the feature back which I paid for and which was specifically used to sell me the device and which now has been taken away from me, I just have to… buy the next hardware generation?

And how long will that last before they decide to remove the feature again?

Thankfully, the Ultra 4 provides some other compelling features making this less painful, but I would have expected at least a toggle to keep old Siri on the old watch. New Siri over the network is impossibly slow and buggy (I made the mistake of installing the betas, so there’s no way back now)

And yet, apparently it was.

It's not perfect, but the dots help me to go from instantly feeling sick to lasting 30-40 minutes before I have to stop looking at the screen.

It does this because it can’t possibly know whether the dying process did bad things to the shared memory pool.

https://oldbytes.space/@mrrmot/116694151801834138

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.

In such a scenario, listening (and acting) on cancellation requests on the same connection becomes very hard, so fixing this goes way beyond "just".

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

Something changed in the 2014ish time-frame when it got more and more politically extreme.

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

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.

https://youtu.be/kNovjjvYP8g

This might be an application- or driver specific issue, not necessarily a common Tahoe issue.

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.

Am I overthinking things here?

yes and given that the energy you put in is practically free, it doesn't matter if it's not as efficient.

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.

In the end it’s all a compromise.

https://dukespace.lib.duke.edu/server/api/core/bitstreams/81...

And of all the high-profile projects implementing it, like the LKML archives, none have backed down yet, so I’m assuming the initial improvement in numbers must continue or it would have been removed since

Yes. Obviously dumb but also nearly 100% successful at the current point in time.

And likely going to stay successful as the non-protected internet still provides enough information to dumb crawlers that it’s not financially worth it to even vibe-code a workaround.

Or in other words: Anubis may be dumb, but the average crawler that completely exhausting some sites resources is even dumber.

And so it all works out.

And so the question remains: how dumb was it exactly, when it works so well and continues to work so well?