Check out bamboo pillows and pillow cases, they have natural hypoallergenic properties and it might suit you better. Or you could just get a bamboo pillow protector + pillow case, in case you don't want to change your whole pillow out.
I used OneDrive, and especially the file on-demand (all files on server visible in explorer but only downloaded when needed) feature a lot
You can continue to use OneDrive. I use the OneDriver client and it works really well - your drive appears just like a local drive, but files only get downloaded when you try to access them. Once downloaded, it gets cached locally and is available offline, and is kept in sync automatically. Other cloud providers should have similar FUSE clients available.
What are best practices for managing apps?
Best practice is to stick to packages provided by your distro's repos. Flatpak should be your second option if you can't find your app there, and AppImages should be your third option (since Flatpaks are superior as they can share dependencies, unlike AppImages). Avoid Snap. In fact, avoid any distros that even use Snap (*buntu). Also, if you're on a Debian/Ububtu based distro, avoid adding PPAs (thirdparty user repositories) as far as possible, as these can cause dependency issues and may cause pain when you upgrade your distro.
Is there a GUI (I know) way to see all applications
That should be provided by your distro - Gnome-based ones have "Software" and KDE-based ones have "Discover".
Since you're on Linux, it's just a matter of installing the right packages from your distros package manager. Lots of articles on the Web, just google your app + "ROCm". Main thing you gotta keep in mind is the version dependencies, since ROCm 6.0/6.1 was released recently, some programs may not yet have been updated for it. So if your distro packages the most recent version, your app might not yet support it.
This is why many ML apps also come as a Docker image with specific versions of libraries bundled with them - so that could be an easier option for you, instead of manually hunting around for various package dependencies.
Also, chances are that your app may not even know/care about ROCm, if it just uses a library like PyTorch / TensorFlow etc. So just check it's requirements first.
As for AMD vs nVidia in general, there are a few places mainly where they lagged behind: RTX, compute and super sampling.
For RTX, there has been improvements in performance with the RDNA3 cards, but it does lag behind by a generation. For instance, the latest 7900 XTX's RTX performance is equivalent to the 3080.
Compute is catching up as I mentioned earlier, and in some cases the performance may even match nVidia. This is very application/library specific though, so you'll need to look it up.
Super Sampling is a bit of a weird one. AMD has FSR and it does a good job in general. In some cases, it may even perform better since it uses much simpler calculations, as opposed to nVidia's deep learning technique. And AMD's FSR method can be used with any card in fact, as long as the game supports it. And therein lies the catch, only something like 1/3rd of the games out there support it, and even fewer games support the latest FSR 3. But there are mods out there which can enable FSR (check Nexus Mods) that you might be able to use. In any case, FSR/DLSS isn't a critical thing, unless you're gaming on a 4K+ monitor.
You can check out Tom's Hardware GPU Hierarchy for the exact numbers - scroll down halfway to read about the RTX and FSR situation.
So yes, AMD does lag behind in nVidia but whether this impacts you really depends on your needs and use cases. If you're a Linux user though, getting an AMD is a no-brainer - it just works so much better, as in, no need to deal with proprietary driver headaches, no update woes, excellent Wayland support etc.
In any case, ZLUDA is really just a stop-gap arrangement so I don't see it being an issue either way - with more and more projects supporting AMD cards, it won't be needed at all in the near future.
It's not "optimistic", it's actually happening. Don't forget that GPU compute is a pretty vast field, and not every field/application has a hard-coded dependency on CUDA/nVidia.
For instance, both TensorFlow and PyTorch work fine with ROCm 6.0+ now, and this enables a lot of ML tasks such as running LLMs like Llama2. Stable Diffusion also works fine - I've tested 2.1 a while back and performance has been great on my Arch + 7800 XT setup. There's plenty more such examples where AMD is already a viable option. And don't forget ZLUDA too, which is being continuing to be improved.
I mean, look at this benchmark from Feb, that's not bad at all:
And ZLUDA has had many improvements since then, so this will only get better.
Of course, whether all this makes an actual dent in nVidia compute market share is a completely different story (thanks to enterprise $$$ + existing hw that's already out there), but the point is, at least for many people/projects - ROCm is already a viable alternative to CUDA for many scenarios. And this will only improve with time. Just within the last 6 months for instance there have been VAST improvements in both ROCm (like the 6.0 release) and compatibility with major projects (like PyTorch). 6.1 was released only a few weeks ago with improved SD performance, a new video decode component (rocDecode), much faster matrix calculations with the new EigenSolver etc. It's a very exiting space to be in to be honest.
So you'd have to be blind to not notice these rapid changes that's really happening. And yes, right now it's still very, very early days for AMD and they've got a lot of catching up to do, and there's a lot of scope for improvement too. But it's happening for sure, AMD + the community isn't sitting idle.
The best option is to just support the developer/project by the method they prefer the most (ko-fi/patreon/crypto/beer/t-shirts etc).
If the project doesn't accept any donations but accepts code contributions instead (or you want to develop something that doesn't exist), you can directly hire a freelancer to work on what you want, from sites like freelancer.com.
Hmm, so I've had a look and it seems like Xournal++ only supports x86_64. Which means that if you get the Snapdragon version, you'll need run it using an x86 emulator like FEXEmu or Box64, and this will affect the performance and may also introduce compatibility issues. So you'll need to do your own research and find out if someone's managed to run it on ARM / Snapdragon 7c, and if there's any issues etc.
You could get the Celeron version instead, but personally I can't recommend a Celeron to anyone in good faith, so you'll have to make your own decision sorry.
Forget Linux for a second. What you need to be aware is that both the variants come with only 4GB soldered-on RAM and eMMC storage. That means, even if you do manage to get Linux going on them, it's going to be super slow for any sort of practical Web/GUI needs. 4GB RAM is barely enough to run a browser these days, and if you tack on a full-fledged DE and multitasking with other apps, you'll be pushing memory pages to the disk (ie, swapping). And when that happens, you'll really feel the slowness. Trust me, you don't want to be swapping to eMMC - that's super old tech, something like 3x slower than UFS, which in turn a LOT slower than m.2 NVMe (the current standard used in "proper" laptops/convertibles).
Also, consider this for perspective - even budget smartphones these days come with at least 6GB RAM and UFS storage. So this laptop/convertible - a device meant for productivity - is a complete ripoff.
If money is an issue, then just buy a used laptop (from eBay, or whatever you guys use there). If you're aiming for good Linux compatibility then ThinkPads are a safe bet. But since you're after a Surface-like device, then you could just get any older Surface device. Why settle for an imitation when you can get the real thing? In any case, most older x86 laptops from mainstream brands should work fine in Linux in general, just do a google for it to see if there are any quirks or issues.
Regardless of your choice, avoid the Duet 3. 4GB RAM is completely unacceptable for a laptop in 2024.
You won't find any alternatives because Flatpak has won the war. Pretty much everyone (except Canonical) hates Snap and avoids it like the plague, and AppImages have significantly dropped in popularity amongst users due to the rise of Flatpak, and the various advantage it has over AppImages. So you're left with only Flatpak/Flathub basically.
skim has unfortunately been abandoned, there have been no updates in an year, and several old PRs and issues remain untouched. The current recommend fork is two_percent, which is also more faster and memory efficient.
If you're facing the same issue with two_percent as well, you can reach out to the author in this thread, since they haven't yet opened up their issues tab.
Kiwi here, no such issues with my Sync. Is there a particular community where you see these errors mainly (if so, can you link it here)?
Also, when you get those errors, it might be worth accessing that community directly using a local account - and if the images load fine, that would point to a federation issue with your server.
doas is quite popular in the BSD world, and was ported to Linux a few years ago (via the OpenDoas project).
For starters, it's is a lot smaller than sudo - under 2k lines of code vs sudo's 132k - this makes it lot more easier to audit and maintain, and technically less likely to have vulnerabilities.
Another security advantage is that doas doesn't pass on the environment variables by default (you'd have to explicitly declare the ones you want to pass, which you can do so in the config).
The config is also a lot simpler, and doesn't force you to use visudo - which never made sense to me, visudo should've just generated the actual config, instead of checking it after the fact. Kinda like how grubby or grub2-mkconfig works. But no need for that complexity with doas.
Eg, the most basic doas config could just have one line in the file: permit: wheel. Maybe have another line for programs you want to run without a password, like permit nopass dexter cmd pacman.