• otacon239@lemmy.world
    4·
    13 days ago

    Okay, this is legitimately cool as heck. This finally helps me wrap my head around the “everything is a file” concept in Linux. Of course it can just copy the executable to memory for later reference. That’s how the system would not completely have a meltdown when you do live updates.

    Excellent share!

    • atzanteol@sh.itjust.worksEnglish
      2·
      13 days ago

      It’s a bit more interesting than that…

      Linux, unlike Windows, will let you delete a file that is actively in use. It removes the reference on the file system but the contents of the file won’t be deleted until all file pointers to it close. In fact it will still be seen as taking up disk space until it’s garbage collected (deleting a large file that’s in use can be frustrating).

      So the file is actually still available to that running process. If you replace it with a new executable and run that then you get the new version.

    • HiddenLayer555@lemmy.mlEnglish
      1·
      13 days ago

      I bet this is done with inodes. Deleted files aren’t truely deleted until nothing has it open and its inode gets dropped. Like ARC for files.

      You can also do interesting things like overwrite a “file” (as in a specific filesystem path) with new contents while keeping anything that already has the file open on the old contents by unlinking the old inode to the path and writing the new contents under a new inode. I believe mv does this. The kind of lesser known feature that probably strikes a good balance between preventing super annoying silent errors/corruption and causing them.

      Relevant Kevin Fang video

      • AlteredEgo@lemmy.ml
        0·
        13 days ago

        Thanks for explaining, I was wondering about that.

        Wait, is that why renaming or moving files on android takes forever?

        • diaphragmwp@discuss.tchncs.deEnglish
          1·
          13 days ago

          No, that’s because Android. It’s also overlaying all filesystems to enforce stupid rules, like no files named “CON” and no files named the same in a different case (like in DOS).

  • rumba@lemmy.zipEnglish
    3·
    12 days ago

    You used to be able to sudo cat /proc/kcore > /dev/dsp and listen to your ram

      • rumba@lemmy.zipEnglish
        0·
        11 days ago

        It was before OSS was taken over by ALSA (and other things) for sound. OSS let you play loose and fast and was very forgiving. I just tried using pulseaudio to do it and barely got a burble of static out of it.

        • MonkeMischief@lemmy.today
          1·
          9 days ago

          That is super rad. I wonder how hard it would be to replicate today.

          We could have a “RAMcore” subgenre. I wonder how running different processes affects the sound?

          Imagine if the German underground scene discovered RAM noises. . .damn, RAMmstein is already taken. XD

          All seriousness though…I now wanna know what my RAM sounds like. Lol

          • rumba@lemmy.zipEnglish
            2·
            9 days ago

            Stand up an old VM that still has OSS. I screwed around with current drivers and didn’t get anything cool sounding.

      • rumba@lemmy.zipEnglish
        1·
        11 days ago

        it rotated in between white noise, strobing sirens, digital corruption and silence.

  • provectus@lemmy.mlEnglish
    2·
    13 days ago

    Did you know openBSD does not have this folder? I think the BSD’s do not use /proc. I do not know why though.

    • [object Object]@lemmy.world
      0·
      13 days ago

      That raises the question of how their ps, top, lsof and such work, since afaik in Linux they read from /proc.

      P.S. Looks like BSDs tug at the kernel via syscalls, namely sysctl and also the ‘kvm interface’ in the case of MacOS (not sure what ‘kvm’ thing is meant here). Seems vaguely reasonable, since procfs also queries the kernel for the info, so about the same resources would be used, perhaps even with the overhead of filesystem traversal and string-numbers conversion.

      • provectus@lemmy.mlEnglish
        1·
        12 days ago

        I might be mistaken, but I think kvm stands for kernel virtual machine. Having no /proc, and interacting with sysctl instead sounds more secure, IMO.

  • utopiah@lemmy.ml
    2·
    12 days ago

    I have some of her paper zines on my desk, warmly recommended.

    Might look esoteric at first but if you think we will be using Linux at least on desktop, servers, consoles and more for decades then totally worth learning about.

  • communism@lemmy.ml
    2·
    12 days ago

    Julia Evans has a bunch of these really handy cheatsheets. I have several saved that I reference semi-regularly.

  • four@lemmy.zipEnglish
    2·
    13 days ago

    I’m surprised it doesn’t mention that /proc/self automagically points to the directory of the current process. So if you’re writing a program, you can just look there for information about itself

  • lyralycan@sh.itjust.works
    1·
    13 days ago

    Great tips! Although if i may 🤓 just a little for the top right, it works because what you deleted isn’t the binary, it’s the pointer that points to the binary’s location. The data is still exactly as it was before “deletion”; the symlink is simply a copy of the original pointer’s info; and I’m speculating that the existence of any pointer prevents the system from recycling those addressed bits.

  • PowerCrazy@lemmy.mlEnglish
    1·
    13 days ago

    I didn’t know any of this. Amazing. I usually just look at /proc/net/ for routes and bonding config etc.

  • jaybone@lemmy.zipEnglish
    0·
    13 days ago

    I’m aware of /proc but usually use lsof to find open fd’s for a process.

    Is one better than the other?