zerovox

I understand that they couldn't use the Escape key, and so having an alternative makes sense, but I'm not sure as a user how I would ever discover the behavior of pressing "shift" three times.

This will be used as a pretense to raise airline fares, and won't impact cancellation rates or average delay times.

It's incredibly painful to do this with a large library, as they've stopped supporting the desktop uploader. It's all drag-and-drop uploads, so it's not easy to keep it in sync with a folder of music.

Also the playback experience is painful and uploaded files are poorly supported across devices like Google Home, where it constantly wants to do playlists or mix in other music. I'm not sure Google Home even supported playback of uploads, though I abandoned the service shortly after the Play apps went away.

I used to use iTunes Match. It'll change more than just metadata, I've had instances where album tracks were swapped out for their clean versions. I've dropped it in favor of a self hosted version I can ensure won't muck with my music.

Another Navidrome user here, hosted on a $5 Linode Nano. I have rclone set up to mount an S3 bucket with the music files. Scanning them is a bit slow, but otherwise I've had no issues.

I highly recommend Symphonium as an Android client. It is receiving constant updates, highly polished, has an offline mode, Android Auto support, and so much more.

The title is misleading. This article argues that you should not use a UUID for a _session cookie or access token_, which was never the intended purpose of a UUID.

I had a similar response when reading "React adapter allows you to access signals directly inside your components and will automatically subscribe to them."

I don't believe this is worth it. The implementation is fairly dangerous and fragile as you point out, all in order to simplify something fairly clean/reacty such as `const value = useSignalValue(signal)` into `signal.value`.

> We also require every access to any stack variable to do math to figure out where on the stack it's arguments are.

In the article, it appears to be the opposite. Previously this math was required (`[ai] = 2 + parameter_count - i - 1`), but by reversing the arguments in the stack it's now always a constant offset, and they prevent indexing out of the passed arguments in the frame by ensuring there's at least as many arguments as formal parameters by stuffing the call with extra `undefined`s:

> But what happens if we reverse the arguments? Now the offset can be simply calculated as [ai] = 2 + i. We don’t need to know how many arguments are in the stack, but if we can guarantee that we'll always have at least the parameter count of arguments in the stack, then we can always use this scheme to calculate the offset.

I do. I simply don't have any reason to doubt that he's being truthful when he says he read a certain book. Given that he clearly enjoys reading, I find it hard to believe that he has any reason to be dishonest in listing his favorite books.

Unless I'm missing some of the problems you're trying to solve, this seems like an extremely over engineered solution to the problem of code duplication (like validation) and boiler-plate communication code. For the former, if you're using a node backend, you can pretty trivially reuse the same code between client and server side. The later doesn't really seem like a big enough issue on its own to really warrant an architecture that requires a back-end with per-tab mirroring - you can usually encapsulate the 'cumbersome AJAX calls' with a straight forward API (or GraphQL query if that floats your boat).

This approach also forgoes many of the nice side-effects of having a clear slide-server boundary like avoiding leaking implementation details into your front-end code. Also, a simple REST API can be reused across platforms, so when you want a native experience on Android, iOS, etc you wont have to replicate this architecture or the underlying logic on each of those platforms.