Either you build a tool that works well with one OS or you build one that works poorly with several.
And it is not as if those other OSes are waiting for new cross-OS init tools: They either seem to be happy with what they got or want something tailored to their own features.
Immutable distros are the future for everything. We just need to wait a for the people most heavily invested into the status quo to retire.
Any user can delete important OS files by turning their computer off while an upgrade is running in almost all traditional distros:-) Sure, you can disable updates, but that is not an option either.
First off, you do not need to know most of that stuff. Tooling around container-based development is really nice nowadays. It just works almost all the time -- and way more often than in mutable setups.
As a beginner you can not really transfer docs from one distribution to another, so you look for docs on your distribution and ask in the official support channels. Those of bazzite are pretty responsive and will be able to help. The community is able to help way better than in a traditional system where every installation is almost but not exactly the same.
Nothing is as bad as accidentally removing some important OS files and not knowing how to restore them. That will just not happen in an immutable setup.
I have installed immutable distros on lots of computers and the users usually are happier than they were on traditional linux: Nothing breaks anymore, the setup is way more solid. Its great for me, too, as I need to support them less often.
Seriously, you should give this a try: Immutable OSes are a huge step forward. Takes a few days to get used to, but I am pretty sure you will not want to go back afterwards.
I revolve very much around copyleft and its ideology. Free software formed my entire career, just as it did for the founders of Slint. From my point of view slint is GPL and offers some other license options for users that do not want GPL for whatever reason.
Forking slint is just as easy as forking any other GPL licensed project: Take all off slints code under GPL and you are done. Yes, you can not relicense that fork to a more permissive license without replacing all the code that you did not write... but that is exactly the same as with any other GPL project you fork. Any use of Slint under GPL is exactly as using any other GPL project, with the same obligations and protections to all parties involved.
I get that you are feeling slint is not GPL, but I do not understand where that feeling comes from. Is it "just" because there is a company backing it? Or because that company is selling their product in addition to oing it under GPL? That is fine for the GNU project from all I understand. Or is it because of contributions happen under MIT terms? But that does not effect the end users that the GPL is protecting in any way.
You are fine with a free software project using Slint as well: Slint is a GPL project, with everything that implies. The releases are out there and the slint project is bound to the terms it released them under. In theory we could release new versions without the GPL option, but we can not take the sources of the released versions away. Neither the other licensing options nor the contribution rules change that. If youbare happy with GPL dependencies, you can use Slint just as any other GPL dependency, with the same risks and benefits.
The copyright holders of any GPL project can decide to relicense their (future) releases. I admit that it is a bit simpler in Slints case due to the contribution rules, but other projects have similar rules in place. Copyright assignments, CLAs, ..., they all exist to simplify a possible future relicensing effort. And even GPL projects without such provisions in place have manged to relicense before.
As a user of Slint you typically never get into contact with our contribution setup at all. Only a contributor might pause and decide not to spend time on Slint due to that. IMHO that is entirely normal: I use tons of free and open source projects that I would never contribute to -- for various reasons ranging from contribution terms, to programming language being used or the projects community.
In many cases you can also publish slint related code in your own repository under whatever license you like. While this obviously does not work for core functionality that has to live in Slint itself, it does work for a wide range of things you might want to make available (like new widgets, ...).
Why don't you download the latest release/nightly from github and unpack it somewhere?
I mean that the company pays someone (like an existing employee) to maintain their internal fork and contribute patches back upstream.
Oh, most companies will pay someone to maintain an internal fork, but hardly any will contribute back. Sometimes that's due to lazyness, sometimes it is the idea that nobody will care for the company internal stuff, but most of the time it is outright forbidden to share internal IP even when that comes in the form of patches to open source code.
In my experience it is safe to just ignore that case and not care about corporate convenience when starting any open source project.
I use toolbox: Distrobox is a pretty horrible shell script and deleted parts of my home directory when I tried that.
In the end I just pointed toolbox to a script named podman that just adjusts the setup to what I need, implementing the missing features I wanted that way.
There is no significant section. It is just a few people telling each other the same old conspiracy stories over and over again.
Autsch! I would never do that... X11 is such a broken mess, but then my window management needs seem to be very different from yours.
Applications do have a say in how big they get rendered (typically by giving a min/max/preferred size), which window managers may or may not resepct/adjust for after the window comes up. Maybe it is just that.
Considering how widely Lennarts code got adopted: You must be missing something.