<rekado>I feel compelled to pick up my sledge hammer for some reason
<rekado>I often wonder about how we can bridge the gaps between user habits and our vision of computing
<rekado>there often is a real convenience cost in doing things the way we’d like, because *we* don’t provide services and platforms but others do. And those other platforms are incompatible with our paradigm.
<rekado>it seems quaint to still talk about Docker in 2023, but its early popularity and later continued entombment in the foundations of new computing habits tells us a story that may hold lessons for us
<civodul>re convenience cost, it's maybe not all that obvious
<civodul>getting started with one of these platforms is not easy either
<civodul>it takes training, you have to get an account on an existing one or build a whole new team in your IT department to deploy one
<rekado>people aren’t *excited* about Docker anymore; but it has won its place among the ranks of foundational technologies to a point where services consider the software deployment problem to be solved by it
<civodul>in that it lets you say: "i'll stop here with Guix and use that other tool for the rest of my trip"
<civodul>the repo2docker thing was an attempt in that direction too
<rekado>“we need to build this application, with these dependencies” (me: starts packaging lots of python stuff) “oh, we need it to be scalable, and we can’t host it on site, and it shouldn’t be too expensive, so make it use kubernetes with auto-scaling on AWS EC2 instances with spot pricing…” (me: scrambles)
<rekado>I’m very forgetful when it comes to this stuff
<rekado>I sometimes have radical ideas about adapters that are specific to a couple of popular tools or platforms
<rekado>e.g. a Guix service for kubernetes and deeper integration so that guix-based services could be implemented *without* actually shipping a whole container blob (instead getting the needed store items from the deployed Guix service in the same kubernetes cluster).
<rekado>I have the impression that we attract the kind of people who are generally not embedded in those communities
<rekado>so our development efforts generally don’t overlap with whatever these communities do
<rekado>and since we don’t talk to one another there’s really not even a miniscule influence we can exert on the direction of change in those communities
<rekado>and since the guix journey ends with “guix pack -f docker” for users of those systems there’s no incentive for influence in the other direction either.
<civodul>or put differently, we're developing an insular culture
<PurpleSym>Perhaps the lack of overlap in communities stems from the lack of overlap in values. From an ideological standpoint it’s not desireable to use „the cloud“ (which, in practise, is often very proprietary) when rooting for free and open hardware and software.
<rekado>PurpleSym: while I think that that’s true to some extent, we also have perfectly fine self-hosted solutions that are free software and that are not integrated with Guix
<rekado>ganeti is a welcome exception, but our local expertise isn’t exactly overwhelmingly spread out among contributors
<rekado>openstack and its grab bag of libraries and tools is another candidate
<PurpleSym>Sure, OpenStack and Kubernetes (afaik) are free software, but running it yourself undermines the reason to use the cloud in the first place: Not having to employ someone to run it.
<rekado>kubernetes makes it easy to have different on-demand scalable services sharing the same ‘computing substrate’ (= the kubernetes cluster)
<rekado>this often *is* run on rented machines, because that’s where that seemingly limitless capacity resides
<rekado>but even if we see it as a cloud-first technology it has the very welcome effect of reducing vendor lock-in as you don’t need some proprietary scaling solution that locks you into one hoster