playing doom on one's robot
speed running hl2 on one's robot, accelerated back hopping using its boobs as the only input method

@rowan @kasdeya we strongly agree with this. to add an example from our field to augment the ECS one: let's talk containers

the use case that they were designed to be used in is deployment of web software, typically in a commercial setting. that's where they actually make sense, so let's start there

the most obvious alternative is to install an application and all its dependencies directly on the host, and this is more straightforward in basically every way — it's easier to get started with, easier to debug, on many systems it's the same mechanisms as installing it on a desktop machine, what could be easier right?

the difficulty with this approach is really only going to show when we start going past this simplified scenario. if we ever in the future need to move this application to new hardware, that's now a non-trivial operation; or say this organization has both a web app and an API for their mobile app, and those are managed by different teams with different dependencies — keeping track of what part of the system exists for what app is easy to mess up and time consuming to fix; worse still, these situations compound on each other: in three years when the mobile app traffic is overwhelming the web server and we want to split these up we may find ourselves asking "wait why is there a modified fork of curl in /opt/ again, which app was this for?"

ostensibly this could be solved purely with documentation, but if there's a manager out there who gives time for that we've never heard of them — so for basically as long as we've been in this space, there have been tools that try to encapsulate an application, its dependencies, and its runtime environment, so they are easier to keep track of in those kinds of situations. there are tools that were in use before containers (VMs, basic chroot jails, isolated user environments, etc) but containers became widespread because they managed to be easier to use (and more easily standardized across languages) than the other broadly available options for mitigating this encapsulation problem

so that was its initial reason for existing, but since becoming more widespread it's been adopted for additional reasons (all with their pros and cons as well)

- containerized development environments to standardize tools and versions across members of a team

- providing a pre-configured runtime environment for self-hosted apps

- running legacy software in an isolated environment where it's less of a risk to be using outdated tools or libraries

all of these are kind of "worse" reasons to use containers (we doubt any of them would have popularized them on their own) but they exist because they're piggybacking on the fact that containers have become such a widespread thing; to a developer who already knows a bit about running containers for deployment reasons, these uses are more or less an easy bonus (but to someone who doesn't already know that, it's absolutely overcomplicated)

FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
FUCK A PUMPKIN
In June 2003, Amnesty International published reports of human rights abuses by the U.S. military and its coalition partners at detention centers and prisons in Iraq. [26]

@fridgelite @freeplay clumsy kbity