***Kabouik_ is now known as kabouik
<drakonis>for the intent of replacing sqlite, yes. <rekado_>I can’t let go of the thought of building a container orchestration thing for the “cloud” <rekado_>with a shared /gnu and Guix VM scripts <rekado_>*everything* I’ve looked at so far falls short, because they all use Docker images. <rekado_>drakonis: do you have the Scheme tools to dig yourself out of there? <drakonis>gonna write a kernel implementation with guile <drakonis>that and writing a daemon replacement, as previously stated <drakonis>the hard part of building the container orchestrator is that the existing tooling is not suited for it and building another one that serves to work around what exists is kind of wasteful? <drakonis>i've been checking out goblins for the replacement <rekado_>of course one could just start a big EC2 instance and then launch VMs, but then you pay for all those resources that you don’t need. <rekado_>the big selling point of the “cloud” is that you pay for what you use. <drakonis>when cwebber gets into porting aerie into guile, it'll be quite helpful <rekado_>I guess for AWS a reasonable strategy would be: i3.metal instance (autoscaling to add more when needed), firecracker (instead of qemu), shared read-only /gnu, and then launch VMs with Guix VM scripts. <rekado_>on top of that some DNS thing to re-route networking to individual instances. <rekado_>more expensive than simpler EC2 instances, but at scale it comes out cheaper and faster to have VMs share a big server and overcommit resources. <civodul>rekado_: the phrase "container orchestrator" always sounded a bit scary to me <civodul>but coming from you, it sounds exciting :-) <civodul>overall i think as a project we're failing to communicate with sysadmins and devops, and that's a shame <civodul>(now i wish it'd be useful to non-professionals looking to emancipate, first) <rekado_>I think that generally there’s a disconnect between free software activists and the … cloud people <rekado_>slogans like “the cloud is other people’s computers” are correct, but also serve as a mental cul-de-sac. <rekado_>rented computing resources exist and are very popular; and a lot of development happens right there in tooling for these resources <rekado_>and I think that if we can bridge that remaining gap between what we have and what developers use we could nerd-snipe some of them and benefit from their contributions <civodul>what i meant is that the "cloud people" is exclusively professional devs/sysadmins <rekado_>with Guix HPC we’re pushing the “reproducible science” angle hard <rekado_>but increasingly HPC admins (and users) flirt with the cloud <rekado_>so I’d like Guix to remain relevant — and actually usable – in that brave new world <civodul>we didn't go as far as i thought we'd go with that one <rekado_>“guix deploy” currently is useful when you already have a couple of Guix Systems somewhere and you want to update or modify them. <rekado_>deployment for devops people happens at the level of programs or individual services. <rekado_>and with the microservice people that’s not one OS with lots of services, but a process on this machine, and another one there. <rekado_>“guix deploy” also relies on a system’s identity, whereas devops people rarely care about that <civodul>so it's too low-level for that use case <rekado_>I don’t want us to cater to any particular backend or provider, of course <rekado_>people who already use k8s for anything will probably stick with the tools that they already have <rekado_>but in shallower waters Guix could still be very useful <rekado_>it currently faces many hurdles because the devops world has agreed on Docker for everything. <rekado_>in the translation from Guix to Docker many of our advantages disappear.