d3Xt3r

As an Arch user (btw), that's rarely an issue thanks to the AUR and it's vast package pool :) But on the very rare occasion that it's not there on the AUR but available as a deb, I can use a tool called Debtap to convert the .deb to the Arch's .tar.zst package.

For rpm-based distros like Fedora and OpenSUSE etc, there's a similar tool called alien that can convert the .deb to .rpm.

In both instances though, dependencies can be a pain, sometimes you may need to trawl thru the dependencies and convert/install them, before to do the main package.

Ideally though, you'd just compile from source. It used to be a daunting task in the old days, but with modern CPUs and build systems like meson, it's not really a big deal these days. You'd just follow the build instructions on the package's git repo, and usually it's just a simple copy-paste job.

Finally, if these packages are just regular apps (and not system-level packages like themes etc), then there are multiple options these days such as using containers like Distrobox, or installing a Flatpak/Appimage version of that app, if available.

I'm not super familiar with ZFS so I can't elaborate much on those bits, but hardlinks are just pointers to the same inode number (which is a filesystem's internal identifier for every file). The concept of a hardlink is a file-level concept basically. Commands like lsblk, df etc work on a filesystem level - they don't know or care about the individual files/links etc, instead, they work based off the metadata reported directly by the filesystem. So hardlinks or not, it makes no difference to them.

Now this is contrary to how tools like du, ncdu etc work - they work by traversing thru the directories and adding up the actual sizes of the files. du in particular is clever about it - if one or more hardlinks to a file exists in the same folder, then it's smart enough to count it only once. Other file-level programs may or may not take this into account, so you'll have to verify their behavior.

As for move operations, it depends largely on whether the move is within the same filesystem or across filesystems, and the tools or commands used to perform the move.

When a file or directory is moved within the same filesystem, it generally doesn't affect hardlinks in a significant way. The inode remains the same, as do the data blocks on the disk. Only the directory entries pointing to the inode are updated. This means if you move a file that has hardlinks pointing to it within the same filesystem, all the links still point to the same inode, and hence, to the same content. The move operation does not affect the integrity or the accessibility of the hardlinks.

Moving files or directories across different filesystems (including external storage) behaves differently, because each filesystem has its own set of inodes.

• The move operation in this scenario is effectively a copy followed by a delete. The file is copied to the target filesystem, which assigns it a new inode, and then the original file is deleted from the source filesystem.

• If the file had hardlinks within the original filesystem, these links are not copied to the new filesystem. Instead, they remain as separate entities pointing to the now-deleted file's original content (until it's actually deleted). This means that after the move, the hardlinks in the original filesystem still point to the content that was there before the move, but there's no link between these and the newly copied file in the new filesystem.

I believe hardlinks shouldn't affect zfs migrations as well, since it should preserve the inode and object ID information, as per my understanding.

In addition to static linking, you can also load bundled dynamic libraries via RPATH, which is a section in an ELF binary where you can specify a custom library location. Assuming you're using gcc, you could set the LD_RUN_PATH environment variable to specify the folder path containing your libraries. There may be a similar option for other compilers too, because in the end they'd be spitting out an ELF, and RPATH is part of the ELF spec.

BUT I agree with what @[email protected] wrote - this is generally a bad idea. In addition to what they stated, a big issue could be the licensing - the license of your app may not be compatible with the license of the library. For instance, if the library is licensed under the GPL, then you have to ship your app under GPL as well - which you may or may not want. And if you're using several different libraries, then you'll have to verify each of their licenses and ensure that you're not violating or conflicting with any of them.

Another issue is that the libraries you ship with your program may not be optimal for the user's device or use case. For instance, a user may prefer libraries compiled for their particular CPU's microarchitecture for best performance, and by forcing your own libraries, you'd be denying them that. That's why it's best left to the distro/user.

In saying that, you could ship your app as a Flatpak - that way you don't have to worry about the versions of libraries on the user's system or causing conflicts.

The Linux kernel supports reading NTFS but not writing to it.

That's not true. Since kernel 5.15, Linux uses the new NTFS3 driver, which supports both read and write. And performance wise it's much better than the old ntfs-3g FUSE driver, and it's also arguably better in stability too, since at least kernel 6.2.

Personally though, I'd recommend being on 6.8+ if you're going to use NTFS seriously, or at the very least, 6.2 (as 6.2 introduces the mount options windows_names and nocase). @[email protected]

The general answer is to enable the RPM Fusion repos. But that won't automagically install the drivers for you, you'll need to manually identify what's needed and install them accordingly. This guide is a decent starting point: https://www.fosslinux.com/134505/how-to-install-key-drivers-on-your-fedora-system.htm

But also consider simply using a distro/spin that has all the drivers included (or automates the install), such as Nobara, or one of the Fedora Universal Blue distros.

Agreed. @[email protected], I think this would be a great idea - making a weekly megathread for Linux questions, preferably also stickied for visibility.

Waydroid works, but there's three main things you need to get things going to replicate a typical Android device:

• OpenGapps: For GApps/Play Store. You'll also need to register your device to get an Android ID.
• Magisk: Mainly to pass SafetyNet / Play Integrity basic checks.
• libndk / libhoudini: For ARM > x86 translation. libndk works better on AMD.
• Widevine: (optional) L3 DRM for things that need it, eg Netflix

There are some automated scripts that can set this all up. I used this one in the past with some success.

Also, stay away from nVidia. From what I recall, it just doesn't work, or there are other issues like crashes. But if you're serious about Linux in general, then ditching nVidia is generally a good idea.

Finally, games that use anti-cheat can be a hit-or-miss (like Genshin Impact, which crashed when I last tried it). But that's something that you may face on any emulator, I mean, any decent anti-cheat system would detect the usage of emulators.

AIO Launcher - not for everyone, but I prefer function over form. :)

First of all, I'm not the author of the article, so you're barking up the wrong tree.

You're using the unstable channel.

That doesn't matter in the big scheme of things - it doesn't solve the fundamental issue of slow security updates.

You could literally build it on your own, or patch your own change without having to wait - all you have to do is update the SHA256 hash and the tag/commit hash.

Do you seriously expect people to do that every time there's a security update? Especially considering how large the ecosystem is? And what if someone wasn't aware of the issue, do you really expect people to be across every single vulnerability across the hundreds or thousands of OSS projects that may be tied to the packages you've got on your machine?

The rest of your points also assume that the older packages don't have a vulnerability. The point of this post isn't really about the xz backdoor, but to highlight the issue of slow security updates.

If you're not using Nix the way it is intended to be, it is on you. Your over-reliance on Hydra is not the fault of Nix in any way.

Citation needed. I've never seen the Nix developers state that in any official capacity.

I know it's not the same thing, but this kinda reminds me of the old GDI object limit in Windows which had an upper limit of 65,536. If you reached that limit your system would start exhibiting all sorts of weird glitches, including not being able to launch any apps even if you had plenty of free RAM.

No, you're right. There's no organisation options. It's pretty barebones overall, and doesn't look great on large foldables either. Guess there's no reason to switch from my current launcher.

There are lightweight GUI options for that too. For iwd, you can use iwgtk. For VPN, that would depend on your VPN protocol/service. Some providers like Proton have their own client, others can use something like Wireguard Client (as an example) or something similar depending on your VPN setup.