The Kubic Project currently produces a "CaaSP-like" Tumbleweed OS, focused on Kubernetes clusters However many of the attributes of Kubic (read-only filesystem, transactional updates, containerised services) could be an interesting platform for another use A Chromebook-like Linux Desktop

My current mail setup is mu4e and emacs based mail client included with the amazing mu mail indexer. mu works similar to notmuch but allows easy bidirectional operation with the original Maildir. Add mbsync (isync) to sync imap locally and msmtp and you have a full mail setup.

We all pant for customer data. Which hardware do customers run ? Which packages are installed ? Which services are running ? etc. pp. A lot of this data is in the supportconfig. But this is neither collected, nor centralized, not easily accessible.

Idea is to have SUSE system with OpenZFS as root FS. Why ZFS

There is a couple of libraries available for asynchronous and non-blocking processing of HTTP requests (in Java) that can be used to avoid having threads waiting for responses in request intensive applications, for example: - Apache HttpAsyncClient

Currently Salt is using supportconfig utility alongside with the SUSE Manager installation. Every single bugreport for Salt, that contains its logs are always useless that regard. It might work for SUSE Manager, but for Salt it doesn't. And even after asking user to switch the cluster into a debug mode or even trace mode, it is still far away from being useful enough, so the supporter don't need to dance with the tambourine around the fire, guessing what ghost just munged what component. What if we can reuse Salt's internal tooling and develop some more tools that will not just grab logs/sysinfo from what is already there, but also get much more data, "x-ray" minions, turn them into a debug mode, collect right data, perform tests realtime etc?

I would like to learn Elixir, I plan to do some tutorial and look into books. I if I have time also start with Phoenix the framework for Elixir :smile: