I’m going to give you the benefit of the doubt and assume what you said was simply confusing, but not wrong.

So just to be clear if your raid array fails, and you’re using software raid, you can plug all of the disks into a new machine and use it there. But you can’t just take a single disk out of a raid 5 array, for example, and plug it in and use it as a normal USB hard drive that just had some of the files on it, or something. Even if you built the array using soft-raid.

I get what you’re saying, but I think the issue with optional memory safety features is that it’s hard to be sure you’re using it in all the places and hard to maintain that when someone can add a new allocation in the future, etc. It’s certainly doable, and maybe some static analysis tools out there can prove it’s all okay.

Whereas with Rust, it’s built from the ground up to prove exactly that, plus other things like no memory being shared between threads by accident etc. Rust makes it difficult and obvious to do the wrong thing, rather than that being the default.

You should look up IPFS! It’s trying to be kinda like that.

It’ll always be slower than a CDN, though, partly because CDNs pay big money to be that fast, but also anything p2p is always going to have some overhead while the swarm tries to find something. It’s just a more complicated problem that necessarily has more layers.

But that doesn’t mean it’s not possible for it to be “fast enough”

Knowing the folks at IA I’m sure they would love a backup. They would love a community. I’m sure they don’t want to be the only ones doing this. But dang, they’ve got like 99 Petabytes of data. I don’t know about you, but my NAS doesn’t have that laying around…

I’m not the person you’re replying to, and I don’t have any videos, but I do love dumping explanation on people! So here’s some terms:

File System: This is the way data is laid out in terms of actual bytes on the drive. It’s in charge of things like where to look to find the name of this file, or how to “last modified” date is stored, or how do I find out which files are in this folder. NTFS is a filesystem, whereas ext4 is probably the file system your linux machine is using. FAT is the older Windows one that’s still used on, like, SD Cards and stuff. That having been said File System is sometimes also used to refer to the particular data on a particular partition of a disk, like “the filesystem will allow” which really means the data on your NTFS partition. Filesystem is often abbreviated “fs”, and is in fact the “FS” of “NTFS”

Mounting: In unix systems, such as Linux, file systems are “mounted” to a place in the folder hierarchy. Everything in unix lives somewhere under the “root” folder /, so mounting is basically saying “Okay, you want to see the files in this filesystem. Where should I put them?”, and if you say /home/user/stuff then the file “one.txt” at the root of your filesystem will now be visible at /home/user/stuff/one.txt", and if you mounted it at /mnt/things it would be /mnt/things/one.txt. The term mount is used like “attach” to mean “where do you want me to hang this new directory hierarchy on your existing one”.

fstab: There are a few ways to mount things in modern linux. The classic is the mount command which looks something like mount /dev/sda1 /home/user/stuff which would take the device with the name /dev/sda1 and mounts it to the given path. Devices in linux usually live in /dev, and in this case are often given names like sda1 to represent the first hard drive (a), and the first partition of that drive (1). But, there are other ways! You can also click on the partition in your file browser and it will mount the disk for you, often auto-creating a mount path and cleaning it up when you’re done, so you don’t even have to think about it. Another way is fstab, which is a kind of config file that controls mounting devices. In here you can give default options for how you want drives to be mounted, and can even specify that you’d like some devices to be automatically mounted by the system on startup. This is actually an important part of how unix systems start, and how the root filesystem and other important ones get going. If you wanted your NTFS drive to always be available at a permanent location, you would edit this file to set that up. If this is something you wanted only periodically, then just clicking may be fine.

Permissions: Virtually all unix filesystems store the permissions of files and directories as a “user” and “group” that owns the files, and then a set of whether or not the owner can “read” “write” and “execute” the file, whether other members of the group can, and then whether everyone else can. If two people were on the same computer, these would allow a person to be able to see their own documents, but not see the documents by other users. Or maybe they can see them but can’t make changes. And it also prevents random users of a system from changing important system configuration, when those config files are owned by the administrative user (called root by convention). Some config files will be read-only to normal users, and some contain secrets and so are permissioned so normal users can’t even see them. But! NFTS doesn’t follow these same conventions, so when mounting an NTFS drive on unix the driver has to produce a set of permissions that are unix-compatible, but it doesn’t have anything to work off on the disk. So the person above was saying by default it assumes the safest option is to make all files owned by the user root, and so if the permissions are the only the owner can write the files, and the owner is root, this will mean it’s effectively “read-only” to you. The terms uid and gid stand for “user ID” and “group ID”, which are the numbers that represent a user in the data. User names are basically a convenience that allows us to give a name to a uid, but it’s more efficient to store one number everywhere on disk for owner rather than a name.

