It is more about being lazy.
In most cases, where you havn’t destroyed your filesystem, you can just boot another Linux from a USB stick, mount your filesystems to /mnt, chroot into it, and then investigate and fix there.
See the Archlinux wiki, even if you do not use Archlinux, it is great: https://wiki.archlinux.org/title/Chroot
No no no! When you break something in Linux systems you fix it. Starting over and reinstalling everything is what you do when you mess up on Windows.
I found the main issue with many non-rolling release distributions are the upgrade instructions from one stable release to the next, and not the difficulty of installing them.
I’m myself a Archlinux guy, but that does sometimes require some carefulness and regularly (at least weekly) applying updates and does not have stable automatic updates, so I started installing Fedora atomic desktop distributions (Fedora Silverblue/Kinolite/etc.) for people that just want to use their device for basic stuff.
The reason for that is long term maintainability without an expert at hand.
I had so many bad experiences updating distributions from one stable version to the next, be it Debian and Ubuntu-based, or Fedora-based distributions.
And with those atomic desktop distributions the amount of moving parts is much lower, so hopefully upgrading them to newer releases is much more stable.
So I would suggest giving Fedora Silverblue (Gnome desktop), Kinolite (KDE) or Budgie Edition a try.
At least its plugins, which are what needs to be regularly updated as platforms change, are open source. I imagine someone will clean-room reverse-engineer the core app and make an open source one that uses the plugins.
Reverse-Engineering and reimplementing something is a lot of work, especially if it is a moving target that is still actively developed. I don’t expect anyone to do it.
Also, Louis Rossmann said they only reserve the right to go after forks to prevent a situation like all the shady ad-ridden NewPipe ones flooding Google Play Store.
That is some kind of hand wavy reasoning that might come from someone that could be sponsored by them. Louis should do better than taking any company by their word and promises. And spreading FUD about NewPipe (and by extension all of Open Source software) is also a straw man argument. An untrustworthy software repository is not a argument against the open source software application, but against the software repository and their maintainers.
If you are concerned with that, you should stop using Google Play store.
Well, with newpipes forks are possible in order to implement controversial features, with Grayjay they are unlikely because of its non-open-source license.
Just FYI. Grayjay is only source available, but not open source like newpipe and its forks.
An interesting concept would be if all hand on the 12 clocks would work, but the hands of the clock in the middle are stuck at 12 position, this way the hands in the middle would point to the clock showing the correct time.
So similar to kakoune? I tried that for a while, but it was missing some features so I went back to vim/neovim.
I need to know vi anyway, because that is available everywhere (as part of busybox), so using vim/nvim for bigger systems just fits.
Or you get a message at 3 am the next day, where they apologize that they didn’t made it, but that they will deliver sometime between 8 and 22 that day.
What about Lua/Luajit?
In most scripting languages you have the interpreter binary and the (standard) libraries as separate files. But creating self-extracting executables, that clean up after themselves can easily be done by wrapping them in a shell script.
IMO, if low dependencies and small size is really important, you could also just write your script in a low level compiled language (C, Rust, Zig, …), link it statically (e.g. with musl) and execute that.
I started using Fedora Silverblue on a tablet, seems to work fine so far, but requiring a reboot in order to install new system packages is a bit cumbersome and the process itself takes a while, but ordinary Fedora also doesn’t win any races when asked to install a new package
I think switching to FCOS or Flatcar on servers that just use containers makes sense. Since it lessens the burden of administrating the base system itself. Using butan/ignition might be unusual at first, but it also allows to put the base system configuration into a git repo, and makes initial provisioning using ansible or similar unnecessary. The rest of the system and services can be managed via portainer or similar software.
I also do not have long term experience with FCOS, but the advertised features of auto-update, rolling-release, focus on security and stability makes it a good fit for container servers, IMO.
An alternative to Debian on servers might also be Apline Linux. Which also has more a focus on network devices, but some people use it on a desktop as well.
If you have many different systems, and just want to learn to operate them all, maybe NixOS might be interesting. Using flakes, you can configure multiple machines from just one repo, and share configurations between them. But getting up to speed on NixOS might not be so easy, it has a steep learning curve.
So generally the pro of coreboot is that it is open source, but the con is that it is open source.
What I mean by that, you can fix any issues yourself, however, if you are unable to do it yourself, you have to wait until someone does it for you and often what features are available and stable are a hit and miss.
Compared to proprietary bioses, the company has some kind of standardized process for developing the bios. So you often get want you would expect. However, if the money flow from the pc vendor to the bios vendor drys up, you, or the community of owners. will not be able to fix any issues.
Linux support should be the same, regardless if you choose proprietary or open source bios. But that depends on how well the coreboot was ported to the platform. So officially supported coreboot bioses are likely better than others.
Personally, if all other attributes are equal, would go with coreboot, because I like to support vendors that offer that choice, and IMO a open source solution, that you can review and build yourself is intrinsically more secure than a binary blob, where you have to blindly trust some corporation. But other security minded people might disagree, which is fine.
Check if you find anything about this in the kernel log (dmesg).
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, …
I like RPG games, however I don’t like it when the company has the ability and incentive to bate and switch my game into a worse version after I bought it.
Denuvo forces me to be connected to the internet, which makes playing the game on the move difficult or even impossible. It also allows them to make sure that the most current version is played. MTX means they don’t have incentives to fix the game and instead sell you the fixes, or even enshittyfy it, to squeeze out more money.
This gives me the incentive to wait a couple of years, until the game doesn’t receive any updates anymore, and then decide if the final product is worth it. And hope that I will get a good experience out of it, before the Denuvo activation servers are shut down.
So you have to wait for a few years, in order to know if the gameplay is (and stays) any good.
Nvidia has created a bit of a sore spot for many Linux Developers and thus users. Through their actions and non actions made it impossible to create FOSS drivers for their hardware that work well and are integrated and tested with the rest of the system.
Many fresh users don’t seem to recognize the reason why they are having a sub par experience using their hardware is Nvidia and not the open source community. They often blame and complain to the developers of the open source drivers or applications, who either have to hack around hurdles placed by Nvidia or cannot inspect closed source drivers written by that company.
It is IMO understandable that at some point the community stops providing free and unpaid customer support for hardware and software, they have no control over or don’t even own.
If you would start paying them, then I suspect you might get better answers. Otherwise you just get information about stuff people are excited about.
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.
Well, that could have been fixed by booting from an usb stick, chrooting into you real system and either downloading and (re)installing the python package this way, or, if your package manager depends on python, download the package in the Live Linux and extracting the python package into your system, and then reinstalling it, so the package management overwrites your “manual installation”.
Could be tedious, but less so that having to reinstall everything IMO.