HN user

zerovox

588 karma
Posts9
Comments85
View on HN

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.

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.

Preact Signals 4 years ago

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.

Interesting to contrast this to what OS X(certainly Mavericks, maybe others) does. If you restart and opt to re-open previously open windows, they will open with screenshots of their previous states - only when you click on one will it dim the window and admit to you that it's not loaded yet. Personally, I find this a little irritating, giving the illusion that it's ready when it isn't. I find facebooks approach a little better, it doesn't pretend to be usable, but guides your eyes to the right part of the screen.

Ah, this is me being misleading, I didn't mean the styling of the document was important(well, until it gets sent to publication, where I am sure you're right about the interns), I really meant the ability and tools to edit/review/track changes and highlight/annotate sections they want changed.

I wouldn't be surprised if a lot of writers were less technically savvy, happiest writing in Word, or simply wouldn't know how to write in any other format. It makes sense from the publishers point of view to pick one format and stick with it, so they have a consistent editing style and ability, and only have to deal with converting one format into a final publication.

I do feel that this is one of those cases where you should be able to write in the way you feel best for you, and if the publisher insist on having the final document in a word format, it should be straightforward to convert your chosen representation to theirs. It's hard to say without knowing precisely how the publisher expects the file to be formatted, but if it's fairly straightforward, there are libraries that will write to doc files for you, or there are open formats that MS Word already knows how to convert into .doc files that you could target instead.

This doesn't seem wildly unreasonable to me. If it allows them to perform a better review and check for malicious code before approving it, I'm all for it.

Perhaps Opera can perform the minification after reviewing the code and achieve the performance gains while still being able to prevent malicious code entering the store.

They've had this planned out for a long time now. Thunderbird received this UI refresh in August last year(the change log said it was to "match the new Firefox UI"), so I wonder why they delayed adding this to FF for so long.

Personally, I much prefer the current UI. It's very concise, no space wasted with curves, perfect for people like me who tend to have 10 tabs open at once. I would rather they update the current style with a few of the nice hover effects and bolder colours, rather than change the shape of tabs and the menu location.

I've tried a dozen different note taking tools, the only one I've stuck with is Workflowy[1]. I think it just suited my style of note taking/todo list making/hierarchical lifestyle right from the start. I would like to see better Android app support(3rd Part/Web only atm), but apart from that it's perfect for me.

[1] https://workflowy.com/

> Wanting to store everything in iCloud is his usecase, and I doubt it's a popular one. Personally, I'd rather keep my library on an external Thunderbolt RAID array for speed and duplicated on an off-site backup.

I think his use-case is a lot more common than yours! 99%+ of consumers don't have an external Thunderbolt RAID array, or even know what it is. They just want their photos all in one place, accessible from everywhere, in the same way you can have your music on all devices with iTunes match.