Readit NewsThis isn't LE's decision: a 47 day max was voted on by the CA/Browser Forum.
https://www.digicert.com/blog/tls-certificate-lifetimes-will...
https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-sch...
https://groups.google.com/a/groups.cabforum.org/g/servercert... - public votes of all members, which were unanimously Yes or Abstain.
IMO this is a policy change that can Break the Internet, as many archived/legacy sites on old-school certificates may not be able to afford the upfront tech or ongoing labor to transition from annual to effectively-monthly renewals, and will simply be shut down.
And, per other comments, this will make LE the only viable option to modernize, and thus much more of a central point of failure than before.
But Let's Encrypt is not responsible for this move, and did not vote on the ballot.
When that happens you really really should look into the much maligned no-sql alternatives. Similarly to the hatred ORMs get, no-sql data stores actually have some huge benefits. Especially at the point where db schema maintenance starts to break down. Ie. Who cares if someone adds a new field to the FB Newsfeed object in development when ultimately it's a key-value store fetched with graphQL queries? The only person it'll affect is the developer who added that field, no one else will even notice the new key value object unless they fetch it. There's no way to make SQL work at all at scale (scale in terms of number of devs messing with the schema) but a key-value store with graphQL works really well there.
Small orgs where you're the senior eng and can keep the schema in check on review? Use an ORM to a traditional db, escape hatch to raw SQL when needed, keep a close eye on any schema changes.
Big orgs where there's a tons of teams wanting to change things at high velocity? I have no idea how to make either SQL or ORMs work in these cases. I do know from experience how to make graphQL and a key-value store work well though and that's where the above issues happen in my experience. It's really not an ORM specific issue. I suggest going down the no-sql route in those cases.
There is zero guarantee that whatever you ask the database for contains anything valid, so your code gets littered with null and undefined checks, and if you ask for example a field "color" what is it going to contain? A hex value? rgb(), rgba(), integer? So you need to check that too.
In my experience NoSQL is even worse, they are literally data dumps (as in garbage dump).
result = orm.query({raw sql}, parameters)
I have wonderful and trivially configurable db connection state management
I have the ability to do things really simply when i want to; i still can use the ORM magic for quick prototyping or when i know the query is actually trivial object fetching.
The result passing into an object that matches the result of the query is definitely nicer with a good ORM library than every raw SQL library i've used.
I think this happens because ORMs make you treat the database as a dumb datastore and hence the poor schema.
The problem is coming from the other side, the Americans are threatening to start a new trade war if the EU doesn't permit their murdermobiles on the European roads.
IMO pedestrian safety should still come above all else, but this is not an initiative coming from some EU representatives who want to own a Cybertruck. Blocking these cars can have impact on the war against Ukraine and the prices of fuel and other import products on the short term.
I've never broke / pulled a fire alarm, I'm sure I can, but let me.
ALSO EVERY AIRPORT SHOULD HAVE MOCK EMERGENCY AIRPLANE DOORS FOR PEOPLE TO TRY OUT.