Re: Serpent OS Infrastructure - Live
On Thursday, 23 March 2023 at 19:31:12 UTC, M.M. wrote: On Thursday, 23 March 2023 at 16:39:17 UTC, Ikey Doherty wrote: So normally a post like this really isn't that interesting. However, our infrastructure has been written in D and is now live! [...] Wow! That's a whole lot of work, and very interesting one. I guess there's still a lot to be done. I go read more on the project website, and wish good luck with the project. Oh there's so much to do! We took the decision to aim for our PoC so we could buy approx. 6 months to build the rest of the project out. Learning how to do CI/CD via DLang has been really fun =)
Re: Serpent OS Infrastructure - Live
On Thursday, 23 March 2023 at 16:39:17 UTC, Ikey Doherty wrote: So normally a post like this really isn't that interesting. However, our infrastructure has been written in D and is now live! We've had a couple of teething problems, notably libcurl on Alma Linux is super outdated, and hit pthread_t exhaustion when using `task!FN().executeInNewThread` so we switched to a thread pool ...  Other than that, it's rolling. Blog post: https://serpentos.com/blog/2023/03/18/infrastructure-launched/ **Code** Summit (dashboard): https://github.com/serpent-os/summit Avalanche (builder as a service): https://github.com/serpent-os/avalanche Vessel (repo manager): https://github.com/serpent-os/vessel Boulder (build tool): https://github.com/serpent-os/boulder Moss (package manager): https://github.com/serpent-os/moss Shared service APIS: https://github.com/serpent-os/moss-service Shared package APIS: https://github.com/serpent-os/libmoss Instance: https://dash.serpentos.com **Basics** The build components are paired using a REST API, public keys and EdDSA JSON Web Tokens. The dashboard schedules builds using a graph, fetching the git recipes and determining missing builds. TLDR every missing build gets scheduled and ends up in the repository's public tree. Right now we're running it at a small scale to find out various teething issues, but do have plans to scale it beyond the current setup. Long story short we're looking to a k8s style setup with separate postgresql (rather than lmdb), and transient builders rather than the current pairing system for blessed instances. Also we're growing highly tired of relying on C libs that are host OS dependent, and are planning a rearchitecture of the core tooling around fibers (using vibe.d core APIs) which will lead to more natural idioms (allowing us to kill our predominantely OOP approach and move towards ducktyping and significantly less allocations) Great project!
Re: Serpent OS Infrastructure - Live
On Thursday, 23 March 2023 at 16:39:17 UTC, Ikey Doherty wrote: So normally a post like this really isn't that interesting. However, our infrastructure has been written in D and is now live! [...] Wow! That's a whole lot of work, and very interesting one. I guess there's still a lot to be done. I go read more on the project website, and wish good luck with the project.
Serpent OS Infrastructure - Live
So normally a post like this really isn't that interesting. However, our infrastructure has been written in D and is now live! We've had a couple of teething problems, notably libcurl on Alma Linux is super outdated, and hit pthread_t exhaustion when using `task!FN().executeInNewThread` so we switched to a thread pool ...  Other than that, it's rolling. Blog post: https://serpentos.com/blog/2023/03/18/infrastructure-launched/ **Code** Summit (dashboard): https://github.com/serpent-os/summit Avalanche (builder as a service): https://github.com/serpent-os/avalanche Vessel (repo manager): https://github.com/serpent-os/vessel Boulder (build tool): https://github.com/serpent-os/boulder Moss (package manager): https://github.com/serpent-os/moss Shared service APIS: https://github.com/serpent-os/moss-service Shared package APIS: https://github.com/serpent-os/libmoss Instance: https://dash.serpentos.com **Basics** The build components are paired using a REST API, public keys and EdDSA JSON Web Tokens. The dashboard schedules builds using a graph, fetching the git recipes and determining missing builds. TLDR every missing build gets scheduled and ends up in the repository's public tree. Right now we're running it at a small scale to find out various teething issues, but do have plans to scale it beyond the current setup. Long story short we're looking to a k8s style setup with separate postgresql (rather than lmdb), and transient builders rather than the current pairing system for blessed instances. Also we're growing highly tired of relying on C libs that are host OS dependent, and are planning a rearchitecture of the core tooling around fibers (using vibe.d core APIs) which will lead to more natural idioms (allowing us to kill our predominantely OOP approach and move towards ducktyping and significantly less allocations)
