psanford

I agree, pocket-tts is quite good. It is also very easy to make new voices from small sample files with pocket-tts.

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.

[0] https://github.com/psanford/s3db

I do not trust a free-tier VPS with my data.

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.

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.

[0] https://github.com/psanford/s3db

The API is free. The statement in the article is not about corporate friction

Developers routinely complain about Slack’s API costs and permissions

What? What API costs is the op talking about?

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.

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.

I'm curious how asahi linux manages scheduling across e cores and p cores. Has anyone done experiments with this?

Edit: It looks like there was some discussion about this on the Asahi blog 2 years ago[0].

[0] https://asahilinux.org/2024/01/fedora-asahi-new/

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.

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.

[1] https://fly.io/blog/oidc-cloud-roles/

What is the criteria for a sprite being "idle"? Is it no network activity or is it cpu based?

Those are not extensions. Not can you use them to talk to dbus.

What browser extensions? Why would I want websites to integrate with gnome or kde? What does that even mean?

Oh hey this is using my go sqlite vfs module[0]. I love it when I find out some code I wrote is useful to others!

[0] https://github.com/psanford/sqlite3vfs

This is great!

I have been using Quickwit as a low cost search engine on Lambda. It works very well for my relatively small and infrequently updated dataset.

Unfortunately Quickwit devs have decided to not support the Lambda deployment mode going forward so eventually I'll need another option.

The thing that killed perl was python. The reason that python won is because it was Google's blessed scripting language.

I had an M2 air running asahi that I loved and had similar worries. I ended up buying a maxed out refurbished M2 which I expect will last me a few more years.

Yes. It is a nice report that does not engage with 1password's security model at all. 1password specifically says that they do not think it is feasible to defend against locally executing malware.

I do hate the name ssh3. I was glad to see this at the top of the repo:

SSH3 is probably going to change its name. It is still the SSH Connection Protocol (RFC4254) running on top of HTTP/3 Extended connect, but the required changes are heavy and too distant from the philosophy of popular SSH implementations to be considered for integration. The specification draft has already been renamed ("Remote Terminals over HTTP/3"), but we need some time to come up with a nice permanent name.

I assume you were using Authy desktop for TOTP? You don't need a smartphone for storing TOTP seeds or generating TOTP codes.

I found the "lets pretend like there is no input latency" thing to be more distracting than useful. As soon as something does not work as expected the illusion is broken. It made me more grumpy than not having it on in the first place.

You can run x86 steam games on asahi easily now. muvm makes it quite easy to run x86 binaries fairly transparently on arm.

I'm comfortable with what I said.

It is fascinating that some people are so afraid of negotiating that they make up excuses why they won't try, and then they try to convince everyone else that negotiating is too dangerous to attempt.

There is no incentive for companies to do that. Its a thing that could theoretically happen in rare cases but essentially never does in the industry. Read patio11's article on why.

I think its telling that you have to reach for a >10 year old article for evidence that this is an actual risk.

One of the key points to patio11's article is that there is only upside to negotiation with no downside. You are basically saying: negotiation doesn't work so why bother. Please stop.

I once negotiated a large raise at a job where afterwards my boss told me that he could not have justified giving me that raise on his own, but because I asked for it he was able to make the case.

Negotiating often works. It has no downside for you (besides making you feel uncomfortable) and major upsides that last well beyond your current role.

Internally at slack the general consensus was that dnssec was a giant waste of time and money from a security perspective. We did it for compliance to sell into the Federal govt and federal contractors.

AWS AppRunner is the closest equivalent to Cloud Run. Its really not close though, AppRunner is an unloved service at AWS and is missing a lot of the features that make Cloud Run nice.