Excuse me what?
Excuse me what?
The accounts of misunderstood negative encounters accumulate and evolve into rumors that exacerbate challenges for beginners and affect the broader community. When someone new faces a genuine issue, they often misinterpret the situation and later recount their experience online, sometimes even after gaining more insight. This leads to widespread misinformation about problems with certain software. Experienced users may overlook these stories, dismissing them as irrelevant or unbelievable, while those who share incomplete accounts can feel dismissed by more knowledgeable peers. Newcomers, influenced by these inaccurate tales, might skip using software that doesn’t actually have the issues they heard about. No one can accurately recall the real problem faced by the novice, resulting in everyone losing valuable understanding and trust in the community.
Uncertain about the exact error Linus encountered. It’s unclear which packages he had installed when he attempted to run 'apt get,' making it hard to determine if autocompletion tools were available. You can add apt on Arch using the AUR: https://aur.archlinux.org/packages/apt. However, pkgfile's 'command-not-found.bash' hook indicates that apt might be present in extra/jdk7-openjdk 7.u261_2.6.22-1. The system appears to recognize this as a Debian package manager, so installing the dependency could provide apt functionality.
This seems like a sensible account. I was also taken aback when Linus mentioned the terminal recommended installing "apt dependencies" while trying to install OBS-Studio with apt on Manjaro. To the OP: you likely have solid reasons to doubt someone deliberately distorting Linux's image. As shown, there’s actually a much more reasonable explanation that feels far more believable than the idea of Linus fabricating claims about Linux.
When attempting to install obs-studio on a Manjaro system, the process reports "command not found" because the tool isn’t installed there. It doesn’t attempt to assist you; instead, it checks standard locations like /usr/bin or /usr/local/bin for available commands. If not found, you must install it manually or accept that it won’t work on this architecture. Under no conditions will it try to retrieve package dependencies for an Arch-based system. It’s understandable he tried apt-get since he’s familiar with Pop-OS, but at the same time, always verify your content before sharing it widely. In a real-world situation, someone searching "apt-get command not found manjaro" would quickly notice that Arch doesn’t use apt and might waste time spreading misinformation to many users.
I noticed someone on YouTube hinting that Linus might have accidentally triggered a yes and wrongly thought the repeated display came from apt-get. Alternatively, it could be he simply didn’t understand how to interpret bash’s command-not-found output and kept running sudo apt-get install obs-studio repeatedly. The situation feels quite perplexing because it starts with a command that isn’t present, which might lead you to believe the missing command is actually producing the results. Bash and sudo often provide more confusing messages compared to modern, intuitive shells. In a root shell, Fish handles this somewhat better: # apt-get install obs-studio fish: Unknown command: apt-get So does ZSH: # apt-get install obs-studio zsh: command not found: apt-get But Bash? # apt-get install obs-studio bash: apt-get: command not found A command-not-found handler would have likely told Linus that APT wasn’t available, yet he might have proceeded to install it using the suggested pacman command. If you attempt to use apt on a system that doesn’t rely on it for package management, the error message still fails to clarify that different distros employ various package managers: # apt-get install obs-studio E: Unable to determine a suitable packaging system type This is essentially a common blunder new users should anticipate. Creating aliases that execute the right equivalents (such as openSUSE’s approach) or displaying the manual page for the proper command (like Garuda’s method) can help reduce such mistakes. Personally, I’d prefer to see a more advanced CNF handler that integrates with sudo and explains clearly what Linus suggested he’d have liked—apart from noting that apt-get is meant for other OSes, not this one. Check the manual for the package manager on Manjaro by running: man pacman (If you want to enable apt-get for development, run "sudo pacman -S apt".)
I feel the urge here, but I'm unsure if custom error messages are necessary. Many familiar programs come standard on one distribution but not another. Should we include everything? Linus's oversight is understandable for a brand new distro trying to switch between systems. Distinguishing Linux features from distribution-specific ones takes effort. I believe we should anticipate new users making similar mistakes and respond with patience.
Most distributions include CNF handlers that cover a wide range of executables in their repositories. Adding extra details for commands with preferred versions on certain distros isn't necessarily harmful. I see the effort involved, and it might not always be practical to focus on it. Would closing a PR to improve documentation for a distro you use make sense? It would help avoid leaving community members with unclear guidance indefinitely and make it easier for them to find the right information. This could prevent burnout in smaller communities.
I wouldn't close that PR. I haven't really worked on Linux distribution PRs before, so my views here aren't very strong. But I don’t think it’s worth much effort. Linux, particularly desktop versions, depends a lot on its community. In the server sector, new users are often assisted by colleagues or classmates. For desktop users, they usually count on other passionate Linux users for support, or their local LUG back in the days before March 2020. From my experience with first-time users, they tend not to read or fully understand error messages from bash. They get upset and even looking at man pages for pacman probably wouldn’t help. Since bash error handling is fine for more experienced folks, and new users are likely to feel anxious and ask for help, I’m doubtful this effort would be worthwhile. For a long time, I’ve dealt with similar questions from newcomers about apt versus apt-get, fixing editor mistakes after accidental selections, adding themselves to non-existent groups, and many other common issues. It’s just part of community life and completely acceptable. Especially since many beginner questions let you assist someone facing a problem right now, helping prevent future issues.