I think it’s great! If we’re Mr and Mrs MyLastName we know they know me and assumed she was the same. If it’s Mr and Mrs HerLastName it means they know us through her, and assumed she must have gotten the name from me! It’s like putting the name of the company in the email you’re giving the email to, it tracks the source. At least that’s the game we play, because it mostly doesn’t matter to us.
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:
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.Good luck out there, and try not to be discouraged!
Similar to other people, I think you should own it. Try to think of it not as “I betrayed my character” but rather “my character gave in to temptation and regrets it but has to live with the consequences”, then use that. Play the character as though they are unhappy with the changes, they regret it, but they must soldier on.
People aren’t all perfect archetypes, and characters can have flaws and nuances. And the best part is, if your character up until now had no reason to make the choice you made, maybe it’s time for an out of game flashback. Work backwards… what thing could have happened in their backstory that would explain why they made this seemingly incongruous choice? Why did this tempt them when so many other things did not, and why does this cause them so much shame now. That kind of stuff.
Or don’t! Just some suggestions, since it sounds like you’ve got nothing to lose, may as well try some character development!
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.