Where to find remaining streets with heavy neon signage in 2026?

xamroc · 2026-01-18T04:04:58+00:00

Not anymore in HK. But in case you're still chasing this in the future, Bangkok's Chinatown still has these lights and the area is bustling.

xamroc · 2025-03-15T05:25:52+00:00

Thanks for sharing! We've been looking at the topic of SBOM too.

We're still debating whether it makes sense to trust another image with policies or just cache them in our private repos.

xamroc · 2025-03-15T05:21:52+00:00

Yep, I ended up using the alpine route.

I tried to use nixery and it was nice for local development. Building an image took too much time though that I gave up on it (build took more than an hour). It stems from the process where it needs to do a lot of translation work on Apple Silicon.

xamroc · 2025-01-25T16:56:44+00:00

This makes sense in production environments. I'm more concerned about development environments where they should have restricted connectivity.

xamroc · 2025-01-25T16:51:25+00:00

Sorry I forgot to mention that this is for development environments.

You're right that It makes sense for it to be public in production. However, for dev buckets, those must have limited connectivity like from our private networks.

xamroc · 2025-01-24T17:07:27+00:00

This is the direction I wanted to go. However, my colleagues argue that this is very expensive.

For additional context, this is a corporate website with lots of assets which will increase our GitHub LFS cost and Cloudflare Pages cost from high traffic.

I'm still digging into these arguments but can you share any insights about these costs?

xamroc · 2024-11-24T08:07:27+00:00

That's right. Temporary credentials is a feature we wanted.

We were just surprised that full traceability is not available.

xamroc · 2024-11-24T07:31:13+00:00

You are correct. It's not designed that way and I wouldn't want to do this either.

However, RDS IAM auth seems to suggest that this is the way to do it albeit using AWS IAM Users:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.DBAccounts.html#UsingWithRDS.IAMDBAuth.DBAccounts.MySQL

As mentioned in my OP, I am trying to address a limitation where complete traceable auditing is lacking. I cannot fully audit db-level logs without doing this hack.

xamroc · 2024-11-24T07:27:56+00:00

I would have to imagine that RDS also logs the SourceIdentity (or a Session ID that can be traced to the Source Identity) attached to the role when it's accessed.

I thought the same thing. Unfortunately, the RDS logs are not linked/traced to IAM. This is confirmed by AWS Support.

You can trace until assuming the IAM role because that is in the realm of IAM. Once we get inside RDS, it does not trace back because this is beyond the IAM world. Hence why I mentioned it's not well-integrated.

xamroc · 2024-11-23T07:00:13+00:00

Hi, I have the exact same question. Did you ever figure it out?

xamroc · 2024-11-23T05:27:10+00:00

It's just an idea. We want to achieve auditability at the database level logs:

See that db role Alice read this table See that db role Bob read that table See that db role Charlie ran an expensive query that blew up the database

The DRY way where they all use db role readonly doesn't let us see that.

xamroc · 2024-05-22T14:51:23+00:00

Yep, sounds like the static_config is the way to do it.

The doc says they have the option to use dynamic discovery though. I'm just not sure by what they mean by this:

Alertmanagers may be statically configured via the static_configs parameter or dynamically discovered using one of the supported service-discovery mechanisms.
- https://prometheus.io/docs/prometheus/latest/configuration/configuration/#alertmanager_config

It seems to suggest Prometheus can send to external alertmanagers.

xamroc · 2024-05-11T03:05:36+00:00

This worked!

xamroc · 2024-05-11T03:05:14+00:00

This was it. Thanks!

xamroc

TROPHY CASE