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.

The OP has no experience with either immutable nor mutable linux. So let him go with the rubust version already installed over recommending some package-based, old-school distro, just because you are more familiar with those.

OP will need to learn things either way, let him learn the future proof stuff, not the outdated ways.

Actual developer and 30+ years Linux expert.

Don’t use anything but immutable distros for development work. Hands down.

Just develop in containers and have one container per project. Doing anything else will lead to broken projects as you can not properly control dependencies per project otherwise.

It is not harder to work in a container than on the real system.

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.

So to be a GPL project you need to be able to trust the project to release all future releases under GPL in addition to having released existing code under GPL?

I do not like this approach:

First of, you need a crystal ball to decide whether a project is GPL or not: Some projects managed to pull off a license change before, just by asking devs whether they are ok and replacing code from devs that did not agree. Its rare, but it happens, so checking for CLAs, copyright assignments, …, is not enough.

Secondly this definition excludes lots of projects that release their source code under GPL, including the GNU project. They ask for copyright assignment, both to defend the GPL license, as well as to be able to relicense when weaknesses in the current licenses are found. I give you that GNU is probably way more trustworthy wrt. not changing away from the free software spirit than some random company.

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, …).

But you do get all code under GPL, which you seem to agree is a freedom preserving choice. That does make Slint free software and as save to use as any other free software project out there.

The story is a bit different when you want to contribute to slint. Slint is not a even playing field for contributions. The company has an advantage in that if can use all contributions as MIT and you can only use the companies changes under GPL, commercial, or royalty free terms.

As a contributor you need to decide whether you contribute to the slint repository, or maybe write an add-on library which you are free to license as you see fit.

You contribute code to slint under MIT and you can also use that contributed code under MIT or any other license of your choosing, it stays your code after all. You can not use other peoples code from the slint repo under MIT though, that is correct. The royalty free license tries to get as close to MIT as we can while limiting the use on embedded… but with that limitation in place it is of course not an open source license.

Contributing back to Slint is in no way required, so if you do not like our contribution terms, then you are free to not do so. Ypu are also free to use something else if you do not like our license terms.

We try to make all of the terms as clear as possible. We rewrote the Slint licensing page several times, often with extensive community feedback, to get it as clear as it is right now. If you have ideas on how we can improve, I am all ears.

You are technically correct: Slint is free software. You can get Slint as GPL or commercial terms – or the royalty free license. The latter lets you do whatever you want anywhere with the exception of “embedded” (this exception makes is not open source).

When you contribute to any MIT license project you are in the same situation: Your code will be redistributed by some company under different license terms. That’s the point of MIT & Co. You contribute MIT code to a project, the project releases its code under MIT, and a company consumes the project and restricts its use. Slint is just cutting out the middle step here.

Disclaimer: I work for Slint and appreciate being paid for contributing to open source software. I also appreciate Slint being free software.

It is unfortunately developing very slowly and it is impossible to interact with git repos… which nowadays is basically every repo:-(

Take a look at jj. It is not as ambitious, but develops faster and you can use it with any git repository out there (as long as it does not need git submodules that is).

This is the presentation from FOSDEM about the OS:

https://fosdem.org/2025/schedule/event/fosdem-2025-4057-particleos-can-we-make-lennart-poettering-run-an-image-based-distribution-/

News at 11: Senior C++ committee member still does not understand what memory safe means.

Seriously: C++ does not “archive parity with other memory-safe languages” (emphasis mine) since it is not a memory safe language itself, even if profiles deliver on everything they promise today.

I use cargo-dist to generate the binaries.

As a user I definitely want flatpaks and use them over distribution packages whereever possible. First I can sandbox the flatpak, but not the native package. Why would my browser need to be able to read my ssh keys?

Secondly I just have seen too many distro packagers sabotaging packages in the most braindead ways possible. Debian removing almost all the random data during key generation because some static analysis tool did not like the code. To this day there are servers using one of the 32k keys debian could produce during that time (they are of course all brute forced by now). Fedora removing Codecs from a video encoder, dependencies that upstream knows are broken and listsmas such in its documentation being used anyway. Random patches being applied, or versions years out of date getting shipped…

If you find a reliable way to allow for people to use data without being able to copy it: Patent it right away, the entertainment industry will be paying big time for it.

Same for erasing the laptop: You can only erase something as long as you can talk to the machine in some way to instruct it to clean itself up. The guy with the machine in hand can just turn off wifi to stop it from receiving the message…

My coworker used it till his HDD broke, taking his key into data heaven. The repository is still online thanks to radicale, but he has no way to ever get push access to it again.

So it is useless as any misstep can potentially kill your access to the repo.

Yes, I should not have said “impossible”: nothing is ever impossible to breach. All you can donis to make a breach more expensive to accomplish.

Those separate tpm chips are getting rare… most of the time they are build into the CPU (or firmware) nowadays. That makes sniffing harder, but probably opens other attack vectors.

Anyway: Using a TPM chip makes it more expensive to extract your keys than not using such a chip. So yoj win by using one.

A TPM is a very slow and dumb chip: It can hash data somebody sends to it and it can encrypt and decrypt data slowly. That’s basically it. There is no privacy concern there that I can see. That chip can not read or write memory nor talk to the network.

Together with early boot code in the firmware/bootloader/initrd and later user space that chip can do quite a few cool things.

That code will use the TPM to measure data (create a hash) it loads before transfering control over and then unlock secrets only if the measurements match expected values. There is no way to extract that key on any system with different measurements (like a different computer, or even a different OS on the same computer). I find that pretty interesting and would love to use that, but most distributions do not offer that functionality yet :-(

Using the TPM to unlock the disks is just as secure as leaving the booted computer somewhere. If you trust the machine to not let random people log in, then TPM-based unlocking is fine. If you do not: Stay away.

Extracting the keys locked to an TPM is supposed to be impossible, so you do not need to worry about somebody stealing your keys. That alone makes TPMs very interesting… your own little FIDO tocken build right intomyour machine:-)

“They” did not go anywhere yet. This is a proposal, nothing more. It will take serious discussions over years to get this into C++.

Prominent figures already said they prefer safety profiles as a less intrusive and more C++ approach at conferences It will be fun to watch this and the other safety proposals going forward.