I have had similar thoughts on disk abstraction - especially the exposure of underlying features like snapshots to higher abstraction layers. So for example it should be possible for a filesystem to implement git like concurrency management using ZFS snapshots... if only the various layers between the application (git) and the underpinning file system (ZFS) oculd expose appropriate capabilities up and down the stack. (and if you do ti right, you don't need to care what the technology is at any given layer.)
On Mon, 6 Sept 2021 at 14:52, Edward Savage via luv-main < luv-main@luv.asn.au> wrote: > Okay, I’ll bite. > > The perspective Timothy presents is a bit of a surprise. And I half > wonder if it doesn’t go far enough? > > Should we really stop at considering the relationship with hardware when > we could consider the software as well. > > Thinking about my own domain of distributed containerised computing, from > this perspective, it’s odd to me that Kubernetes, Operators[1], and all of > the Custom Resources[2] we manage with them are run entirely in userspace. > Really, it could be argued that we’re running jobs on a scheduler on top of > the already capable system scheduler just to add a handful of features to > manage the container runtimes that are already being managed by the same > system scheduler. And you know, if someone really took me to task, as the > speaker might, I think I'd really struggle to justify why this is a > rational design. > > And it gets worse. > > Because we’re abstracted in this way in the distributed world, not an > accepted part of the “Operating System”, it’s not natural for us to use or > add to the features already shipped with the Linux kernel. This results in > all sorts of questionable duplication: we run additional services like > Vault when every server already has a TPM, we manage our own volume > topology and encryption(!), we use service like Istio to provide in-transit > encryption and discovery when BPF and the Kernel can already do it better, > and we spend months writing Operators to manage resources that don’t neatly > fit into the Kubernetes ecosystem when FUSE and UIO have been around > forever. And more. > > Which, I think, brings us neatly back to Timothys point; should we be > extending kernels into these domains, and if we do, how could it be done > properly. I definitely don't have any answers on that topic. Though I > know it would be entirely technically possible to extend Linux in a way > where the complete Kubernetes ecosystem and capability set could be rolled > into the kernel cleanly. > > We'd just have to redefine what we consider the Linux Operating System to > be to do it. > > Edward > > [1] Redhat has deleted the original post, …ouch > http://web.archive.org/web/20210210032403/https://coreos.com/blog/introducing-operators.html > [2] With some imagination this could be a driver interface right? > https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/ > > On Fri, Sep 3, 2021 at 3:01 PM Russell Coker via luv-main < > luv-main@luv.asn.au> wrote: > >> https://www.youtube.com/watch?v=36myc8wQhLo >> >> This guy is trying to incite the audience, but he makes some really good >> technical points. >> >> -- >> My Main Blog http://etbe.coker.com.au/ >> My Documents Blog http://doc.coker.com.au/ >> >> _______________________________________________ >> luv-main mailing list -- luv-main@luv.asn.au >> To unsubscribe send an email to luv-main-le...@luv.asn.au >> > _______________________________________________ > luv-main mailing list -- luv-main@luv.asn.au > To unsubscribe send an email to luv-main-le...@luv.asn.au > -- Dr Paul van den Bergen
_______________________________________________ luv-main mailing list -- luv-main@luv.asn.au To unsubscribe send an email to luv-main-le...@luv.asn.au
