I wish the author provided some latency numbers for this. One issue with tpms is that they are slow relative to performing the same operation on a modern CPU.
Thats the “what it costs” section? Im a bit impressed if they are down to ~3ms per handshake. When I last looked at TPM signing (many years ago) it was more like single digit transactions per second.
That said, even 3ms TPM signatures are going to be for special cases or novelty. Plain old CPU tls will do about 1ms cpu time per request which will scale by cpu core count. One or two orders of magnitude more throughput per host.
There are a bunch of these tools out there. I like curl-impersonate[0] as a quick way to make curl fingerprint as chrome or firefox. There's also CylceTLS[1] for a more programmatic approach.
Often I set up a bunch of automation for a particular service, and then they "upgrade" their security to enforce fingerprint checking, and adding in a proxy is just a config change to my existing tooling.
I got rid of my Alexa devices after they would not shut up. "Alexa what is the weather for today?" "The weather for today will be ... By the way, did you know that you can set alarms? Just say ..."
I do not care about whatever stupid feature you want to build engagement around. Do what I asked you to do and then shut up.
And don't get me started on the Alexa Show that had the audacity to display ads.
I wrote a library[0] to let you concurrently update a sqlite db in s3 safely. It uses the little known sqlite sessions extension plus s3 compare-and-swap on a small metadata file to make this work reasonably efficiently and safely. I have been enjoying it for a bunch of small projects where I want a lambda function to have a db for state but I don't want to pay for a full database instance.
This is exactly what I had dreamed of except without being aware of the session extension... I put it off because I thought I would have to create a layer opening sequential partial sqlite dbs and somehow filtering to the most recent version of each record in-between compactions.
It sounds like sqlite sessions handles the hardest part and you've sanded down some of the rough edges while implementing the glue bits for s3 (generously licensed MIT); thanks for the heads-up!
> If you're using AWS Lambda then you have to work to keep convincing yourself this is better than your own web servers. Keep convincing yourself that using AWS Lambda is not a horrible mistake.
lol ok. I have ~50 lambdas running in my personal aws account. Some of them are webservers running behind an api gateway or using a lambda function url to expose them to the internet. Some are running on a schedule, some are triggered from s3 events. The cost to run these for me is less than the cost of the cheapest vps (my total requests per month stay under the free tier limit). There is also zero maintenance I need to do for these functions (ok, this year I did have to find-replace al2 to al.2023 in my terraform config). I don't have to worry about making sure the os is patched for the latest vulnerabilities. And I don't have to worry about the specific hardware my code is running on at any time. Doing maintenance for old projects sucks. It is great to have servers I deployed years ago continue to chug along without me needing to think about it.
Now, all of my lambdas are written in Go and I suspect if I was using one of the manged runtime libraries I would find the language upgrades to be quite annoying. Go also helps quite a lot with cold start times.
Then again maybe I have just drank the koolaid. In my quest to use lambdas for as much as I can as cheaply as I can, I made a library[0] to use sqlite on top of s3 (not just readonly). It uses the sqlite session extension plus s3 compare-and-swap to allow you to write updates safely to s3, even if you have concurrent writers.
> The cost to run these for me is less than the cost of the cheapest vps (my total requests per month stay under the free tier limit).
I don't think this is a valid argument. Free-tier VPS do exist also.
On the other hand, if you don't trust unattended-upgrades [0], and prefer to spend time poking package manager manually (while at the same time considering that time an expense) - sure, that's a strong argument in favour of using lambda.
As you yourself said. Your load is so light you keep it in free tier. Their entire business model is for them to capture you while your load is light and then when you scale the price goes up.
I have also used lambda at scale in professional environments. I would not use a lambda for a webserver at scale, but having an s3 object trigger processing via a lambda function is a really nice flow.
This "it has to be handwritten" stuff is nonsense. Do that if you enjoy it, but also you should acknowledge the downsides to it.
I started keeping a work journal a few years ago and it has changed how I work for the better. It is just a text file.
The main value of it is that I can search it! When I'm figuring something out for the first time, and I have a lot of trail and error, I write down what I did. And then I might not touch that thing again for 6 months. When I come back to it, it is unlikely that I will remember what I did exactly but because it is written down and searchable I can quickly recover my old state.
I like this so much I also started a personal work journal for my home lab. It really is useful for me. But its primary value is that I can search it.
> This "it has to be handwritten" stuff is nonsense. Do that if you enjoy it, but also you should acknowledge the downsides to it.
From the submission:
"Should you use one?
Maybe! I can't answer that for you. "
There is a middle ground. Write on paper on the spot. Transcribe to digital form later. I've been doing it for many years. Painful, but now I just get an LLM to OCR my handwriting.
And oh, definitely - for me the brain works differently while typing vs handwriting.
I find there's an advantage to writing if I'm trying to memorize something. But if that isn't going to happen because I only did this configuration once and then never needed to reference it again for two years and now I need the exact commands I executed, can't beat a searchable txt file.
Writing things by hand leads to better retention, but if you can't remember it...yeah you'll have a fun time finding it again if you have a nontrivial amount of notes and haven't spent a significant amount of time indexing them.
Yeah I was talking about Google Vision or similar. Though USPS has been doing handwriting recognition since the 80's. I don't it got very good until the late 90's though.
I stopped using my Remarkable because I couldn’t read my own writing on it. I have have no problem reading my writing when I write in a physical paper notebook (well, fewer problems). But the resolution either for capture or display on the remarkable makes my somewhat messy writing impossible to read.
So, it’s not only if you can’t remember it… you also have to be able to read it!
For me the advantage of using digital journalling is it's easier to switch between multiple threads. It means if I have 3 tasks to complete, I can switch tabs to the notes on the new task without thinking about the physical limitations of a notebook.
I handwrite notes because it commits it to memory and I don't have to search it later (most of the time). Important stuff goes in electronic notes, but 90% of things aren't that important.
Most of what I write in my journal I don't want to need to remember (that is why I am writing it down). I also don't know what will be important or not important later, so I want it all to be searchable.
It's not nonsense. At least it hasn't been for me. My memory retention shoots into the stratosphere when I write stuff (that I need to remember) down. Something about it being slower and actual effort needing to be expended to commit the information.
Handwriting is my primary notetaking route, but in situations where it isn't (typing is faster after all), I'll scribe what I typed into my reMarkable later. If the note I created was for work and I wrote a note by hand first, I'll type it into a Google Doc later and upload both versions (since they might differ slightly). I learned this as a study hack while I was in school 15+ years ago and it still works flawlessly for retention.
Handwriting everything has held me back sometimes, though. Ironically, insisting on handwriting everything is the reason why I didn't keep a daily journal for a long time. I started journaling in 2012 and stopped as work and life got busier. I picked it back up in 2021 with a mood tracking app to, well, track my mood and reactions to emotions and fairly quickly regretted not having just typed my journal entries.
it sounds like the author is using an e-ink device for note-taking. i use an ipad app for a lot of hand-written notes and i'm consistently surprised at how well it can search my chicken-scratch.
my biggest issue with handwriting is it just takes so long that i end up leaving out important details. it's a shame because i do enjoy it.
Playing around with this for a small amount of time, it is very neat but also there are a bunch of things that are unclear / undocumented (I assume the documentation is coming so I'm not faulting them for it not being there yet).
Some things that are unclear:
- How should I auth to github? sprite console doesn't use ssh (afaik) so I guess not agent forwarding?
- What on machine api's are available? Can I use the fly oidc provider[1]? There's a /.sprite/api.sock but curl'ing /v1/tokens/oidc gets a 404.
- How much is it going to cost me? I know there is pricing but its hard to figure out what actual usage would be like. Also I don't see any usage info in the webui right now.
Don't think of this as in any way connected to the Fly Machines API. For now, just take it on its own terms. We'll have an open-source local version of it relatively soon, if that clarifies anything.
To follow up on this a bit, something that I really want is a way to build and launch apps from an llm really easily. I am imagining and environment with a database, object storage, and a publicly reachable webserver. I think this could be that with OIDC auth to an s3 bucket and litestream.
I was previously thinking about doing the same thing on my homeserver with tailscale to expose the web interface publicly and tailscale oidc auth to an s3 bucket for object storage.
i believe the .sprite dir has some stuff to help claude answer those questions. haven’t done it myself but my friend said he was able to get claude to set it all up for him (yolo mode helps) including connecting to github.
reply