So putting it all together, what they’re suggesting is that you can use the /etc/fstab file, which has a very particular format, to specify default options when mounting your drive. These options include setting the uid option and gid option to your user’s uid and gid, so that when the filesystem is mounted, it will appear that all the files are owned by you, so you’ll have full permissions on them. They’ve assumed your uid and gid will be 1000 because that’s a common convention, but if you’re comfortable you can run the id command on the command line to output your actual uid and gid (you can ignore all the other groups your user is in for now)

They also mentioned that when mounting you can specify if you want to mount the filesystem as “read-only” or “read-write”, etc. If you mount the whole filesystem read-only, then the write permissions stored on the individual files are ignored, basically. So if you were mounting with a command, or through fstab, you should make sure the rw option is present to clarify that you’re looking for “read write” permissions on your mount.

That having been said, it’s possible none of that is relevant to you if you’re mounting the fs by just clicking in your file browser. One way to tell is if you right-click on some file you aren’t allowed to edit and look at the properties there should be a Permissions tab thing. And it will list the owner of the file and what access you have. If those permissions are already set to be owned by you, then this uid thing is already taken care of for you by the file browser. In that case it might be something more fundamental to the NTFS filesystem, like the locks other people are talking about.

So those are some words and their meanings! Probably more than you wanted to know, but that’s okay. I liked typing it

I think I may have contracted some kind of brain worm, because the other day I needed to do some photo manipulation and couldn’t get krita to do what I wanted, but I went into gimp and just knocked it out. I’ve hated gimp for years, but I guess I’ve used it enough that I’ve figured out how it works… and now I don’t hate it anymore…

I think I may need help.

Oh, but I always use it in single window mode ever since that came out. The multiple windows floating panel thing drove me nuts!

Some tips:

• Unless the code is very small, or your feature is very big, try to put blinders on, and focus only on the code you absolutely need to to get your feature built. Use search tools to comb through the code to find the relevant methods while reading as little surrounding code as possible, tweak those methods to be different, and call that a first draft. If the maintainer wants the code refactored or differently arranged, they can help with that as part of the review process
• Being unable to build sucks, it really does. But if the software is released for your platform, it means someone out there is able to build it. And these days that someone is often an automated build tool that runs per release. See if you can figure out how this tool works. What build steps it uses, what environment it runs in, etc. If you can’t figure that out, try contacting the person who releases the builds
• If the software is in apt (if you’re on a Debian-based system), you can use apt build-dep, apt source, and debuild to try and recreate the native apt build process. These tools will give you the source that built the system package, and its dependencies, and allow you to build a deb yourself out of it. Test the build to make sure it’s working as-is. If it is, and if the software’s dependencies haven’t changed too much, you can even use apt to fetch the old version that’s in the repos, update the code to reflect the upstream release, and then test the build there to see if it still builds. If so, now you have something you can start working off.
• If you aren’t on an apt system, but do have a package manager, I assume there’s an equivalent to the workflow mentioned above
• If your change is subtle enough that you think it’s pretty low-risk, you could just edit the code even though you can’t build it. This might be sufficient for bug-fixes where you just need to check something is greater than zero, or features where you pass a true instead of a false in certain conditions or something. You should probably mention this in your PR / MR / Patch so the reviewer knows to test building it before merging.
• This one is a bit wild, but let’s say you’re on a Mac or Windows machine, and the build instructions only work for Linux. You can just run a virtual machine that’s got Ubuntu or something running on it, and use it as your build environment. These days you can probably be in a simpler situation with Docker or something more lightweight, but as a worst-case scenario, a full virtual machine is there for you if you need it
• And finally, if the tool isn’t a crazy popular or busy tool, it’s possible the maintainer or other people in the community are more approachable than you think. If they are looking for contributions, then getting a willing contributor’s build environment setup is a benefit to the project. Improving their build docs helps not just you, but potential future contributors as well. A project will usually be more helpful towards someone who says “I’m trying to build this feature, but I’m running into trouble” compared to someone saying “why doesn’t your tool do X”. You may need to be a bit patient, they’re probably doing this on volunteer hours, but they might be happy to help you get your stuff sorted out

Good luck out there, and try not to be discouraged!