Application containers were born out of a variety of reasons, but primarily seem to be oriented around partitioning a host OS into individual resource namespaces each with its own library context. Thus, an attempt to address the fact that the host OS is deficient in providing a multi-tenant experience out of the box.
In fact, application container deployments frequently don't use an init and process supervisor at all, but when they do it's a bare minimum loop that reaps zombies and reexecs a process on SIGCHLD.
On the linux side, the kernel will start to play second fiddle to the systemd.
That much is true, for better or for worse. systemd and much of the new desktop userland is refactoring a lot of kernel components into userspace, creating the de facto equivalent of an unwieldy hybrid kernel. I suppose Tanenbaum did win that debate, after all. Sort of.
in the debian world, the package management system has become more significant than the kernel.
The package management infrastructure is basically what makes a Linux distribution a "distribution". It's the backbone. That you can create Debian stacks based on non-Linux kernels is because many Linux packages are cross-Unix.
as a development platform you'll be able to quickly put together application stacks using microserves in a way that hasn't been practical until now
Wikipedia defines microservices as:
In computing, microservices is a software architecture
style, in which complex applications are composed of
small, independent processes communicating with each
other using language-agnostic APIs. These services are
small, highly decoupled and focus on doing a small task.
That sounds a lot like... the Unix philosophy, which you openly admit systemd is in opposition to.
It seems like a daemontools-style toolkit approach (e.g. s6, nosh, perp, runit, etc.) fits the "microservices" umbrella far better. Indeed, I've been seeing plenty of container configurations based on those tools.
"Application containers were born out of a variety of reasons, but primarily seem to be oriented around partitioning a host OS into individual resource namespaces each with its own library context. Thus, an attempt to address the fact that the host OS is deficient in providing a multi-tenant experience out of the box."
Given that multi-user and multi-tasking is pretty much a massive hack on what is at the core a single task, single user design, no surprises there.
I say a massive hack, as a CPU is in essence an assembly line. It takes data and processing directives in one end and spit processed data out the other. What multitasking does is basically to halt the assembly line mid job, documents its state, clear it out, and then load onto it the state of a different job. And so it goes, cycling through all the tasks.
Then again, the apparent reason for the discontinuation of Consolekit in favor of Logind was that the latter, via its ties to systemd-as-init-and-cgroup-manager-in-chief, was multi-seat.
A concept where one pretty much recreates the mainframe on the desktop by logically assigning disparate IO devices to a "seat", and so in essence creates terminals. Apparently this is supposed to work while still maintaining the ability to plug and unplug IO devices at will. Quite the rabbit hole.
Application containers were born out of a variety of reasons, but primarily seem to be oriented around partitioning a host OS into individual resource namespaces each with its own library context. Thus, an attempt to address the fact that the host OS is deficient in providing a multi-tenant experience out of the box.
In fact, application container deployments frequently don't use an init and process supervisor at all, but when they do it's a bare minimum loop that reaps zombies and reexecs a process on SIGCHLD.
On the linux side, the kernel will start to play second fiddle to the systemd.
That much is true, for better or for worse. systemd and much of the new desktop userland is refactoring a lot of kernel components into userspace, creating the de facto equivalent of an unwieldy hybrid kernel. I suppose Tanenbaum did win that debate, after all. Sort of.
in the debian world, the package management system has become more significant than the kernel.
The package management infrastructure is basically what makes a Linux distribution a "distribution". It's the backbone. That you can create Debian stacks based on non-Linux kernels is because many Linux packages are cross-Unix.
as a development platform you'll be able to quickly put together application stacks using microserves in a way that hasn't been practical until now
Wikipedia defines microservices as:
That sounds a lot like... the Unix philosophy, which you openly admit systemd is in opposition to.It seems like a daemontools-style toolkit approach (e.g. s6, nosh, perp, runit, etc.) fits the "microservices" umbrella far better. Indeed, I've been seeing plenty of container configurations based on those tools.