• 1 Post
  • 17 Comments
Joined 2 years ago
cake
Cake day: August 4th, 2023

help-circle
  • Respect.

    I haven’t quit or tried to, but:

    • I do things while I’ve got YouTube on in the background more than I dedicate my attention to it. Writing code, playing a video game, etc.
    • I almost never log in to YouTube. And I clear my cookies at least daily. So I don’t succumb to “the algorithm” very much. I do use NewPipe on my phone for music and such, but again, no algorithm involved. But generally I go specifically to what I want to watch or search specifically for what I want to watch and watch it. I also turn autoplay off.
    • I have published videos on YouTube, but I’m resolved not to any more. Any more videos I might make in the future, I’ll put on PeerTube.

    I have a short list of creators I follow (but without using things like the bell/subscription feature on YouTube). Short enough that I can keep the list in my head. One of those creators I also support on Patreon.

    I guess all that to say, I do hedge my use of YouTube, but quitting isn’t on my radar any time soon.


  • I wonder if there’s a way to prevent people from even knowing that two different votes came from the same user.

    What I outlined above should prevent anyone from knowing two different votes came from the same user… without specifically trying that user’s id on each. That’s what the salt (the comment/post id) is for.



  • TootSweet@lemmy.worldtoOpen Source@lemmy.mlIntroducing Lemvotes
    link
    fedilink
    English
    arrow-up
    12
    arrow-down
    1
    ·
    edit-2
    1 day ago

    Votes should be anonymous.

    I tend to agree, but the fact is that they aren’t anonymous. This tool just exposes the already-existing fact that Lemmy expressly does not guarantee anonymity for votes. The solution isn’t to not for the poster to not publish this tool. Believe me, such tools already exist in private even if none other than this one are published. Publishing this one only democratizes access to that information. (And not entirely, I don’t think. From what I’m seeing on the page, it looks like it still requires an admin account on an instance. Update: Actually, I’m not sure if it requires an admin account or not. Either way, though.) The solution is (if it’s possible) to make Lemmy itself protect voters’ anonymity.

    The reason why instances know who has up/down voted things (rather than only keeping an anonymized “total” for each post/comment) is so it can prevent double-voting.

    Maybe instead of usernames, the instances could store/trade… salted hashes of the usernames where the salt is the title or unique identifier of the post/comment being voted on? It wouldn’t be perfect, but it would allow the instance to figure out whether the currently-viewing or currently-voting user has already voted while also making it harder for anyone else to get that information. About the only way a tool could tell you exhaustively who had voted if that were how things worked that I can think of off hand is to try every username on Lemmy one-by-one until all the votes were accounted for.

    (Of course, malicious instances could still keep track of usernames or unique user ids who up/downvoted, but only on the instance on which the vote was cast. Also, one downside of this approach would be increased CPU usage. How much? Not sure. It might be trivial. Or maybe not. Dunno.)

    And there may be much better ways to do this. I haven’t really thought about it much. I also haven’t checked whether there is an open ticket asking for improved anonymity for votes already.

    (Also, full disclosure, all of the above was written after only an extremely brief skim of the linked page.)

    (One more edit. Something IHawkMike said led me to realize that the scheme I described above would allow instances to manipulate votes by just inventing hashes. Like, grabbing 512 bits of data from /dev/urandom and giving it to other instances as if it was a hash of a username or user id when, in fact, it’s not a hash of anything. Other instances wouldn’t be able to easily tell that it wasn’t the hash of a valid user id. I haven’t thought how to go about solving that yet. Maybe if it occurs to me, I’ll update this post.)










  • Originally posted here, quoted below for convenience:

    Real story.

    I was in my late teens. My parents were dragging me to a tiny, kinda culty church every fuckin’ weekend. Didn’t really have much choice. (Hell, I hadn’t even told anyone yet that I thought Christianity was 100% bullshit.)

    I had a reputation for knowing my stuff about computers. (Because normies – particularly boomer normies like Pastor Dipshit – don’t know the difference between programmers and PC support.)

    So, one Sunday after the service, Pastor Dipshit asks me to look at his computer. His Outlook was giving an error dialog. Something about not being able to find an email on disk. Clicking the “ok” button just resulted immediately in another dialog, and while the error dialog was present you couldn’t interact with the main window, so this rendered Outlook unusable.

    Turns out he’d gone and deleted a bunch of files from the filesystem. Like by navigating from “My Computer” down to the directory where Outlook stored its files. Rather than deleting emails through the Outlook GUI the way one is meant to.

    So, I mused “hmm, I wonder if it’s just giving one error message per email that was affected.” I could see in the window behind the error dialog that the total count of emails in his inbox was only a couple hundred or something.

    So I commenced to clicking as rapidly as I could. Probably about a minute of clicking later, no more error dialogs and Outlook was usable again.

    And everyone marveled at my “genius.”

    I wouldn’t be surprised if he didn’t learn his lesson and continued to delete random files from the filesystem, but he kindof lost what was left of his connection to consensus reality and scared even my culty family away and we quit attending that church not terribly long after that, so I couldn’t say for sure.




  • Ok. Lessee.

    Just to quickly explain first off:

    • A disk is just a big collection of bytes. A 100GB disk has 100 billion(-ish) bytes. Each one has an index. The first byte has index “0”. The second has index “1”. There’s a byte 8,675,309. Each byte has a particular value at any one time. The computer can set the value of any byte to any value. (It could set byte 8,675,309 to 01100001 and later it can reliably be read back from the same index as the same value, until it’s changed to a different value.)
    • A disk can be divided into partitions. Basically you (or rather a tool you use) writes data to a location near the beginning of the disk that says “treat this disk as multiple separate devices. The first starts at byte X and ends at byte Y, the second starts at Y and ends at Z, etc.”
    • When you plug a disk into a Linux computer (on most modern full-featured desktop/laptop Linux systems, though maybe not on, for instance, some embedded systems) a new “file” appears in /dev for the disk along with more files for each of the partitions on the disk. For instance, an external USB hard drive with three partitions might show up as /dev/sda and the partitions as /dev/sda1, /dev/sda2, and /dev/sda3 respectively. (Ok. Technically the things in /dev are only files in some senses. They’re technically “devices”. But they have paths like files do and they can be read from and written to like files.)
    • If you want to, you can read and write to those partitions or to the disk directly as you would read or write any file. You can open it in a text editor, for instance. You might get lots of random-looking broken characters if you do that, and god help you if you try to save over it, but you can. If you read from a disk or partition, it just returns all the bytes in the disk or partition starting from the first (or from whichever index your application asks it to start from.)
    • A “filesystem driver” knows how to interpret the bytes on a partition as files and directories.
    • If you want to know what device in /dev a file lives on and what filesystem driver is used for that device, the mount command just typed into any bash terminal will tell you. It’ll output rows like on type (...). If you read/write a file or list a directory, it’ll pick the entry in the mount output that has the longest that is a prefix of the requested file. The is the “file”(/device) in /dev that corresponds to the parition on which that file is encoded. `` is the name of the filesystem driver. So, for instance, if I have an entry /dev/sdb3 on /mnt/pringles type ext4 (...) and I read a file named /mnt/pringles/apple/unicorn/potato.txt (and if there are no entries in the mount output with longer paths that are still prefixes of the requested file path), the kernel will ask the ext4 filesystem driver to please look at the partition /dev/sdb3 and interpret that partition’s contents as a hierarchical filesystem to find and return the contents of the file at the path apple/unicorn/potato.txt relative to the root of the filesystem encoded on the /dev/sdb3 partition.
    • There are other filesystem drivers that don’t deal with disks. Some like tmpfs store data in RAM only (and RAM isn’t intended to be persistent, so you can’t expect anything in a tmpfs to last reliably through a reset.) Others like procfs don’t look at a disk but make these ephemeral files that basically decide what data to return when read from at the time they’re read from. (Files in procfs filesystems usually expose data about the Linux system. Like, for instance, what processes are currently running.)

    Now, the question of where files should go is… kinda unrelated to the above. Files that are system-wide configuration should go in /etc. Files that are system-wide executables should generally go in /bin, /sbin, /usr/bin, /usr/sbin, and /usr/local/bin. Anything your own user downloads/creates should go in /home/$username. Etc. More specifics of all this here.

    It can be useful to make decisions regarding what disk/partition a particular directory like /home lives on. But whether /home is on the same partition with /etc and /bin and /var etc or whether it’s on a different partition (and both of these options are quite common), your users’ files should go somewhere in /home.

    To elucidate a little more, if you decide to put your /home on the same partition as /bin and /etc and /var and such, you’ll have an entry in your mount output like /dev/sda2 on / type ext4 but nothing with a `` of /home. If you decide to put /home on a separate partition, you’ll have your /dev/sda2 on / type ext4 entry plus another entry like /dev/sda3 on /home type ext4.

    So which partition does a file go on when you write a file to /home/keenflame/document.txt? Well, in the first case, it’d be on the partition Linux calls /dev/sda2. In the second case it would be written to the partition that Linux calls /dev/sda3.


  • I just meant with the C: comment that OP shouldn’t expect it to still be called C: after he’s wiped Windows and is running Linux.

    As for the oversimplification comment:

    First off, C: (or D:, E: etc) doesn’t refer to a disk in Windows. It refers to a partition. So it’s entirely possible (and not terribly uncommon) to have a single disk with both a C: and a D: on it.

    It’s very typical for a Linux installation process to (by default, if you don’t tell it to do something else) make separate partitions on a single disk for / and /home. (Plus there’s usually an extra EFI boot partition on most modern desktop/laptop systems. And a swap partition.) In such a case, you couldn’t really describe where “the disk” (that was formerly called C: on Windows) was mounted in the mindset of conflating “partition” with “disk”. What was previously “the disk” C: (again, C: isn’t a disk, it’s a partition, but Windows makes it easy to conflate the two) is now split in two (or three or more) and mounted not just on / but also on /home (and maybe on /boot as well, and maybe one partition isn’t mounted on the main abstract root filesystem).

    / and /home aren’t really even partitions (let alone disks). They’re mount points in the slightly more abstract root filesystem.

    The most obvious software representation on a typical Linux system of the main internal disk in that machine would probably be something like /dev/sda or /dev/nvme0. The partitions would likely be something like /dev/sda1//dev/sda2/etc or /dev/nvme0p1//dev/nvme0p2/etc. Also, the “filesystem” on the partition is arguably a subtlely a distinct concept from the block device that is the partition. And where that filesystem is mounted is yet another distinct concept. (Another subtlety I haven’t mentioned is the distinction between the device in the /dev/ directory/filesystem and the kernel representation of the device with the device major/minor numbers.)

    A typical Windows install kindof conflates a lot of these probably a lot more so than Linux does. But I didn’t want to be like “akshuly things are a lot more complicated than that and you have to understand a bunch of Linux kernel internals to understand all the ways in which you’re wrong so you can install the holy ‘Guh-noo Plus Linux’.” All that is stuff that OP will learn by installing and using Linux. And if OP’s going with Mint, it’s probably not necessary to really understand all of that before starting the install process.

    And technically OP doesn’t really need to understand that the main disk won’t be called C: after switching to Linux. Probably. (I don’t think I’ve ever installed Mint. So I don’t know for sure, but from what I’ve heard about it, I’d be surprised if the installation process had much of a learning curve.) But I told OP anyway. So there. :D


  • Welcome to the club!

    Just want to mention that "C:" is a Windows-specific convention for identifying hard disks. Linux doesn’t have quite any concept of a “C:\ drive.” You’ll of course still have your OS installed on the same disk that today Windows calls "C:", but on Linux it’ll be (and I’m oversimplifying a little bit here) “/”.

    I’m a little bit jealous because I can’t start learning such things for the first time like you will be soon. Ha!

    My advice: don’t feel like you have to learn it all at once. Don’t feel bad about just accepting the defaults that the installer suggests where you don’t know what to do otherwise. If the command line intimidates you (we were all there once) use the gui tools exclusively as much as you like. Some day you might start to feel limited sticking with gui tools. (Or maybe for your particular purposes, the guis will always be perfect.) Until you do start to feel like you want to learn more about such things for your own sake, don’t let anyone tell you you’re doing it wrong by using the easy way.

    (This from someone who does basically everything from the terminal. Lol!)

    And don’t be too afraid to break things. Breaking things is arguably the best way to learn. And do feel free to reach out to friendly communities for help when you need it. It’s likely that if something has gone wrong (which is pretty unlikely with Mint), you’ll need to do some terminal stuff to fix it, but people can help you out with that if you ask. :)

    Godspeed!