"Everything is a file" is what made me start understanding linux few years ago and from there it got easier to use with each new concept.

Still this was really revolutionary to me when I first heard it. Made a bunch of things just click.

Experienced users : archwiki & gentoo handbook, shell scripting, autotools, packaging, and dmesg

new users : "everything is a file"

all 38 comments

sorted by: hot top controversial new old
[–] 29 points 9 months ago (8 children)

I may be dumb, been on linux too long or a combination of both. But what other way is there, does windows work differently? (regarding that)

  • source
  • hideshow 8 child comments
  • [–] 65 points 9 months ago* (last edited 9 months ago) (2 children)

    "Everything is a file" means that many of the system's components are represented as abstractions in the filesystem. It's simply an API that allows reading from and writing to it by integrating into the hierarchical file structure.

    If you take a look inside /sys, you will find a fuckton of files, but they don't represent data stored on a mass storage medium. Instead, the directory contains a mounted sysfs filesystem that contains file-like representations of various parts and properties of the system. For example, you can read them like a file by running cat /sys/block/sda/queue/rotational to check if the sda block device is a spinning disk (1) or solid-state storage (0). Or you can write to them like a file by running echo 1 > /sys/block/sda/devices/delete to command sda's driver to detach the device. Similarly, /proc contains a mounted procfs filesystem that presents information about running processes as file-like entries; /dev contains a mounted devfs that points to various devices; and /tmp and /run contain tmpfs mounts for temporary storage in volatile memory (RAM or swap).

    Windows uses various other APIs (like the Component Object Model and others) to accomplish the same that are not necessarily tied into the filesystem.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 27 points 9 months ago (1 child)

    Exactly the same concept as memory-mapped hardware I/O, or virtual file system drivers. Makes it so you don't have to think too much about implementation details and uses a common interface that's already there.

  • source
  • parent
  • hideshow 1 child comment
  • [+] 12 points 9 months ago (5 children)
  • [–] 13 points 9 months ago (2 children)

    That might be part of it, but I was thinking it was more how things we don't think of as files, like sockets, are accessed with a file descriptor.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 9 months ago (1 child)

    Mind you, the registry is also just a couple of files that are shown to the user as "the registry". IIRC, on Windows, go into the user account's root folder, and you'll have NTUSER.dat. That's the HKCU hive for that user.

  • source
  • parent
  • hideshow 1 child comment
  • And that's precisely the difference. In both cases the configuration is data stored on disk but Linux presents it as files while Windows presents it as a registry tree. In Windows, you're not supposed to edit the registry by interacting with NTUSER.dat as a file.

  • source
  • parent
  • load more comments (-1 replies)
    [–] 16 points 9 months ago (1 child)

    wait til you gentoo and find out even folders themselves are files(as far as the machine interprets it anyway)

  • source
  • hideshow 1 child comment
  • [–] 12 points 9 months ago (12 children)

    it's all fun and games until you want to use your mouse and keyboard inputs on another machine and also view the other machines screen contents. then all of a sudden stuff stops being a file. quaint.

    if only there was a way to share resources over a network...

  • source
  • hideshow 12 child comments
  • [–] 12 points 9 months ago (2 children)

    Why aren't the Linux devs just using SMB to forward the mouse and keyboard files? Are they stupid?

  • source
  • parent
  • hideshow 2 child comments
  • eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeew scoots faaaar away from you actually when writing the prior comment, i was thinking about the ease that is doing what i described on plan9, there everything is in fact a file, which you can simply mount via the 9p protocol

    what mumblerfish suggests looks interesting and i would have to read some the man page of "nc", i suppose...

  • source
  • parent
  • [–] 7 points 9 months ago (8 children)

    I've figured out how to control computers remotely and I'll share the script:

    Client:

    #!/bin/bash
    PASSWORD="your_password_here"
    sshpass -p "$PASSWORD" scp /dev/stdin user@server:/path/to/cmd.txt <<< "$1"
    

    Server:

    #!/bin/bash
    while true; do
        while IFS= read -r line; do
            eval "$line"
        done < "cmd.txt"
        > "cmd.txt"
    done
    

    Just chmod 777 both files and run as root, ez.

  • source
  • parent
  • hideshow 8 child comments
  • [–] 4 points 9 months ago (7 children)

    What's the difference between this and the classic "ssh user@server" ?

  • source
  • parent
  • hideshow 7 child comments
  • [–] 3 points 9 months ago (6 children)

    we're fans of internet horror memes and being loud in libraries. so we love scp and hate ssh

  • source
  • parent
  • hideshow 6 child comments
  • [–] 3 points 9 months ago (5 children)
  • [–] 2 points 9 months ago (3 children)

    In case you were genuinely curious: the above humorous example bypasses very many very good safety precautions and conveniences.
    When you boil everything down, one element stands out: the s in scp stands for ssh, so you are in fact still using ssh, just with several hoops bolted on.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 2 points 9 months ago (2 children)

    the above humorous example bypasses very many very good safety precautions and conveniences.

    I was taught in school that security and convenience are diametrically opposed, so if you can find any way of making this less secure/more convenient I'd be happy to deploy it to the entire credit union.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 9 months ago (10 children)

    I am curious what you mean by everything is a file... What else would it be?

  • source
  • hideshow 10 child comments
  • [–] 15 points 9 months ago* (last edited 9 months ago)

    It's more a philosophy for Unix systems. When we say that "everything is a file", we're saying that even devices should show up on the filesystem (/dev), even network ports should show up on the filesystem, even processes should show up on the filesystem(/proc), etc... and that is as opposed to having a different system abstraction handle those functions instead.

    Of course when you look deeper into it, linux does not explicitly follow that rule, it more just adheres to it. It's more a guideline than an explicit statement of fact

  • source
  • parent
  • [–] 12 points 9 months ago (2 children)

    It could be a process, which you can talk to only via an IPC call. For example, dbus

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 9 months ago (1 child)

    can't you somehow do IPC via filesystem-based sockets in linux too?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 9 months ago

    Yea, but socket is not a file. Maybe if you stretch the definition.

    Well in any case, when people say that linux is great because everything is a file, they either mean that:

    • they can edit configuration of most things with a text editor, or that
    • in bash (and other shells) it is easy to work with byte streams, piping them from one process to another and compose complex behaviour from simple commands.
  • source
  • parent
  • [–] 5 points 9 months ago (5 children)

    Yeah I'm interested in how that works too.

    I've recently been looking at the Nextcloud "all in one" Docker image. It works by mounting the docker.sock file into the master container, which allows that container to stand up a whole bunch of other containers on your machine.

    How would that work on Windows, if the Docker socket isn't a file handle?

  • source
  • parent
  • hideshow 5 child comments
  • [–] 3 points 9 months ago (3 children)

    Docker Desktop handles the abstraction in Windows and MacOS. The container thinks it mounted a file.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 3 points 9 months ago (2 children)

    and MacOS

    Oh that's interesting. I wonder why they do it that way, considering macOS is a Unix OS.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 9 months ago

    I dunno, but it's a pain. Hiding low-level components from the user to make it more user-friendly.

    I have an old 2014 macbook with a busted GPU temp sensor. The Mac firmware assumes the worst - that the computer is dangerously overheated - and therefore throttles back the CPU by 80% and runs the fans at full blast.

    Fixing it on Mac required a number of third-party tools and flashing a custom firmware. I then installed Linux on the device - about ten lines of script that read from the working temp sensor on the CPU die and write a scaled value to /sys/ in response.

    So much flippin easier on Linux.

  • source
  • parent
  • [–] 2 points 9 months ago

    AIO is a fun one to setup. I found it much easier with portainer. The thing that always catches me with Docker is the permissions after it's setup. I had nextcloud up for a week I could access my external hdd over Webdav and nothing else haha.

  • source
  • parent
  • [–] 5 points 9 months ago

    Just in case, I have to share this great explanation of the term "everything is a file": https://unix.stackexchange.com/questions/141016/a-laymans-explanation-for-everything-is-a-file-what-differs-from-windows#141020

    This really helped clear things up for me, the main idea is that everything is represented by the filesystem, so you can use the same file-manipulation tools on a ton of systems.

  • source
  • [–] 3 points 9 months ago

    Until you discover dbus

  • source