Hey miller_joe! I actually just built this - Claude Vault! (Free)
Same philosophy as ChatKeeper - local-first markdown files that sync and work great with Obsidian. I had the exact same problem with my Claude conversations buried in JSON exports.
Just published to PyPI:
pip install claude-vault
claude-vault init
claude-vault sync conversations.json
----
Auto-generates tags using local Ollama (completely offline, no API costs) and detects relationships between conversations
Would love to collaborate or integrate with ChatKeeper down the line - seems like we're solving the same problem for different LLMs!
Yep, you're not the only one, and I want to add support for more formats/LLMs. Right now ChatKeeper's internals are very ChatGPT-specific, but I have a plan to change that and Claude (which I also use frequently) will be the first one I add support for.
I was hoping google cloud artifact registry pull-thru caching would help. Alas, it does not.
I can see an image tag available in the cache in my project on cloud.google.com, but after attempting to pull from the cache (and failing) the image is deleted from GAR :(
> "When a pull is attempted with a tag, the Registry checks the remote to ensure if it has the latest version of the requested content. Otherwise, it fetches and caches the latest content."
So if the authentication service is down, it might also affect the caching service.
In our ci setting up the docker buildx driver to use the artifact registry pull through cache involves (apparently) an auth transaction to dockerhub which fails out
Instances are constantly booting up because most instances live <30d. Boot time in terms of how soon a node is fully booted and joined to the EKS apiserver and ready for workloads is approx 2.5-3min. There are lot of parts involved in getting to this point though, some of which would not matter if you're not using EKS. Also this is not something we measure super closely as from a user perspective it is generally imperceptible.
A possibly better metric for your particular case (assuming you're interested in fastest bootup possibly achievable) is from our self-managed github-actions runners. Those boot times are in the 40-50s range. This is consistent with what others see, as far as I know. A good blog on this topic - including how they got boot-to-ready times down to 5s - that you might be interested in from the depot.dev folks: https://depot.dev/blog/github-actions-breaking-five-second-b...
I'm already at the ~5s mark, booting a brand new instance, almost all of which is AWS time before my instance gets control; once the kernel takes over the remaining boot time is milliseconds. (I plan to go the "pool of instances" route in the future to eliminate the AWS time I have no control over.)
But ever so often, I observe instances taking several more seconds of that uncontrollable AWS time, and I wondered what statistics you might have on that.
Possibly relatedly, do you ever observe EBS being degraded at initial boot?
I wasn't sure how to load the images back into docker at first. I tried `docker load` but I get this error:
$ (cd ci-repack && tar cfv - .) | docker load
./
./oci-layout
./index.json
./blobs/
./blobs/sha256/
./blobs/sha256/2ad6ec1b7ff57802445459ed00e36c2d8e556c5b3cad7f32512c9146909b8ef8
./blobs/sha256/9f3908db1ae67d2622a0e2052a0364ed1a3927c4cebf7e3cc521ba8fe7ca66f1
open /var/lib/docker/tmp/docker-import-1084022012/blobs/json: no such file or directory
Then I noticed the `skopeo copy` in one of the github actions workflows. That got me further. The image was able to be pushed to a registry. But I am getting this error when pulling the repacked image:
failed to register layer: duplicates of file paths not supported
This is great! I’ve been using ipv6 on openbsd for a while now, starting with a hurricane electric tunnel years ago then to native v6 on Comcast and now Sonic. Configuring ipv6 PD has not been supported in base this whole time. I recall using wide-dhcp6c years ago and then switching to the dhcpcd in the article. The situation has improved, slowly, but it will be great to have this in the base system
They turned on native IPv6 end of last year, at least in some areas (including Berkeley where I live). You wouldn't know it from their help pages, but there are some post in the forum to that effect.
Vector is fantastic software. Currently running a multi-GB/s log pipeline with it. Vector agents as DaemonSets collecting pod and journald logs then forwarding w/ vector's protobuf protocol to a central vector aggregator Deployment with various sinks - s3, gcs/bigquery, loki, prom.
The documentation is great but it can be hard to find examples of common patterns, although it's getting better with time and a growing audience.
My pro-tip has been to prefix your searches with "vector dev <query>" for best results on google. I think "vector" is/was just too generic.
I’ve been using this for a few weeks. I converted to a paying customer. I’ve imported some but not yet all of my bookmarks.
I’ve been collecting bookmarks in Evernote and now obsidian for about a decade. I try to add as many tags as I hope will allow me to find an article again later. It’s often many months before I need to find something. My success rate at remembering a term from the title or the right tag is not great. I’ve been pretty impressed with zenfetch’s ability to search and find exactly what I was looking for. And this doesn’t even scratch the surface of what it can do when you want it to synthesize answers from many articles for you.
They’re also working on indexing your saved tweets which I’m excited about. It’s a giant pain to try to find liked tweets.
I just happen to be reading Peter F. Hamilton's Confederation universe (1996–2000) trilogy and in it earth has been dealing with the "Armada storms" for a couple hundred years due to climate change. From the descriptions there are multiple of these storms occurring at any given time. Humans now live in "arcologies" which are giant multi-kilometer domes over population centers. There was no way to reverse the damage done. We can't fly anymore so everything is in a very fast underground train system called "vac-trains". I suppose this may be where we are headed (although I'd rather love to see the vac-train system)
