> The virtual environment model is a containerization: we're going
> to separate the versions of language and libraries that we use from
> everything else on the system so that we don't have to worry
> about cross-interference. That allows multiple projects to work
> on the same system.
That also prevents combining two projects (because they all too often
depend on different versions of the same libraries).
So, as mentioned elsewhere in the thread it ends up going down the path
where the developers only care about *their* own use of the code.
Users are presumed to be "pure users" who may have legal
access to the code but aren't really expected to do anything with the
code.
> Those were the pro arguments. The con arguments are that every
> project needs to have all dependencies tracked, and if necessary
> rebuilt when a security, performance or correctness problem is
> solved -- independently. Organizations need to understand that
> these things have costs. Then they can make decisions.
Sadly, those who make the decisions can all too often arrange so that
someone else gets to pay the costs.
Stefan
