0x6c6f6c

Time can be an issue connecting to Wi-Fi. Devices who've lost track of time often can't properly negotiate access to then get NTP updates to their time. Perhaps this could be solved, but it's a common problem for devices left for the batteries to go dry.

It is a bit sensationalist to say this is reviving it though, which makes this sound like some wild issue.

It is default behavior based on implicit environment setup. But I think the title could use updating because it is misleading without that.

Perhaps "creates CLAUDE.md for claude-code users by default" instead.

What are you using for OCR locally? This is something I've been considering trying for some time with old journals.

Comparing self-hosted immich and a truly E2EE hosted platform like Ente is really odd. There are massively different trade-offs and target customers between these.

Ente is a private hosted photo storage and sharing platform. Only trusted devices that can decrypt /encrypt would even be able to perform the kind of work to tag photos for face recognition, and in this category I'm not aware of any hosted alyermative that actually does this, and they do a _pretty good job_ considering the limitations of E2EE.

Immich, Google Photos, Apple Photos- these platforms don't have to work around the fact all user data is opaque ciphertext. I imagine you could extend the capabilities of machine learning to a trusted node (similar to what you can do with Ente Desktop, but with more capable models), but they still have to work around any of that metadata being visible to them as well.

This takes somewhat trivial problems and makes them entirely non-trivial to solve. Self hosted platforms that don't provide an E2EE story have significantly less headache to deal with, especially since most people justify it by "it's running on my server so it's okay". And I get that, you can generally work around this issue with disk-level encryption and you're all good. It's just not the same product at all.

That's a somewhat reaching use of the word "natively".

It's being run through the equivalent of a virtual machine. So it's really quite similar to the layers used to abstract away platform specifics like Wine / Proton does for Windows compatibility. Instead of DXVK you have WebGL.

There is no comparison when running a TypeScript project with Bun vs with Node. Or when mixing ESM and CJS. Or when setting up unit testing.

Node and its ecosystem was considerably behind in multiple regards.

Bun does zero work in relation to TypeScript's type system. Since it's a strict superset, it is "simply" stripping types to execute the resulting JavaScript. That is effectively what it boils down to.

TypeScript is the most complex type system in existence. I am unsurprised it is difficult to port, but I am still a bit surprised by the length of the project thus far.

Microtransactions. In a non-joking sense. People pay for outfits or gear to wear to the rave. Or they can work for it in game. Maybe a bit like EVE Online where you can pay monthly to play but if you make enough in-game you can buy a months subscription.

Honestly Claude straight up ignores my input sometimes, preferring to instead run commands for output and processing that and burning through a series of tokens when thinking hard about whether to ignore me.

Like today, I told Claude exactly the name of the folder it had mistaken (it was supposed to be prod, not production), and it disregarded my input to then examine the directory itself. Small example of the kind of things it's been doing lately but that's top of mind.

And if you were a smaller team then you don't even need K8s. Just ECS or Cloud Run have simple abstractions for horizontally scalable services and sidecars support.

I like TEA but don't fully grasp how it scales for apps that may have reusable components or sufficiently complex pages. Is there an agreed-upon way(s) to deal with this? I know state is a big NO so it seems a bit at odds, but also does this essentially mean all Elm apps are just a global Redux and React app with no effects? Curious about more details to what you enjoy and how you like to work in Elm. Links also perfectly fine too.

What are some of the alternatives that are worthwhile for this?

Many people do use GitHub for this. There are even Android app stores hinged around searching and installing release APKs.

The social connectivity and discoverability in github is a big reason many people use it. Can't say how many, but it is.

This is likely one of the many pains of App Store subscription configuration issues. Once anyone has subscribed you will have to migrate those yourself and even those details I'm not sure what restrictions there are. The latest seems to be one-time purchase, but historical cleanup is probably necessary on their part

Agreed, but this isn't always bad. Optimizing early with unclear requirements can kill time, which at an early stage is just delaying product launch.

