I’m not a fan of having two definitions for “lint” in the tech world. Unnecessary ambiguity.

This should just work if your Android device’s USB mode is set to Mass Storage, no extra software needed on the PC. It’ll just show up like a thumb drive.

Note: Gaming performance is purely based on money spent. There’s no fundamental reason windows would have better gaming performance, it’s just that there is more money being paid to engineers and vendors to support DirectX and related tooling.

Then there’s the self-fulfilling aspect that, windows has the largest marketshare, so devs are going to spend the most money targeting it, so that they can get the most money in return, which means more people will use it, which leads to the high marketshare.

The ONLY reason Linux use is seeing the few percent blip in gaming is because Valve has dumped truckloads of cash into making it viable.

The better comparison is that distros are the operating systems (like “windows”, “macos”, and “android”), while “linux” is the kernel under the hood that end users likely never interact with (like “NT”, “XNU”, and…“linux”).

A distro represents an intended user experience. If you want a distro that has an intended user experience that is similar to windows, go with Mint or OpenSUSE. If your desired experience is like the SteamDeck, install bazzite (with an AMD GPU ideally). If that’s all you care to know, then that’s all you need to know; go use your new system how you would any other.

But if you want to dig deeper, yeah, the fact that all the distros are based on linux (and more importantly, are posix compatible) means that a lot of the software is portable across distros. But that doesn’t mean your experience on all distros will be the same. Different distros organize their filesystems differently, they might ship with different versions of core utilities based on the stability testing they’ve done, and they likely offer varying means of installing and managing new packages.

The tl;dr is, go use one distro, and then later try doing the same stuff in a different distro, and inevitably at some point you’ll go “oh, this didn’t work exactly how I expected because the other distro I’m used to handles this differently”. That’s the difference.

The performance is relative to the user. Could it be that you’re a god damned genius? :/

Man, we’re gonna have to change the name of the AUR because bad journalists keep thinking this has something to do with the distro.

“Arch Linux Users who go out of their way to install RAT at risk of installing RAT”

Ah, I think you mean non-free or just non-open source.

Something being “native” means it’s compiled for your specific hardware, ex. an x86-64 binary running on an x86-64 CPU. An example of non-native is an x86 binary being emulated on an ARM CPU, Java bytecode running on a JVM, or Python code running in an interpreter.

But your drivers are all definitely all running natively on your hardware.

ofc amd drivers should be native so that shouldn’t be my issue

I’m curious, what’s an example of non-native drivers?

Driver bugs exist, it could definitely be a hole in someone’s testing. I would assume the number of people running PopOS (and whatever build of mesa their release is on) with that specific GPU is pretty low. Maybe try the amdgpu-pro driver and see if the issues go away (or change, heh)? Not sure what the recommended way of installing it on PopOS/Ubuntu/Debian is.

We’re talking about an eink tablet. I assume none of them are running X, so there’s no “desktop” involved here. I have a remarkable 2 which runs Linux. I can ssh into it to rsync files to it, back things up, and make customizations. There’s no package manager, it seems to be an embedded system. It has python, so i’ve written some python scripts to do custom operations. Everything i do on my remarkable 2 is stuff I would expect to also be able to do on an android based tablet.

Not to nitpick, but Android is Linux based. So I would expect to be able to do all the same stuff that I can on a Linux based one.

Edit: can anyone explain why the downvote? Any concern about android ecosystem vs linux ecosystem should be moot, and I think that’s useful context…

Why are they called “patched” and “fix” and who is installing them?

It’s meant to be a convenience for people who know what they’re doing.

You can’t even install from AUR using pacman directly. You either need to makepkg them manually, or use an extra AUR compatible package manager like yay. It’s made as clear as possible to arch users that the AUR is not vetted in any way, it’s just for convenience.

Cool, welcome! I assume you’re aware that it won’t be all sunshine and rainbows from day 1, but give it time and leverage the community to solve any issues you run into. Effective bug reports and knowledge sharing make the experience better for everyone.

To me it’s worth having control over my hardware, and an OS that’s designed to work for me and not some corpo against me.

Dual boot? Keep like 200GB for windows, and the rest mint. If you need windows for something, boot over. But otherwise, I legit feel more worried when windows has access to my data.

Side note: If part of your prep for an OS wipe involves making copies of critical information, I recommend re-evaluating your backup strategy. You should be able to lose any device at any time without warning, and not lose any data.

iirc it was using Method 3 on this guide (but my efi path looks different).

Edit: oh, I also definitely used bcdedit /copy to clone the windows entry, and then edited the clone.

Unfortunately, the windows bootloader issues are also ingrained in UEFI for many motherboards. Every few days I start my PC up and it has decided my grub entry is garbage and does me the favor of removing it and defaulting back to the windows bootloader.

I’ve worked around this by adding a bootcfg entry to the windows bootloader that points at grub. Now any time this happens, I pick the grub entry from the windows bootloader, my PC reboots, and now it’ll keep defaulting to grub again until the next time it decides to wipe it.

I’m responding to the literal words you said that were inaccurate. Cheers.

It is not standard workflow in git to change the commit history for a branch on the remote. You have to use --force, and the next time someone pulls they also have to --force their any local tracking branch to follow the remote. Every git guide on the internet warns against pushing a rebase for this reason.

Locally you can do whatever. I’m not familiar with Mercurial, but I assume it must work the same as git: I can do whatever I want locally, and only what I push matters. And when I’m doing stupid stuff locally as I organize my changes, rebase is handy.