This is the actually the thing same as Windows - in Linux you’ve got the which command, and it’s equivalent is where in Windows. Both do the same thing - find out where a program lives.
OP meant a “program” in this context. Both Linux and Windows have specific paths where programs typically lives. For example, in Windows, if you type “notepad” in a command prompt or the ‘Run’ dialog, it’ll search for it in known system paths such as C:Windows, C:Windowssystem32 etc. These paths are declared in the PATH environment variable - which you may have encountered when certain applications try to (or ask you to) add their program folder to the PATH, such as say Java or Python. If a program is added to the PATH, typing ‘java’ or ‘python’ from anywhere will automatically launch it, so you don’t need to specify the full path or the program.
Now whilst this is convenient, sometimes it can cause unwanted issues. For example, say you installed some other program that uses a specific version of Java or Python, and it installed that version in your system, and added that folder to the PATH - now when you type java or python in a command prompt, you wouldn’t know which version you’re executing. This is what OP meant by a program living in multiple places. As you can imagine, this can now cause issues, and can even break some scripts expecting a particular version of Java/Python etc and some other version is being picked up. This is where the where command in Windows comes in handy, as it tells you where exactly that program is located. And it’s Linux equivalent is which.
So at least in this department, the behavior of Windows and Linux is virtually identical. :)
But if something isn’t available via the package manager, I could still find it online and download and install it, but it might cause issues because it hasn’t been verified by the people who maintain the distro’s package manager accessible repositories.
Correct. The usual issues that you’d find is missing libraries or other package dependencies, because the versions/packages on your OS may not match what the developer complied their generic release package with. Which is why you normally don’t download random apps from the web like you’d do on Windows, becuse there’s no guarantee that it’d work on your distro (not to mention the security concerns).
Or I could still install it with flatpaks or snaps and something something container and it should still work? Or might cause compatibility issues?
Correct, Flatpak/Snap was invented for this very reason, to solve the library mismatch and dependency issues you might get. Flatpak/Snap works by bundling all the necessary dependencies a program might need, so it doesn’t matter what your OS has. There are some issues with Flatpaks/Snaps, but these are rare and usually they come about due to the sandboxing (Flatpak/Snaps typically don’t have full system access, but “just enough” to get things working. You can manually configure the permissions though if you need to give an app more/specific permissions).
AUR has more packages that have been verified for arch than OpenSUSE has with Yast?
“packaged”, not “verified”, but yes being packaged for a particular distro usually implies that it works, but that’s not always the case. Btw, YaST is just a system config tool, not a repo. OpenSUSE’s default repos do indeed have fewer packages compared to AUR, but that’s an unfair comparison since the AUR isn’t even enabled by default on Arch, it’s something you’ll manually need to enable and even get a third-party package manager like yay/paru etc to access it. OpenSUSE also has third-party repos like Packman, and even an online Software Portal that can be used to search for and install package from several official and unofficial repos. So technically speaking you could probably find everything you need on OpenSUSE (it’s hard to get an exact package count to compare), but I guess it’s not as easy/convenient as simply using the AUR on Arch.
If you’re a beginner then don’t worry about the encryption. Unless you’re hiding from some three-letter agency or being targeted by hackers or something, LUKS1 encryption is more than good enough (for an average home user).
But just so you’re aware, whilst it’s trivial to convert to LUKS2 using cryptsetup convert, you’ll need to first switch your bootloader to systemd-boot from GRUB, and that may not be a trivial process as there’re multiple variables involved - is your ESP big enough, have you mounted your ESP to /boot, whether you’re using secure boot or not, whether you’re dual-booting or not etc. Plus you’ll also need to manually create a bootloader config file that’s specific to your system, and maybe even add a line to load a CPU microcode file if you’re on Intel… there’s a lot of things to consider here.
Honestly, I wouldn’t recommend EndeavorOS to you as a newbie, because it’s basically Arch, but by making the installation easy, you’re skipping all the knowledge you’d get of your system and how it works. And when it comes to situations like you’re in, you reach a roadblock because you took the easy path.
If you’re really interested in Arch then I’d recommend wiping your system and install Arch manually, the Arch way.
No such issues here with my XM5, been using mine for over an year. Are your devices on at least Bluetooth v5.2? All of mine are either 5.2 or 5.3 and I’ve not experienced any issues. I use my headphones with Android, Linux, Windows 10 and macOS. Even multipoint works fine.
As for the head comfort, you could get a headband cover/cushion, such as the ones made by Geekria.
As KDE F38 user, this is a super boring release. Nothing noteworthy for us to look forward to except LibreOffice 7.6 - which you can get via Flatpak anyways. I was hoping the new DNF 5 would make the cut, but guess it’s still not ready yet. :(
Guess will have to hold out my excitement until F40 for Plasma 6 and DNF 5 (hopefully).
At least KDE is planning to introduce customisable trackpad gestures next year, with Plasma 6.0. Not sure if that would include palm rejection though or the other stuff.
This is pretty much what I did, although it was coincidental. Felt bad for my boss because he fought pretty hard to get a meaty pay rise for me, and then a month later I quit.
Audio works. Not sure how though, –unshare-devsys is supposed to not share the hosts devices, but I guess audio devices are an exception.
The full isolation flags are:
<span style="color:#323232;">--unshare-devsys: do not share host devices and sysfs dirs from host
</span><span style="color:#323232;">--unshare-ipc: do not share ipc namespace with host
</span><span style="color:#323232;">--unshare-netns: do not share the net namespace with host
</span><span style="color:#323232;">--unshare-process: do not share process namespace with host
</span><span style="color:#323232;">--unshare-all: activate all the unshare flags below
</span>
If you’re after fluid yet lightweight animations then you should definitely check out Wayfire. Yes it’s Wayland and a WM not a DE, but you can get a distro/spin with Wayfire and all the stuff you need for a DE all pre-installed and pre-configured. Wayblue (based on Fedora uBlue) is one such option you can try. And because Wayblue is immutable and has reliable atomic updates, it’d make a great option for you as a school-goer as stuff rarely breaks and you can always rollback to a previous image before the update.
I have the same chip in my mini PC (7840HS) and it works fine for me on Linux, but then again I use Arch + Wayland. Maybe you could try a couple of different distros on a Live USB or something (you could create one using Ventoy and then put a few different ISOs on there to play around with). I’d recommend choosing a distro with a recent kernel and updated graphics stack, for eg Arch or Bazzite and see how it goes.
But the artefacts you describe sound more like a hardware glitch to me. Have you tried running the Lenovo hardware diagnostics from the system boot menu? (IIRC you need to press F12 or something to get the menu and then choose the diagnostics mode).
I’ve only started using yadm recently so I may not be able to elaborate in detail, but for me the main draw for using yadm (as opposed to Ansible, which I use at work) is the simplicity. It’s basically just a bash script that uses git, so there’s no dependencies besides git and tools installed on most Unix systems. Ansible felt like overkill for what I needed, ie just something to manage and sync my dotfiles.
Also, maybe it’s personal bias, but I really hate installing/using Python-based programs - they often tend to go wild with their dependencies and eventually break. I recall trying to install Ansible on a Raspberry Pi at some point (via pip) and it failed because one of the dependencies couldn’t be compiled for whatever reason. I gave up after trying to fix it for a while, and dropped the idea. I’ve had similar experiences with other large Python projects, there’s always some drama. Why is why I prefer compiled binaries or simple shell scripts like yadm.
I’ve no issues using Ansible at work though. We use it on RHEL so it’s quite stable and doesn’t have the dependency issues you’d get on a bleeding-edge, ever-changing, end-user system. Plus it really shines at the Infrastructure as Code stuff so we use it to automate everything from networking gear to VMs. But I feel it’s overkill for something as simple as syncing a bunch of text files.