Only thing I really miss is good Podman support in Skaffold.

> As I understand they propose to pass the data explicitly, like a struct with fields for all possible request-scoped data.

So basically context.Context, except it can't propagate through third party libraries?

If you use a type like `map[string]any` then yes, it's going to be the same as Context. However, you can make a struct with fields of exactly the types you want.

It won't propagate to the third-party libraries, yes. But then again, why don't they just provide an explicit way of passing values instead of hiding them in the context?

> why don't they just provide an explicit way of passing values instead of hiding them in the context?

Hiding them in a context is the explicit way of passing values through oblivious third-party libraries.

In some future version of Go, it would be nice to just have dynamic scoping. But this works now, and it’s a good pattern. The only real issue is the function-colouring one, and that’s solvable by simply requiring that every exported function take a context.

Precisely because you need to be able to pass it through third party libraries and into callbacks on the other side where you need to recover the values.

Yeah most people talking here are unlikely to have worked on large scale Go apps.

Managing a god-level context struct with all the fields that ever could be relevant and explaining what they mean in position independent ways for documentation is just not scalable at all.

Import cycles mean you’re forced into this if you want to share between all your packages, and it gets really hairy.

The latter one shows your password in the process listing.

`mount /proc -o hidepid=1` recommended :)

First one will show how to get it :D

… which is not accessible to as many users as the process list is.

And can often be passed in bash via a filehandle, without a file.

That's true if you need to clean up temporary files every night or make a backup.

But what if your cronjob has an effect in the physical world, locally? E.g. open the parking gates every morning.

The world is inherently messy :-)

That sort of thing would be best handled by your own user's crontab, so would naturally inherit that user's TZ.

If you must run it as root, you can specify a CRON_TZ variable on a per-file basis, which will override the default.

> That's true if you need to clean up temporary files every night or make a backup.

Making a backup is usually reserved for the quietest hours of the morning, so that it does not compete as much for resources with the normal operation of the system; in my experience, the quietest hour is usually around 4:00 local time.

Well assuming that the gates don't move timezones. But obviously jobs that need to run for a given timezone should be configured to run in that timezone.

Unless the gates need to open at 2:30am and in the case of daylight savings time that hour is skipped.

Not if that cron file (you can have multiple cron files per user/system) is configured to run in the local timezone.

But then wouldn't the job run twice when time "falls back"?

no, it would run either twice at the "same time" as it is read out, but obviously 60 minutes apart time duration wise; but this can't be helped as this time "existed" twice in that time zone. Or conversely in spring that time wouldn't happen at all, but the cron job will still run 60 minutes apart time duration wise. But this is the downside of local time, just make sure if you want to open a door at 01:30 local time that that is what you really want, because the unintended consequences could be a bit strange.

Hope you're doing well Jeff! Those were good days!

Only gripe here, and it's not a devdocs problem per se, is that Firefox deletes the offline documentation if you haven't opened devdocs in a while.

Is there any way I can turn that off, preferably on a per-site setting?

This site's cookies seem to be issued for some 2 months. You can extend cookies' lifetime in Firefox globally and per-site but a cookie can (and in most cases should) be invalidated on the server side.

RabbitMQ?

https://www.rabbitmq.com/oauth2.html

Good

Not often you see simracing mentioned here!

For sure there are gains to be made by having proper material as opposed to entry level, but those quickly become marginal.

The biggest gains by far are usually found in working on your driving style. Have a look at telemetry of someone who's slightly faster and work out the differences methodologically.

Shameless self-promotion: if you're racing in iRacing, have a look at https://garage61.net, we have over 125 million laps of telemetry to learn from.