That's not how most distro kernels are built, but sure you can build a custom kernel with everything statically linked in. What you can't do is link your application in as well and do whole-program optimizations on the whole binary, which is what Ali is trying to do here. We're also hoping that the eventual solution will be distro friendly enough that we can pack the "kernel library" into a future Fedora which you can use to link your own servers into unikernels.
Of course it's not, but the comment I replied to was about whether using it to build binaries for extremely small embedded systems made sense. In that scenario a distro kernel from one of the desktop distros is a total non-starter.
If a few MB of space matters, then you'll want a suitably configured kernel that disables a ton of stuff that is totally irrelevant for such a system, and you'll need to take that configuration into account whether or not you're building a normal kernel or a unikernel, as it involves not just excluding drivers and the like, but disabling functionality that if left enabled will not get removed by the linker because there will be calls into it from code paths that are reachable.
Do that, and you'll find it is pretty straightforward to get a Linux kernel down under 1MB.
Now, it's possible your tooling makes that easier, but my point is that it is equally possible to disable those parts of the kernel for a non-unikernel system as well, and you're not going to make significant additional savings. And if you want to, then ditching glibc for one of the smaller libcs would be a better starting point.
This is not a criticism of this project - size is simply not what most people look to unikernels to address, especially not one built on a general purpose kernel.
Linux as a library is unlikely since GPL enforces a boundary between Linux and its users. Otherwise it'd've become just another statically-linkable asset copied into a bunch of corporate codebases long ago. glibc uses the same strategy too w/ LGPL. Folks wanting to overcome the latencies and bloat these barriers create, should consider the problem might be more about politics than engineering.
