You do not even need to patch it out. It is basically an extra entry in the user db (think: /etc/passwd). Just don't fill it in and you are done, just like your location and a ton of other stuff you can put there if you want to.

Nobody can read it outside your system either... it's a defined place when (not if -- not anymore) something wants to store that information. Better have a properly protected defined place ready than have 10 different programs request that info separately and store it all over the place.

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.

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...

Any of the many immutable distros (vanilla os, fedora silverblue, bluefin, aeon, endless os, pure os, ...) will all obviously work.

Most of your customizations will live in your home directory anyway, so the details of the host OS do not matter too much. As long as it comes with the UI you like, you will be mostly fine. And yku said you like gnome, that installs many apps from flathub anyway and they work just fine from there.

For development work you just set up a distrobox/toolbox container and are ready to go with everything you need. I much prefer that over working on the "real system" as I can have different environments for different projects and do not have to polute my system with all kinds of dependencies that are useless to the functionality of my system.

NixOS is ofmcourse also an option and is quasi-immutable, but it is also much more complicated to manage.

I'd go for open source projects. They usually have bigger code bases and good practices, that they enforce on their contributors with code reviews and such.

It's a good way to get feedback on your code, something miss out on personal projects and get much less of in university and corporate projects.

I never said that you can not run a project elsewhere, my point is that you will get way more interaction on github.

Try pushing your project to github and compare the interactions you get from both forges.

When I last checked (and that is a long time ago!) it ran everywhere, but did only sandbox the application on ubuntu -- while the website claimed cross distribution and secure.

That burned all the trust I had into snaps, I have not looked at them again. Flatpaks work great for me, there is no need to switch to a wannabe walled garden which may or may not work as advertised.

Yeap, -O3 is mostly voodoo. Berger has some measurements.

Spoiler: He found your username has a bigger effect on performance than most compiler flags:-)

Build everything you use and ackage it in flatpak?

It's not even that hard to build your own gentoo-based runtimes and install stuff on top of that. Fedora does offer that, too, offering fatpaks based on their own fedora based runtime + rpms.

supply chain attacks are a serious problem that needs addressing.

Last I checked: I am not a supplier. So I will not invest effort to secure some supply chain for people that I do not have any obligations to: The license clearly states "no warranty" for a reason. I do those projects for fun, not to bother me with security stuff, notifications about security problems some automatic thing "found" that do not really effect my code and bogus merge requests to upgrade dependencies for no reason... this are all cool things if you are a supplier, do not get me wrong, but I am not. No, I will not invest hours of my free time to sign binaries nobody uses either or to fill out security surveys for badges I can display on github.

If you want me to act like a supplier: Pay me like all the other suppliers you have. I doubt there is any interest to do so for the projects I have on my private github :-)

For your own projects, it might be worth considering a move away from GitHub. (I've been thinking about it since Microsoft bought them.) Codeberg looks like a good alternative.

That also has associated costs: Your project gets instantly much less visible, so you need to keep a mirror on github for visibility. Unfortunately that also means that you will also get interactions on github, so you will need to log in occasionally to not make people think the project is dead.

Not at all: I listed the arguments you will get for that question of yours. They all are bogus, as I tried to explain between the parens.

What do you mean by "system support"? The system is mostly pushing bytes along, the programming languages/UI ovaries tend to do all the hard work. So it is usually more interesting to see what those support.