A Slint fanboy from Berlin.
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…
Not only that: It protects your data. The Unix security model is unfortunately stuck in the 1970s: It protects users from each other. That is a wonderful property, but in todays world you also need to protect the users from the applications they are running: Anything running as your user has access to all your data. And on most computer systems the interesting data is the one the users out there: Cryptogrqphic keys, login information, financial information, … . Typically users are much more upset to loose their data than about some virus infecting the OS files, those are trivial to fix.
Running anything as anlther user stops that application from having access to most of your data.
The same happens with any of the new immutable distributions. It’s just less effort as you do not need to do the nix configuration dance anymore.
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.
Github login does not help much… devs are on github, not on random forgjo instances. That’s where they see your project. Github is also where they put their fork of your project when they play with it. They will write comments using github markdown and won’t care whether that renders correctly or not in your forge.
And it is where they will report issues and open a PR. It is annoying, but it is how it is. When you ask them to open the PR elsewhere they complain sinde they need to set up an account there and copy ssh key and similar things. You need a very dedicated contributor to go through with all that… especially if it is just a few lines of drive-by fixes.
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.
That unfortunately requires setting up email… I have not bothered doing so on my boxes in a very long time.
The biggest factor to me is developer attention. I had a project on gitlab and pushed a README.md with a link to the gitlab instance into github. I got about 10 times more reactions from github, incl. PRs (where the person had grabbed the code from gitlab and did a PR on github anyway) – even in this setup. Mirroring a project to github tilts that even further.
Not being present on github means a lot less users and contributors. As long as that stays this way there is no way around github.
I hope federated forges can move some attention away from github, making other forges more visible… but I am not too optimistic :-(
The blocking certain countries is a US legal thing. It effects any forge in the US and probably in more areas close to the US. As soon as a forge gets big enough to show up on the radar of government orge they will need to do similar blocking.
You can not really blame github for that part.
Rustfmt is not very configurable. That is a wonderful thing: People don’t waste time on discussing different formatting options and every bit of rust code looks pretty identical.
Why would they need to share ssh keys? Ssh will happily accept dozens of allowed keys.
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.
Why don’t you download the latest release/nightly from github and unpack it somewhere?
Yeap, -O3 is mostly voodoo. Berger has some measurements.
Spoiler: He found your username has a bigger effect on performance than most compiler flags:-)
Ansible must examine the state of a system, detect that it is not in the desired state and then modify the current state to get it to the desired state. That is inheritently more complex than building a immutable system that is in the desired state by construction and can not get out of the desired state.
It’s fine as ,one as you use other people’s rules for ansible and just configure those, but it gets tricky fast when you start to write your own. Reliably discovering the state of a running system is surprisingly tricky.
To be fair: snaps can work for all kinds of things all over the stack from the kernel to individual applications, while flatpak just does applications. Canonical is building a lot around those abilities to handle lower level things, so I guess it makes sense for them.
IMHO flatpak does the applications better and more reliably and those are what I personally care for, so I personally stay away from snaps.
It is the same as with all logins: It goes through the Pluggable Authentication Modules. So you need a service that uses PAM (they basically all do for a long time now) and the configuration of that service needs to include homed as an option to authenticate users. Check /etc/pam.d for the config files.
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.
Censorship is about you being limited in the actions you can take to express yourself. It is not about cushioning you from the consequences of those actions from the people around you.
You obviously were allowed to take action: The contents was apparent upon on a forum and here as well. People reacted to your actions: Admins removed your contents and blocked you and I am telling you that your understanding of wayland as well as politics is limited.
Deal with it.
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…