On 08/02/2017 10:57 AM, hw wrote:
It probably makes sense under the assumption that you do pretty much everything in one container or another and that it doesn´t bother you having to switch between all the containers to do something. That would require something like a window manager turned into a container manager, and it goes towards turning away from an operating system to some kind of BIOS to run containers and the container-window manager on. You could strip down the BIOS to no more than the functionality needed for that, resulting in having less need for different software versions of the platform (BIOS).
Why hasn´t a BIOS like that already been invented? Or has it?
Since copyright issues were mentioned, please keep in mind that I am now the inventor of a container manager that is like a window manager, potentially showing programs running in whatever container as windows on your screen, bringing them together seamlessly with no further ado, as if they were running on the same OS: A common window manager would show an emacs frame besides an xterm; a container-window manager would basically do the same, but emacs and xterm would be running in different containers.
OS/2 already had something like that, but it didn´t have containers.
Why hasn´t a container manager like that already been invented? Or has it?
Wouldn´t it be much better being able to do this without needing containers?
Sure there is such a thing. It's a tiled console package (tilix is what I use). In all honesty, I wouldn't want Libreoffice running in a container and I can't imagine why you'd want an xterm in its own container. Most containers I've built have been RESTful API containers, NGINX proxies/web servers, etc. I spend more time on the container host making changes, than in the containers themselves. If an API change has been made, I throw a new container up with that change and test, rarely, if ever, do I need access the container directly. And that's the idea behind containers if you ask me.