For those of us without an account that would like to see the entire source

I completely overlooked the shipping-of-tarballs. Links make sense, here. I had 'unpacked' and relatively-local data in mind. Absolutely would not go as far to suggest their scheme pick up 'zfs {send,receive}'/equivalent, lol.

Effectiveness is debatable, this approach still has duplication. An insignificant amount, I'll admit. The filesystem handling this at the block level is probably less problematic/prone to rework and more efficient.

edit: Eh, ignore me. I see this is preparing for [whatever filesystem hosts chose] thanks to 'ameliaquining' below. Originally thought this was all Discourse-proper, processing data they had.

The full-display-on-focus thing certainly got my interest.

Discretion, etc. We understand that was the tool making a suggestion, not our idea. Our agency isn't in question.

The removal proposal is similar to wanting a phishing-free environment instead of preparing for the inevitability. I could see removing this message based on your point of context/utility, but not to protect the agent. We get no such protection, just training and practice.

A supply chain attack is another matter entirely; I'm sure people would pause at a new suggestion that deviates from their plan/training. As shown, autobots are eager to roll out and easily drown in context. So much so that `User` and `stdout` get confused.

If terraform were to abide, I'd hope at the very least it would check if in a pipeline or under an agent. This should be obvious from file descriptors/env.

What about the next thing that might make a suggestion relying on our discretion? Patch it for agent safety?

Let's not forget the spirit Matt champions here includes taking contributors to court, demanding more contribution, and hijacking plug-ins.

Can WP Engine talk about WordPress, Matt? I haven't followed the cases since the last time you were in the media.

What's more, I can already explore five ideas at once. There is no backlog formed by incapability, lol.

I don't understand the eagerness for "productivity as a service", celebrating quotas, and lot of other conjecture I could get twisted up with... but I'll skip it this time. Rarely pays off :)

> This feature is deprecated as of Cockpit 322.

Still works on 357 (Fedora 43)... so it's one of those "you can use it, but don't expect fixes" things, I guess. ref: https://cockpit-project.org/guide/latest/#multi-host

I believe when 'roscas' says this feature was dropped, they're talking about the requirement to enable 'AllowMultiHost'. As far as I know, this is still supported with some risk (according to the latest docs): https://cockpit-project.org/guide/latest/#secondary-auth

The failure/assumption of under-13 or whatever, as a result of manipulation, is fine. I'm not actually trying to solution something though, jeez.

I find it more compelling to say, for instance, "x% of our users have chosen not to share their information"... rather than "y% have not set it". This category would almost surely be about as 'useful' (useless) as the 'do not track' header... and a concern for something other than systemd or even the portal (to a degree).

> It's entirely optional, I get that. I could 'just' not set anything.

Why? Telemetry, mainly. I'd rather attestation [or whatever intends to use this] fail and make it apparently deliberate.