The GUI that came with my distro only covers 2 of the 4 package managers I mentioned. And I'd have to use a GUI
If the subset of software available in the Debian package repository includes all the software you ever need, or if you are OK with potentially waiting years to have missing software added, and if you are OK with what are likely outdated versions of that software, then yes, all you need is apt-get install.
But, personally, I don't think I've had a Linux install that didn't include software installed from other sources
I somehow forgot you had to download every program yourself and update it yourself or put up with a third party update app at all times. I’ve only been away from Windows for like a year but it’s like “I completely forgot about that”.
The author exaggerates how bad it is, to be honest. The built in winget package manager solved most of my needs for installing and updating software while I was still using Windows, and what it left is no worse than the situation on Linux. There are also alternatives to winget, like Chocolatey.
In some ways the situation is actually worse on Linux, since I regularly use 4 different package managers on Linux: apt, flatpak, pixi/conda, and uv/pip, on top of having to manually download and install software, some of which I have to compile myself
There is very little stopping you.
You mean besides the huge time investment required to get to the point where you can meaningfully contribute?
Per the blog post linked from the Phoronix article:
The improvements and features mentioned in this blog post are planned for the next version of Linux Mint, which is scheduled for Christmas this year.
Because X11 is mostly dead and the guy who's is trying to keep it alive has a questionable understanding of the programming language it is written in, to the point where he got ejected from the original X11 project for constantly and pointlessly breaking stuff. See also https://github.com/X11Libre/xserver/pull/56
No, the idea was that apt update would keep failing while the system upgrade was running (and holding the lock):
$ apt update
E: Could not get lock /var/lib/apt/lists/lock. It is held by process 1704856 (apt)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to lock directory /var/lib/apt/lists/
But there are better ways of waiting for a process to finish, that other people have shared
If you can run sudo without a password, you could do something like:
There's no need for password-less sudo.
Instead, you can use bash -c to run a set of commands via sudo:
sudo bash -c "while true;do apt update && shutdown -h 5; sleep 5m;done"
True. Most of the false positives were easy to dismiss, but I did spent a significant amount of time of time on a couple of them, since it wasn't immediately clear to me that the code was correct. In one case the agent had missed a precondition that was verified elsewhere, and in the other it had misrepresented what the C++ standard actually said
No, he is wrong. He blindly assumed that the project followed semver, and kept insisting that it did despite the obvious evidence to the contrary. That's entirely on him
You didn't expect them to use the standard low-level, cross-platform API to build cross-platform coreutils?
But they never established a "semver social contract". You can't assume that project follows semver just because it has an x.y.z version number; semver is not the only versioning scheme, it's just a very popular one