I think this is a backwards way to set up VMs. "Installing a guest" is the wrong concept. Use a VM image pre-prepared from your favourite distro to skip that step. cloud-init is the standard way for it to specialize to your use case.
Adding contraints makes it take longer to deliver a result. I probably cannot install today's engines SDKs and related tooling for example. I'd have to write my own. Doable, and would make me a better programmer, but you won't see results for a long time.
As it happens, I do this. I have various projects burning for years and yet to be published because in my hobby time I value good engineering over results.
> For example, aerated autoclaved concrete has better structural strength, doesn't need additional insulation, completely non-combustible, and is cheaper to build.
Apparently it ages out though and becomes unsafe when it does, resulting in a scandal in the UK:
"There is nothing fundamentally wrong with reinforced autoclaved aerated concrete (RAAC) as building material or system. Many buildings from the 60s and 70s built from many materials are now having problems due to inadequate maintenance, and old age."
I'm not exactly sure what this is supposed to mean. I've never heard of this problem with regular brick or concrete structures.
Copyright law is an artificial legal construct, not a moral code.
I think appropriate attribution is a moral code, but I am not able to attribute every idea I have to all those who helped me develop the general intelligence that I use to develop such ideas.
I don't pay for my mind to absorb the world's information, either. And when I publish to the Internet, or give a talk, I also typically don't charge. Even when I publish under some kind of copyright restricted licence, that restriction has never (by law) extended to restricting transformative use that you might perform using your mind.
This idea that absorbing information requires paying a toll needs to change. It was never the case in copyright law anyway (and the courts are beginning to agree). Even if it were, copyright law was founded on the basis of encouraging creativity by creating an economic incentive. Appeal to "compensating the rights holders" therefore needs to be based on the economics, not just some principle about "rights" that never applied to this case anyway.
Placing various artifacts (eg. build artifacts) inside the source tree always seemed like a historical mistake to me. It leads to various accidents such as people checking in their credentials and accidentally bundling such files in source distributions, for example. These consequences are real.
Debian build tooling places build artifacts in the parent directory on the assumption that this is acceptable, but it then surprises people since it's not the norm anywhere else.
Perhaps this ship has sailed. But I think it's worth pointing out that if you have an option, don't design things that place things inside the source tree if you can avoid it.
Arrests seem like overkill. Ask them to stop, issue a fine, whatever. Sure I get you're asking for any enforcement at all. But hyperbole has a polarizing effect on discourse we should try to avoid, IMHO.
I've seen this kind of thing happen not through bias but because good people know good people, where by "good" I mean highly competent. They knew each other through university and other regional connections, so they happened to have the same ethnicity as one might expect from such a regional commonality. One got hired, referred another, and it cascaded. They were great to work with and highly competent, so I don't think there was bias even though it might appear that they're was.
All the items being discussed are useful things to think about and cover in the commit message. Certainly if after reading a commit message I do not know what was intended (eg. “is this a refactor that is not intended to change behaviour or not?”) then the commit message is missing something. What I object to is overloading all of this into the first line. The subject should be reserved for the most relevant information and is limited in length. Forcing committers to collapse a bunch of metadata into it makes it less useful for that purpose.
> sometimes resulting in arguments with authors that the editors need to smooth over
This is an understatement. A friend of mine is a published author in a field that requires correctness. The "legions of people" all got in the way, continuously introducing errors and unable to use a system with any kind of change control, so my friend had to keep rechecking the whole thing and finding further errors that had been introduced without being told about them. This included introducing errors of fact as well as simple things such as not fixing references to areas that they themselves changed. This was from an established publishing house and apparently this is normal. As far as I can tell, the roles that once added professionalism have been eroded both in skill and in budget, such that now they fail to make use of technology and just get in the way. They didn't seem to add any value in my friend's case, anyway. Perhaps it does add still add value to authors who start with a low standard of work. And perhaps the quality of publishers varies massively, resulting in hugely different experiences.
> ...upstream package maintainers who are expected to deal with bug reports from ancient versions...
They are not expected to deal with this. This is the responsibility of the Debian package maintainer.
If you (as an upstream) licensed your software in a manner that allows Debian to do what it does, and they do this to serve their users who actually want that, you are wrong to then complain about it.
If you don't want this, don't license your software like that, and Debian and their users will use some other software instead.
Refactoring and rewrites prove time and time again that they also introduce new bugs and changes in behaviour that users of stable releases do not want.
For what you want, there are other distributions for that. Debian also has stable-backports that does what you want.
No need to rage on distributions that also provide exactly what their users want.
Debian has had a better "software supply chain" posture than any other player in the ecosystem since before the turn of the century. While we all face the risk of malware from upstream, Debian is the least at risk of being affected by it. See for example the stream of issues from npm et al. None of it has affected Debian.
> In this context we are talking explicitly about cloud-hosted AIs.
Looking upthread, we seem to be talking about Claude. Claude is cloud-hosted inference but the harness is local if you're using Claude Code, and can be MITM'd there.
> It boggles my mind to see legal firms increasingly rely on consumer-oriented cloud services while acting like they are retaining custody of the data entrusted to them.
My theory is that lawyers tend to lean on the law to protect them more than others might. "I can ensure that it would be illegal for them to them to expose this data; therefore this method is safe" vs. "If they expose this data, is that a situation I want to deal with?".
A smart AI would realise that I can MITM its web access such that sees the .well-known token that isn't actually there. I assume that the model doesn't have CA certificates embedded into it, and relies on its harness for that.