| Yes, how do you know EXACTLY what code/service/diagnosis/communication library you'll need in the future? Answer: you don't. You don't know what corner you're painting yourself into. The linux kernel, outside of its excessive amounts of drivers, is full of code that is useful for computers, vms, and containers in lots of different situations: normal operation, compromised, at load, in distress, etc. I doubt you can even make a list of the utilities you'd need ahead of time for getting stats on the container's state. network? disk? processes? memory? Linux obviously used to scale to very constrained computers (386/486s with a couple megs of ram was the PC state of the art when Linux was initially developed) up to the current supercomputers and large vms on AWS and other vendors. A lot of the size bloat in linux for container images is the drivers. For containers and VMs, one really doesn't need all the driver variants because a VM/container should just be presented a limited virtual hardware interface. Then you could greatly reduce the driver portion of the monokernel. Once you get rid of that, linux should probably concern itself with a couple "power of 1000" kernels. kiloherz/kilobytes of ram (maybe not even bother with this) aka the 80s computer. Since this is an 8 or 16 bit computer, linux may not be practically back-scalable to this mode of computing, but I don't know linux history enough megahertz/megabytes of ram aka the 90s computer aka the 32 bit era. gigahertz/gigabytes+ (2000s to modern) aka the 64 bit era. terascale is basically served by 64 bit kernels afaik. Your typical container will basically fit into one of these profiles I would guess. But the basic linux/unix model should work for every one of them... because it has, since the 70s, on machines from the PDP-7 on up. So IMO, container focused derivatives of Linux should concentrate work on tailoring to these levels. Container applications should basically be targetted at one of the levels. Granted, maybe the 1000 factor jump is a bit big. Economically there is a big difference between 1, 10, 100 MB and gigabyte memory spaces in particular, and what you can cram into a machine or pod. But the KB image should be able to overlap with the low end MB (although that takes ugly segmentation pointers and other memory extension hacks). The MB image can DEFINITELY encroach on the low end GB image. |