Which makes me wonder if it's not an OS question at all, but an interface question...
On Mon, 6 Sept 2021 at 16:54, Paul van den Bergen < paul.vandenber...@gmail.com> wrote: > 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 > > -- 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
