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

Yes, wayland by design does not let random applications grab events intended for other applications nor does it let random applications take screenshots at any point in time showing other applications screens. This requires applications to do screen sharing differently, and it indeed breaks random applications sending events to random other applications. That is basically all you wail about and an absolutely necessary property of any sensible system and it is very embarrassing that it took so long to get this.

Systemd-networkd (not systemd the init system) defaulted to the google DNS servers when:

• the admin did not change the configuration
• the user did not configure anything
• the network did not announce anything
• the packagers had not changed it as they were asked to do
• the distribution actually decided to switch to networkd. Few have done somtomthis day.

That is indeed a serious issue worth bringing up decades later.

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.