SEA market is not a good one for high end stuff. Until they can get big enough to make budget level THEN they may get into Indonesia officially

In sampling and statistics, I’m pretty sure there are terms for that. To account for the fact that not 100% of the population are being sampled. Hmmm, I wonder what that term is.

Damn, what’s the movie name again? With Tom Cruise cloned and all?

Edit: It was oblivion

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)

Yes it is a variant but also it’s more general than that. If you sold the same item with a different number of pcs in a pack (even if just a plastic packing), it also gets SKU. In general you can’t break SKU into smaller units without making a different SKU.

So if you sell socks in 1, 3, and 5 pairs, all get their own SKU even if every pair of socks in the bundle are the same kind. That means if someone wants to order 1 pcs but you only have SKU for 3 in your system, they can’t. Even if the item is there physically. Not unless you remove the SKU of the 3 bundle and add 3 of the 1 (which requires the buyer to communicate it and the seller to jump a bunch of hoops on their system)

https://en.wikipedia.org/wiki/Stock_keeping_unit

SKU is stock keeping unit. So not really about variant pf a product but every unique sellable items should have it’s own SKU so you don’t accidentally sell 5 of things with one color while only have 3 in stock.

Every *-git package also fetch it from the repo. The apt analogy is someone haven’t been maintaining the nixpkg and then it gets adopted by someone else. Now that someone else change the build script to be malware. So it is no fault of the upstream

I know where you’re coming from when you say they are different. But I disagree on that because at the end of the day you’re still trusting other people would not act maliciously or get their account compromised. The selection process doesn’t make it any more special as demonstrated by xz in my example.

Anyone can be an AUR submitter and maintainer. Act in good faith and never become an Arch maintainer. Someone can be an Arch maintainer and be good for a few years then something happened and their account got hacked or bad blood made them act rashly.

That’s precisely what I mean when I equate AUR maintainer to the distro maintainer. To the package management system, they are both trusted. Not in the sense of how special they are or how strongly you can trust one but not the other.

Yes, and that is no different than distro maintainer that maintains the infrastructure and package. Anyone can volunteer. That’s how xz is compromised. The point is that aurto trust models mimic those of other package managers. Trusting the authors implicitly trust the code. The only other special things from distro maintainer is their PGP signatures are required to perform release on the main repo. This is better because as I stated earlier, reviewing PKGBUILDS would encourage people to just skip it. Not everyone has the time for that. But when a maintainer changes? Aurto removes the package for you to perform that first trust again on the new maintainer. This is no different than if you update the arch keyring just more manual

Well, it is just like a distro maintainer account anyway. If the maintainer account is compromised then gg for the whole distro. That’s what happens with other supply chain attacks as well and yes, I do think we need a way to fix that without compromising on ease of usability

Edit: Sorry I realize my rambling didn’t answer your question. My suggestion is to not use aura. I do not see anywhere on their repo about their trust model or if they just do it like yay/paru. This is also why I recommend aurto and not aurutils. People would just skip the diff with aurutils.

The thing is, aurto is not the helper. The helper is aurutils. aurto is just the local repo manager that adds timer to auto-update and some QoL features. But to add packages to that local repo, you need to add the maintainer to the trust list. That means the current attack of adopting orphaned / unmaintaned packages is moot. The maintainer change means the package are kicked out and not tracked anymore by aurto. You can still re-add them after you’ve confirmed that they’re safe.

That being said, aurto do have issue. They trust the PKGBUILD of the author/maintainer so if the maintainer got hacked or gone rogue, it will not protect you. Same as with every other package manager in that case.

Yeah, use and promote aurto instead. They require you to trust the maintainer and would remove the package from the local repo if the maintainer is changed

Thanks!

It is useful because you don’t need to migrate the fs if you need to expand later