Read the proposal: Lifetimes annotations, the rust standard library (incl. basic types like Vec, ARc, ...), first class tuples, pattern matching, destructive moves, unsafe, it is all in there.
The proposal is really to bolt on Rust to the side of C++, with all the compatibility problems that brings by necessity.
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 :-(
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.
It gets rid of one more SUID binary. That's always a win for security.
Sudo probably is way more comfortable to use and has way more configurable, too -- that usually does not help to make a tool secure either:-)
Serious question: What is the point?
Just push into half a dozen mirrors and you are pretty censorship resident without the crypto voodoo put on top of git.
Github has one huge value: Discoverability of a project. This is even worse than hiding your project in one of the smaller forges... nobody can remember the mess of letters you need for this.
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.
I am looking forward to follow up articles like "woodworking as a career isent right for me", "bookkeeping as a career isent right for me" and the really enlightening "any job sucks when your boss is shit".
Watch out: That mindset is what got me into Rust in the first place!
I was so fed up with everybody drowning on about Rust that I thought I need to read up on it a bit so that I can argue against the hype. I am a seasoned C++ dev after all, I use a language that I picked because it allowed for robust and fast code. What could Rust add on top of that?
Well, I have a job working almost exclusively with rust now and do not plan to ever go back.
How is that different to when every distribution shoved their implementation of sysv-init into your face? You were never free to choose your init, it always came from the distribution. You could (and still can) replace the init system, if you are willing to do the work involved.
That's the whole point: Nobody is willing to do the work for one distribution, if they can just improve systemd and fix a whole bunch of distributions at once. That's why developers flock to the systemd umbrella project to implement their ideas there, which is why systemd keeps getting cool be features for the plumbing layer of Linux -- which is far more than just the init system.
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:-)