I adore this machinery, there's a lot of money riding on the idea that interest in AI/ML will result in the value being in owning bunch of big central metal like cloud era has produced, but I'm not so sure.

I'm sure the people placing multibillion dollar bets have done their research, but the trends I see are AI getting more efficient and hardware getting more powerful, so as time goes on, it'll be more and more viable to run AI locally.

Even with token consumption increasing as AI abilities increase, there will be a point where AI output is good enough for most people.

Granted, people are very willing to hand over their data and often money to rent a software licence from the big players, but if they're all charging subscription fees where a local LLM costs nothing, that might cause a few sleepless nights for a few execs.

We could potentially see one-time-purchase model checkpoints, where users pay to get a particular version for offline use, and future development is gated behind paying again- but certainly the issue of “some level of AI is good enough for most users” might hurt the infinite growth dreams of VCs

tts would be an interesting case-study. it hasn't really been in the lime-light, so could serve as a leading indicator for what will happen when attention to text generation inevitably wanes

I use Read Aloud across a few browser platforms cause sometimes I don't care to read an article I have some passing interest in.

The landscape is a mess:

it's not really bandwidth efficient to transmit on one count, local frameworks like Piper perform well in alot of cases, there's paid APIs from the big players, at least one player has incorporated api-powered neural tts and packaged it into their browser presumably ad-supported or something, yet another has incorporated into their OS, already (though it defaults to speak and spell for god knows why). I'm not willing to pay $0.20 per page though, after experimenting, especially when the free/private solution is good enough.

Yeah, a fuse or a breaker is a pretty common thing.

Probably a more apt analogy would be a keyed adapter.

This is uncanny and worryingly specific, and I'm not a lawyer, but if you're not already under suspicion of being a criminal, then installing graphene doesn't match this definition I think

"This regulation will only apply to people who are already criminals" is a line that has never held

Suspect, they wrote, and that happens all the time. If you go into a store on the way home from work, and 99 days this works fine but the 100th day they want to look in your bag, but you can't show them confidential drawings of the Google Pixel 14 Max that you carry as part of your work, now they'll think you really did steal something and you went from no suspicion (spot check) to definitely a suspect and new things start to apply to you, e.g. if you leave without resolving the suspicion the police might have grounds to enter your house or search you when you walk out next time. The suspicion is based on being a suspect, not on any actual evidence (nobody saw you put anything in your bag)

I mean, you don't really have to speculate about what this is for, it's for an authority providing for lawful search, it seems pretty well-scoped, and similar to any old search warrant, which is not a new thing, really https://classic.austlii.edu.au/au/legis/nsw/consol_act/deccd...

Basically, they're not really setting up for a blanket ban on personal security features, that interpretation is obviously catastrophizing. Not that there aren't hamfisted laws somewhere like this, but NSWs implementation seems OK I guess

We have mass surveillance already in all 5 eyes countries that assumes that anyone can be a criminal at all times.

I find Rust pretty cohesive and consistent in its semantics. Accomplishing different tasks involves less sugar than other languages like this article seems to focus on.

Generally all of the interfaces conform to the patterns in the mem module. If you want to understand the structure of everything else unambiguously it would be best to start there: https://doc.rust-lang.org/std/mem/

When they establish personality archetypes and roles bonds form readily. That's like, the purpose of roles in an organization.

Well I guess a GLP-1 pacemaker would address this. A lifetime of doses weighs at much as a nickel?

I believe it has to be kept at refrigerated temperatures over its relatively short shelf-life (1 year, I believe).

Two lines clearly deviate from AAB.

Can't upload discord attachments from mobile.

My server got renewal halted. I rolled my own wrapper for certbot. Idk it's just a blog, I'm not that attached. It hit some rock a few months ago, I just retried and manually installed it, and it seems to have perked back up and continued receiving certs. Probably would have been more frustrating if it were a huge fleet but, it wasn't even worth my time to check logs and figure out what precisely happened (cert distributed with a modified that didn't match the ASN.1 expiry? transient issuance failure? issues the same cert? ...who knows.)

Were you running certbot multiple times per day?

Looking at the relevant limit, "Consecutive Authorization Failures per Hostname per Account"[0], it looks like there's no way to hit that specific limit if you only run once per day.

Ah, to think how many cronjobs are out there running certbot on * * * * *!

[0]: https://letsencrypt.org/docs/rate-limits/#consecutive-author...

Isn't that where we are going eventually? Certs only lasting a day?

That's a good point. I suspect as the renewal period is shortened, scripts will attempt renewal faster and faster.

I hope they don't go any shorter than a month. Let the user pick, any value up to a year should do.

Browsers are eventually going to deny any certificate after 47 days iirc

They simultaneously want shorter certs but can't cope with the current load

Nowhere in the blog post does it say they can't cope with the load, which is why the rate limits are so high. This is only about reducing wasted resources by blocking requests which are never going to succeed.

They definitely can't cope with the load at midnight, or at least couldn't back in 2022, and the fact that they mention midnight specifically in this post makes me assume they still can't. I say this because I had cert issuance fail for multiple days because of DB timeouts on their end from that: https://community.letsencrypt.org/t/post-to-new-order-url-fa...

Incidentally the fact that it took them 4 days to respond to that issue is why I'll be wary of getting 6-day certs for them. The only reason it wasn't a problem there was that it was a 30d cert and had plenty of time remaining, so I was in no rush. (Also ideally they'd have a better support channel than an open forum where an idiot "Community Leader" who doesn't know what he's talking about wastes your time, as happened in that thread.)

Why not just run your update outside rush hour though.

No, they will never get that short due to reliability issues. I could see getting down to maybe two weeks.

To make 24 hour valid certs practical you would need to generate them ahead of time and locally switch them out. This would be a lot more reliable if systems supported two certs with 50% overlapping validity periods at the same time.

Let’s Encrypt has already started issuing a limited number of 6-day certs and they will be generally available later this year.

(90 days will remain the default though)

> I think AWS charges like $0.50 per email when you use their hosted email sender.

SES? Around $0.0001 per e-mail

Yes, it was facetious, i am jabbing at Let's Encrypt for ceasing email operations.

Assuming 47 day certs they would be saving 500k USD/year just from SES fees with that change.

For a free service, that's a whole lot of money.

By my memory, a cron runs a script that checks my cert file's last modified daily. When it is a certain number of days since (flavored Bash statements) the file last modified I'll certbot and install whatever comes back.

It's very under-engineered, maybe a trifold pamphlet on light A11 printed with a laser jet running out of ink.

I've probably spent more time talking about how much it sucks than I have bothered considering a proper solution, at this point.

>I've probably spent more time talking about how much it sucks than I have bothered considering a proper solution, at this point.

I respect this. Reading someone else write this makes me feel more comfortable thinking about the things in my life I could be doing more to improve, which makes me respect this even more.

Brought to you by lightspeed briefs