Migrate/optimize later when you're actually reaching scale is a perfectly reasonable approach.

In fact, if you have a decent abstraction or standard in place (e.g. S3 API or repository pattern) you can swap it out in place.

I absolutely have used AI to scaffold reproduction scenarios, but I'm still validating everything is actually reproducing the bug I ran into before submitting.

It's 90% AI, but that 90% was almost entirely boilerplate and would have taken me a good chunk of time to do for little gain other than the fact I did it.

I have usually explained to my teams that you only should be doing this at the boundaries of the system. User input, raw files, request bodies, etc. are places where you would _need_ to determine an actual type for an otherwise unknown value.

Even then, a solid validation/parsing library like Zod is a better choice than casting, it is much less error prone at ensuring you have the right type applied.

Beyond that boundary, casting with `as unknown` is a massive code smell and often introduces any further use of that data to invalid type errors. I'll refer to this as "force casting", because simply casting "x as T" with sufficient strictness configured will still fail type checking if x is not compatible with T, and that can be fine for certain cases like reducing a complex type or giving an inferred parser type a form that fits your domain types.

Developers that force cast too readily can end up creating hundreds or even thousands of type errors in the codebase over time, and they are pretty quickly revealed once you peel away the casting. The same is true when starting from an `any`, where every reference thereon is equivalent to a force cast.

There can be some complex typing scenarios that do require it, but even then a good type guard works better even if certain cases can be semantically equivalent, you can write tests around guards as they're just functions, ensuring some logical correctness to the typing.

The simplest but maybe odd way to judge whether a casting is used the wrong way is to ask "are you lying to the type system?". If so, how can you better portray that type correctly (validation that determines a correct type for you (e g. Zod) or type guards).

It definitely would be interesting to have proposed alternatives and even examples included as part of this piece.

As far as I can tell, people who are paying for support contracts were also impacted by this. It was explicitly called out in that thread

Their example in the README is extremely misleading then. It indicates your stream output is

name: A name: Al name: Ale name: Alex

Which would suggest you are getting unfinished strings out in the stream.

Based on this thread that's called NDJSON

Newline Delimited JSON

TIL

This approach couples together everything though, in such a way there's no standard manner of wiping cache but not your app, configuration, etc.

XDG may not be perfect but wiping related data for apps following it is straightforward. There are a few directories to delete instead of 1, but still consistently structured at least.

Same boat, but vs amethyst. It's worked very well for me the last few years.

Since no one responded, they're running on Kubernetes, where a unit of containers is called a "pod". A pod may be one or more containers, but it's the smallest deployable unit in the Kubernetes space.

Their docker images were 11-35GB. Using the nix dockerTools approach would have resulted 100-300MB layers. These also may not even cache well between tags, though that's my intuition not knowledge. Especially if that's true, it wouldn't have improved the overall pull time issues they were having, which was 70-210s or image pull time on many new builds.

In their case they added a sidecar container which was actually an init container, which runs before the primary container of the pod runs. They did utilize root privileges to perform things like bind mounting of nix store paths into the running container which made it possible for the container to run software provided in the /nix/store available from those bind mounts. This also meant both the Kubernetes hosts and containers did not require the nix daemon, the nix-sidecar running within the pod orchestrated pulling derivations , binding them, and running garbage collection at low priority in the background to ensure host SSDs don't run out of storage, while still allowing referenced derivations in the cluster to persist, improving sync time where the SSD may already contain all necessary derivations for a new pod startup.

By tracking changes made by a command, like you might with git.

SSH over QUIC

so, maybe SSHoQ or SoQ

soq reads better for the CLI I suppose.

Except those are not even close to the same type of software to fairly compare. A file manager has virtually no inherent servicing costs to pay compared to a podcast player.

It's fluff to give the elevator pitch now guys, be warned

If your data is already in Drive haven't you already given them it?

It could do better for sure, but it's a just a Get Started guide, I never consider that a Production Ready guide.