At our company, it's ~35k USD increase annually. This is not negligeable.

Send them a request to have Trusted publishers support at central-support (at) sonatype.com

I did that a couple of weeks ago and received an acknowledgment "Another request on Trusted Publishing option. Assigning to Product for review and further action." so this is a bit encouraging.

At least Maven dependencies don't execute scripts on install, but Maven plugins could have a big blast radius.

That's a feature of stepsecurity though, it's not built-in.

We've been having timeouts, 504, 500 for about 30 minutes now on our "Login with Google" feature.

It's definitely DSQL with the multi-region active active feature[1].

[1]https://aws.amazon.com/rds/aurora/dsql/features/#topic-1

DSQL only uses Postgres for the query processor layer, so it doesn't require a replication library within postgres itself. Definitely NOT from DSQL.

> We’re not using any of the storage or transaction processing parts of PostgreSQL, but are using the SQL engine, an adapted version of the planner and optimizer, and the client protocol implementation. [1]

Rather, DSQL seems to do its region replication using the distributed journal abstraction [2].

[1] https://brooker.co.za/blog/2024/12/04/inside-dsql.html [2] https://brooker.co.za/blog/2024/12/06/inside-dsql-cap.html

You calculated based on a 0.99$ purchase price though, at 2.99$ it's 4825 purchases to break even.

Views and foreign keys!

Thanks. The team's working on both. For views, do you need updatable views, or are read-only views sufficient?

For me it's RO views.

I believe views were added to the preview a little while ago

edit from the launch: "With today’s launch, we’ve added support for AWS Backup, AWS PrivateLink, AWS CloudFormation, AWS CloudTrail, AWS KMS customer managed keys, and PostgreSQL views."

Correct: https://docs.aws.amazon.com/aurora-dsql/latest/userguide/wor...

This is good, just bear in mind that if you put the hash of an external composite action and that action pulls on another one without a hash, you're still vulnerable on that transitive dependency.

oh damn - that is a great point! thanks matey!

This week, Hydro-Québec, the nationalized company that provide electricity to residents of the province, has announced a major investment program to reduce electricity usage by using smart thermostats. I'm extremely worried about the life expectancy of those smart thermostats in the long run and whether it's a good use of public funds. I'm also not super thrilled of the amount of functional regular thermostats that will end up in landfills because of that initiative.

[1]https://news.hydroquebec.com/en/press-releases/2172/hydro-qu...

That doesn't mention the key detail of the Hydro Quebec smart thermostats: they keep remote control of the thermostat.

The whole idea is they can turn down your thermostat and sell the electricity to the US instead, or it was. Somehow they also encourage the adoption of electric cars, while also claiming we should save electricity. It's a very confused message.

Unless the object is immutable, like String, Integer, Long, ImmutableCollections, etc. Or your own immutable objects.

> Unless the object is immutable, like String, Integer, Long, ImmutableCollections, etc. Or your own immutable objects.

Exactly. You can have immutable primitives. You can have immutable classes. And you can combine them to form thread-safe immutable classes.

Now you're restricting yourself to a subset of the language. There's nothing stopping someone from adding a mutable member to your "immutable" type later.

It's much better to have immutable bindings/references so that nothing that mutates the object can be done through them. Rust does it very well, for example. Even C++ has a good version of this.

> It's much better to have immutable bindings/references so that nothing that mutates the object can be done through them. Rust does it very well, for example. Even C++ has a good version of this.

Yes, that might be superior but even Java is doing better than Go here.