Article Summary:
The article will explain how to build a simple, but fully functional Atomic KDE Desktop using bootc
Article Description:
I will explain step by step the configuration and building blocks to make a KDE desktop environment as well as the motivation for the endeavour.
What is bootc?
What is KDE-BOOTC as the template for further customisation.
Explanation of the container repository and the reason of each component
I moved from Kinoite to a personalised installation based on fedora-bootc, and I had to resolve a few hurdles in the process. So my idea is to share some tips with the community to make the experience easier for others.
I will acknowledge Fedora’s and Universal Blue’s proposition as mainstream solutions, but what I want to explain is that you can also create your own flavour.
Considering that bootc is relatively new, I think there is room for more ideas, experience sharing, and conversations.
I have created a public repo to share my experience, the article will be a condensed version of this project.
While you can create your own version of a KDE image-mode operating system based on bootc in various ways, I think it would be easier and more beneficial for the community and the project to use the already available bootable container image that I mentioned in my previous post.
Anyhow I’m not a member of the Fedora Magazine team and my opinion probably won’t matter, but I think any article about Fedora image-mode operating systems in general would be interesting.
Thanks for jumping in with your feedback Hristo. Your opinion as a consumer of what Fedora Magazine publishes is important!
@sigulete I’m not very familiar with these technologies, so I’m not sure how to evaluate your proposal. What I’m gathering is that there is more than one way to do it. IMO, that is OK, but we do want to state upfront if the content that follows is not a standard configuration and, consequently, users who might implement it will likely be on their own to figure out problems that might arise (i.e. it won’t be a “supported” configuration).
Would you be OK with adding that sort of disclaimer near the start of your article? If so, I think we would be OK with publishing this sort of article on Fedora Magazine.
When you have it ready to review in the Word Press instance for the Fedora Magazine, please leave a link to the preview in a comment on that ticket. The editors will review/comment/schedule it.
A drift in /etc occurs when a file in this directory is changed locally. So, any future updates to this file during container image building won’t be transfered to your OS. The rule dictates that the local version will persist.
Examples:
/etc/ssh/sshd_config is changed locally to disallow password authentication. If sshd adds new configurations, your OS won’t update them. The solution would be to add your own configurations as drop-in inside /etc/sshd_config.d/. In other words, trying to avoid changing config files when possible.
Let’s say that an imaginary service called serviced is added in the container image, and this service has a UID 699 when it is created for the first time (/etc/paswd). Now, let’s assume that the next time serviced is setup in the container image the UID is 680, which will be updated in your OS with the new /etc/passwd unless this file was locally modified.
Having wrong UID’s can lead to access issues and services not working as expected.
The solution in this case would be to avoid creating users outside the container build that would otherwise modify /etc/passwd.