I'd figured remote development was the only viable workflow for these devices anyway?

Are there any examples of small community driven teams responsible for managing $200 million revenue?

I see this as a win for Wikipedia.

Though arguably it being biased during the time of its relevance achieved the goals of the original biased editors.

Gell-Mann amnesia effect: https://en.wiktionary.org/wiki/Gell-Mann_Amnesia_effect

> systemd has no fcking clue what they're doing on networking. You need to not use systemd-resolved, and not use systemd-networkd or systemd-timesyncd either.

I'm not sure how to reconcile that with enjoying each of those:

systemd-resolved is the default on many distributions, and does DNS-over-TLS stub resolution for me. What do you suggest as an alternative that handles changing network connectivity, and DoT?

* systemd-networkd is very well documented/organised. I find it pretty useful on servers.

* systemd-timesyncd doesn't seem to cause issues for me. It being an SNTP client (rather than NTP) seems appropriate for distributions. I would like to move to NTS or Roughtime at some point.

I had figured the cost would decrease in time as deterministic builds became the norm (i.e. build tools stop including build timestamps).

I agree that it might not have positive POI. Bit tricky for me to judge.

This has been the status quo in Debian for a while now. You can build, and use diffoscope to audit the differences.

It's a stronger security property to have bit-for-bit reproducibilty, and it looks like Debian are ready to commit to it.

They're still a pragmatic choice for many usecases.

What is a win is that two independent parties can run the same build, and get the same binaries.

This is important because it removes trust from builders: anyone can verify their output.

It just so happens that unimportant things like build versions impede that.

The marginal gains are inevitably diminishing (since you pick the lucrative options).

There's a practical rate at which work can be done, limited by all sorts of things like organisation friction, how fast customers are willing/able to adopt new features, and how fast you can learn from it.

Arguably AI can improve all of these, but those improvements might not be happening as fast as CloudFlare are able to pump out features.

Further, this is all exacerbated by upper management having to made decisions at the nth derivative. Meanwhile, salary costs you now. You might foresee vast riches in future, but you have to remain solvent and competitive until then.

These all points towards layoffs. There are many factors that point towards keeping employees.

How to decide? No idea. Rightfully no one trusts me to make these!

This is contextual on a number of factors. It seems difficult to establish in the general case.

But I expect it's treated like "very serious and scary ops", which isn't wrong, but isn't enough.

I hadn't considered that societies rightfully impose standards on these things.

I consider it too early to judge the cost-benefit, but it's fair that others might have already evaluated that. I rescind my comment.