Check if you find anything about this in the kernel log (dmesg).

Time and your personal experience might be a factor.

Often the first book I read from an author, leaves a very positive and fresh impression, but after I read a couple more of the same author, I learn their structure and writing style, and it becomes just more of the same, and I have trouble getting into those books.

It is similar in other mediums as well, maybe to a lesser degree. TV series and video games have multiple writers to keep things fresh, but at some point it becomes just more of the same.

You can still try to replay/rewatch/reread the great ones, but then you know what to expect. This might not be the case with new media of the same authors.

Also time directly might also effect it, I have trouble really getting into any game now, because I have other stuff to do, and getting back into it afterwards (especially with video games) is more difficult.

Not the drama itself should influence your judgment, but how they will deal with it.

Whenever people work together on something, there will be some drama, but if they are dealing with it, then that should be fine.

Nix and NixOS are big enough, that even if it fails, there are enough other people that will continue it, maybe under a different name.

Even it that causes a hard fork, which I currently think is unlikely, there are may examples where that worked and resolved itself over time, without too much of burden on the users, meaning there are clear migration processes available: owncloud/nextcloud, Gogs/Gitea/Forgejo, redis/valkey, …

As I said, it is not impossible to move away from gh compared to many other cases in other industries, just that it is more difficult than necessary because vendor-lockin is allowed.

If vendor-lockin was illegal, companies had more incentives to use established or create new standards to facilitate simpler migration between software stacks, without changing the external interface.

For instance allowing your own DNS name to be used as the repo/project basepath instead of enforcing github.com, Allowing comments, reviews, issues and pull requests via email or other federated services, instead of enforcing github accounts to do so, providing documented, stable and full-featured APIs for every component of their software, so that it is easy to migrate and pick and choose different components of their while stack from possible different vendors, …

There are so many ways that would improve the migration situation, while also providing more ways for other ideas to compete on a level playing field. If a bright engineer has an idea for improving one component from github, they should not be required to write a whole separate platform first.

Well the reason for that is the vendor-lockin and centralized technology.

If your project for instance uses a similar development method as the linux kernel does, e.g. sending and reviewing patches via mailing lists and providing url to push and pull git repos from, it is quite easy to switch out the software stack underneath, because your are dealing with quasi-standart data: Mbox, SMTP, HTTP(s) and DNS. So you can move your whole community to a different software stack by just changing some DNS entries and maybe provide some url rewrite rules without disrupting the development process.

I am not saying that the mailing list development process is the right one for every project, but it demonstrates how agnostic to the software stack it could be.

If vendor-lockin is made illegal, the service providers would have more incentives to use or create standardized APIs, so that their product can be replaced by competitors. So switching to or from github/gitlab/… becomes easier.

It has more than you expect, if your project is established on github and want to move away you have to deal with:

• migration of issues
• migration of pull requests
• migration of all review comments etc
• migration of the wiki
• migration of the pages
• convince all contributors to possible create a new account somewhere else
• changing of the project urls. I don’t think github offers a url rewrite service
• forks on github will not have the new destination as the fork base
• change the ci and release process
• because you cannot add url rewrite rules to your old gh project, you might need to only ‘archive’ the project there with manually written text, to point to the new destination, for people to find it

You don’t know what a “monopoly” is.

What the author is probably searching for is “vendor-lockin”, which is an anticompetitive practice for so long that it became the way many companies rely their business on. It favors established products over new-comers by making switching offerings difficult/expensive or even impossible, thus better products often have no chance of competing in a field, that was dominated by a single supplier for a while.

IMO there should be strict regulations and high fines associated with it, because it hinders innovation massively across all industries.

The cost of switching away from github for a project is high, but not as high as in other fields.

IDK. I think that just causes more confusion. Like with “Use gitlab”, do I mean the application or gitlab.com?

“We give you money, so that you don’t put a backdoor from another country in your software.”

Only really nice when not CLA is required and every contributor retains their copyright. Ente doesn’t seem to require a CLA.

Otherwise it allows the owner to just take the changes from their contributors and change the license at a later date.

Or other standard archiving formats like WARC.

There also is https://github.com/ArchiveBox/ArchiveBox which looks a bit similar.

Snap is just one case where Ubuntu is annoying.

It is also a commercial distribution. If you ever used a community distribution like Arch, Gentoo or even Debian, then you will notice that they much more encourage participation. You can contribute your ideas and work without requiring to sign any CLAs.

Because Ubuntu wants to control/own parts of the system, they tend to, rather then contributing to existing solutions, create their own, often subpar, software, that requires CLAs. See upstart vs openrc or later systemd, Mir vs Wayland, which they both later adopted anyway, Unity vs Gnome, snap vs flatpak, microk8 vs k3s, bazar vs git or mercurial, … The NIH syndrom is pretty strong in Ubuntu. And even if Ubuntu came first with some of these solutions, the community had to create the alternative because they where controlling it.

I mod my games on my PC and sync it to my SteamDeck. I also sync the save files back and fourth, to continue playing on different devices. Mostly non-steam games.

I also sync my eBook collection to my eink reader with syncthing.

Everything is also mirrored to my always-on NAS, so syncing always works.

Environment variables isn’t a concept of just docker, but general native app programming. So look into the docs of your language.

To the second point, as a avid firefox user, I noticed that some Webapps seem to not depend on the Browser alone.

Even in safe mode, some Webapps sometimes work better on different systems than on others using the same Firefox version.

For instance youtube streaming seem to work better on my Linux laptop then on my Windows desktop, where it becomes stuttery. In Chromium there it works as well as Firefox on my Laptop.

What I want to say is that browsers and all the systems around this are very complicated. So your milage with the same browser will vary, and you might blame the wrong thing.

I have setup a mail server for my employer, and doing it manually yourself is difficult. I didn’t want to do it for myself as well.

However I looked into mailcow, and tried that privately and it works great so far! However, i would dedicate a separate VPS for just that.

I am hosting bitwarden myself (on a VPS) and I am not that concered about losing my passwords, because every device syncs all passwords locally regulary so that you don’t need internet to access them.

So to loose all your passwords not only do you have to loose your bitwarden server and all the backups, you also have to loose access to all your bitwarden clients synchroniously.