Honestly, the wave of system integrator and people making SFF build to compete with steam machine already puts steam at the advantage. They already released SteamOS for every other desktop, that means system integrator and pre built can also make SFF with console like experience

Do you even read the premise? The premise is that if they are subsidized. So imagine the same spec for 500-600

Is it? Or is that an advantage for office? Where people only need a browser, ms office suite, and probably adobe pdf. Heck, I bet software development work can be done there. Some light CAD (emphasis on light), and maybe even some graphic design work (not video editing tho). Office also cares about efficiency and with the right consumer it is appealing to have 150-200W power sip compared to 200-350W when you install 50-100s of them.

Read. The issue is if they are subsidized

The problem with valve subsidizing it, is that it will make it an attractive choice to those that are not buying it for gaming on steam. After all, it is still just a pc. You can literally do some real work there unlike a console. It may even fall into a company that provides pc leasing service if they are cheaper than some dell or HP or any other mid spec pre-built.

Sure reviewing changes is easy. But the problem is that it is still a review. You need to have an understanding of what exactly is being done and to account for any oddities that may or may not be because of the quirks of upstream. That’s why I mentioned that AUR trust models should be made like pacman for most helper. We trust the maintainer of Arch so why can’t we trust other people too? Take PPA, the trust model is exactly that. You trust the maintainer. At the very least make it an option that you can choose on first run

All of that wouldn’t have any effect if the aur helper mimics the model of pacman. Trust the maintainer, not the build script. By requiring users to review PKGBUILD every time it changes, it encourages laziness. But by requiring the review only once then trusting the maintainer, it helps a lot because the only way an attack can be done is directly attacking infrastructure (pushing malicious script bypassing the auth) or hacking the account (author turning malicious). Both of those are hard with a properly configured system or not worth it because it requires a long game (like those of xz attack)

Adding stuff is easier than patching existing implementations is probably the reason why. Because up until this point, the webserver can just ignore the GET body request but if the client starts sending with body then who knows what bug might surface that turns into security vulnerability.

People wanting to use AUR helper, you’re better off using aurutils on aurto than yay or paru. Aurto, even with auto update already remove packages when the maintainer changes because aurto trust models was always to check the maintainer first and not the package itself

https://github.com/alexheretic/aurto

There’s a reason why we already called it orphaned. The flag already exists. The AUR helper that auto updates stuff is the problem