How so?

Seems like an elegant enough solution to ensure you always have the right headers to build modules against the currently running kernel.

An elegant solution would be not having that problem in the first place.

The article goes into detail as to why this actually can't be used to build modules against the currently running kernel.

Isn't kernel header availability a solved problem on any linux system that isn't busy pretending not to be built on linux?

The nice thing about this is that you can keep kernel headers around in a much smaller format on-disk, while still making them available separately as a package if you want.

A few problems this solves:

1. Neither user nor tool knows specifically how to install the headers for specifically this version of the kernel.

2. Manually installing a header package on e.g. Ubuntu marks it as manually selected, meaning it doesn't get cleaned up with an 'autoremove'; selecting a generic kernel headers package (like linux-headers-4.14-generic or something) means that every time your system auto-updates the kernel package version (which happens by default on, for example, AWS IIRC, and happens a lot) you end up with yet another copy of the kernel headers, and then you blow your I/O budget uninstalling them.

3. It removes one extra step to running e.g. an eBPF program, or building an e.g. out-of-tree kernel module, so make scripts can now start to take advantage of that. For example:

    # Get headers
    if modprobe kernel_headers; then
      <unpack the tgz>
    else
      <scan through /usr/src, /usr/local/src, etc. for what looks like the right version, or fail>
    fi