4 ms·

As someone in the midst of transitioning to Linux for the first time ever, the thing is: I still kinda hate Unix, but my AI friends (Claude Code / Codex) are ve

As someone in the midst of transitioning to Linux for the first time ever, the thing is: I still kinda hate Unix, but my AI friends (Claude Code / Codex) are very good at Unix/Linux and the everything is a file nature of it is amenable to AI helping me make my OS do what I want in a way that Windows definitely isn't.

pjmlp 1y ago
On UNIX the "everything is a file" quickly breaks down, when networking, or features added post UNIX System V get used, but the meme still holds apparently. If you want really everything is a file, that was fixed by UNIX authors in Plan 9 and Inferno.
- dark-star 1y ago
  Yeah, I was really confused when I learned that every device was simply a file in /dev, except the network interfaces. I never understood why there is no /dev/eth0 ... That was back in the mid-90s but even today I still don't understand why network interfaces are treated differently than other devices
  - simonh 1y ago
    It's probably because ethernet and early versions of what became TCP/IP were not originally developed on Unix, and weren't tied to it's paradigms, they were ported to it.
  - MisterTea 1y ago
    Plan 9 does exactly this but all networking protocols live in /net - ethernet, tcp, udp, tls, icmp, etc. The dial string in the form of "net!address!service" abstracts the protocol from the application. A program can dial tcp!1.2.3.4!7788 or maybe udp!1.2.3.4!7788. How about raw Ethernet? /net/ether1!aabbccddeeff!12345. The dial(2) routine takes a dial string and returns an fd you read() and write(). Very simple networking API.
  - mixmastamyk 1y ago
    What would it mean to write to a network interface? Blast everyone as multicast? Not that useful. But Plan9 had connections as files, though I’ve never tried.
    - dark-star 1y ago
      That's a bad argument. What does it mean to write to a mouse device? To the audio mixer? To the i2c bus device? To a raw SCSI device (scanner or whatever)? Those are all not very useful either. Especially since there actually is a very useful thing that writing to /dev/eth0 would do: Put a raw frame on the wire, and reading from it would read raw frames.
      - mixmastamyk 1y ago
        You haven't thought through what you're asking. That's the bad argument. Network packets are not viable without a destination address. Nor does anyone want unaddressed (garbage) packets on their network.
        dark-star 1y ago
        I certainly have thought this through. Network packets don't need a destination address. Broadcast addresses exist. Also, packets to invalid/unknown destinations exist. You can send network packets with invalid source or destination addresses already anyway. Taking a raw chunk of data and putting it on the wire as-is is the most logical interpretation of "writing to the ethernet device". Does it make sense to allow everyone to do that? Certainly not, that's why you restrict access to devices anyway. The fact that not every chunk of data "makes sense" for every device in /dev is certainly nothing new, since that is the case for all other devices already (I mentioned a few in my post above).
        mixmastamyk 1y ago
        My first comment mentions multicast. Invalid packets won’t get routed, unless lucky enough to be accidentally valid.
- blu3h4t 1y ago
  I was recently thinking that object orientation is kind of everything is a file 2.0 in the form everything is an object I mean ofcourse didn’t pan out that good. Haven’t googled yet what people had to say about that already before. P.s. big fan of ur comments.
  - myaccountonhn 1y ago
    I actually read a decent paper on that a while back Unix, Plan 9 and the Lurking Smalltalk https://www.humprog.org/~stephen/research/papers/kell19unix-personal.pdf https://www.humprog.org/~stephen/research/papers/kell19unix-... Late binding is a bit out of fashion these days but it really brings a lot of cool benefits for composition.
    - pjmlp 1y ago
      There is also an interesting from Xerox PARC, "UNIX Needs A True Integrated Environment: CASE Closed" http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-4_UNIX_Needs_A_True_Integrated_Environment.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-4... For the TL;DR; crowd "We 've painted a dim picture of what it takes to bring IPEs to UNIX. The problems of locating. user interfaces. system seamlessness. and incrementality are hard to solve for current UNIXes--but not impossible. One of the reasons so little attention has been paid to the needs of IPEs in UNIX is that UNIX had not had good examples of IPEs for inspiration. This is changing: for instance. one of this article's authors has helped to develop the Small talk IPE for UNIX (see the adjacent story). and two others of us are working to make the Cedar IPE available on UNIX. What's more. new UNIX facilities. such as shared memory and lightweight processes (threads). go a long way toward enabling seamless integration. Of course. these features don't themselves deliver integration: that takes UNIX programmers shaping UNIX as they always have--in the context of a friendly and cooperative community. As more UNIX programmers come to know IPEs and their power. UNIX itself will inevitably evolve toward being a full IPE. And then UNIX programmers can have what Lisp and Small talk and Cedar programmers have had for many years: a truly comfortable place to program."
  - MisterTea 1y ago
    > object orientation is kind of everything is a file 2.0 in the form everything is an object That is why I love Plan 9. 9P serves you a tree of named objects that can be byte addressed. Those objects are on the other end of an RPC server that can run anywhere, on any machine, thanks to 9p being architecture agnostic. Those named objects could be memory, hardware devices, actual on-disk files, etc. Very flexible and simple architecture.
- tankenmate 1y ago
  Some GOSIP (remember that?) implementations on some Unicies did have files for network connections, but it was very much in the minority. Since BSD was the home of the first widely usable socket() implementations for TCP/IP it became the norm; sockets are a file, but just not linked to any filesystem and control is connect()/accept() and the networking equivalent (setsockopt()) of the Unix system call dumping ground; ioctl().
  - pjmlp 1y ago
    I don't remember any of the ones I used having it, or then I missed it. Kind of, sockets don't do seek().
    - fuzztester 1y ago
      Psst - don't tell().
    - tankenmate 1y ago
      Not all devices support seek either, they're still files; ENOSYS
- zokier 1y ago
  Well it depends on what "file" means. Linuxian interpretation would be that file is something you can get file descriptor for. And then the "everything is a file" mantra holds better again.
  - pjmlp 1y ago
    Although many people nowadays misunderstand Linux for UNIX, it still isn't the same.
  - tsimionescu 1y ago
    Windows is actually much closer to this limited, meaningless, form of the "everything is a file" meme. In Windows literally every kernel object is a Handle. A file, a thread, a mutex, a socket - all Handles. In Linux, some of these are file descriptors, some are completely different things. Of course, this is meaningless, as you can't actually do any common operation, except maybe Close*, on all of them. So them being the same type is actually a hindrance, not a help - it makes it easier to accidentally pass a socket to a function that expects a file, and will fail badly when trying to, for example, seek() in it. * to be fair, Windows actually has WaitForSingleObject / WaitForMultipleObjects as well, which I think does do something meaningful for any Handle. I don't think Linux has anything similar.
    - marcosdumay 1y ago
      > Of course, this is meaningless, as you can't actually do any common operation, except maybe Close*, on all of them. You can write and read on anything on Unix that "is a file". You can't open or close all of them. Annoyingly, files come in 2 flavors, and you are supposed to optimize your reads and writes differently.
      - tsimionescu 1y ago
        You can call write() and read() on any file descriptor, but it won't necessarily do something meaningful. For example, calling them on a socket in listen mode won't do anything meaningful. And many special files don't implement at least one of read or write - for example, reading or writing to many of the special files in /proc/fs doesn't do anything.
- star-glider 1y ago
  Linus finally relented and changed it to "everything is a stream of bits." Still, it's a useful metaphor and way to think about interacting with bits of the OS.
TrackerFF 1y ago
Having observed my fair share of beginners transition from win to linux, the most common source of pain I've seen is getting used to the file permissions, and playing fast and loose with sudo.
ok123456 1y ago
The problems of commercial Unix in 1993 are totally different from Linux in 2025.

pjmlp 1y ago

On UNIX the "everything is a file" quickly breaks down, when networking, or features added post UNIX System V get used, but the meme still holds apparently. If you want really everything is a file, that was fixed by UNIX authors in Plan 9 and Inferno.

dark-star 1y ago
Yeah, I was really confused when I learned that every device was simply a file in /dev, except the network interfaces. I never understood why there is no /dev/eth0 ... That was back in the mid-90s but even today I still don't understand why network interfaces are treated differently than other devices
- simonh 1y ago
  It's probably because ethernet and early versions of what became TCP/IP were not originally developed on Unix, and weren't tied to it's paradigms, they were ported to it.
- MisterTea 1y ago
  Plan 9 does exactly this but all networking protocols live in /net - ethernet, tcp, udp, tls, icmp, etc. The dial string in the form of "net!address!service" abstracts the protocol from the application. A program can dial tcp!1.2.3.4!7788 or maybe udp!1.2.3.4!7788. How about raw Ethernet? /net/ether1!aabbccddeeff!12345. The dial(2) routine takes a dial string and returns an fd you read() and write(). Very simple networking API.
- mixmastamyk 1y ago
  What would it mean to write to a network interface? Blast everyone as multicast? Not that useful. But Plan9 had connections as files, though I’ve never tried.
  - dark-star 1y ago
    That's a bad argument. What does it mean to write to a mouse device? To the audio mixer? To the i2c bus device? To a raw SCSI device (scanner or whatever)? Those are all not very useful either. Especially since there actually is a very useful thing that writing to /dev/eth0 would do: Put a raw frame on the wire, and reading from it would read raw frames.
    - mixmastamyk 1y ago
      You haven't thought through what you're asking. That's the bad argument. Network packets are not viable without a destination address. Nor does anyone want unaddressed (garbage) packets on their network.
      - dark-star 1y ago
        I certainly have thought this through. Network packets don't need a destination address. Broadcast addresses exist. Also, packets to invalid/unknown destinations exist. You can send network packets with invalid source or destination addresses already anyway. Taking a raw chunk of data and putting it on the wire as-is is the most logical interpretation of "writing to the ethernet device". Does it make sense to allow everyone to do that? Certainly not, that's why you restrict access to devices anyway. The fact that not every chunk of data "makes sense" for every device in /dev is certainly nothing new, since that is the case for all other devices already (I mentioned a few in my post above).
        mixmastamyk 1y ago
        My first comment mentions multicast. Invalid packets won’t get routed, unless lucky enough to be accidentally valid.
blu3h4t 1y ago
I was recently thinking that object orientation is kind of everything is a file 2.0 in the form everything is an object I mean ofcourse didn’t pan out that good. Haven’t googled yet what people had to say about that already before. P.s. big fan of ur comments.
- myaccountonhn 1y ago
  I actually read a decent paper on that a while back Unix, Plan 9 and the Lurking Smalltalk https://www.humprog.org/~stephen/research/papers/kell19unix-personal.pdf https://www.humprog.org/~stephen/research/papers/kell19unix-... Late binding is a bit out of fashion these days but it really brings a lot of cool benefits for composition.
  - pjmlp 1y ago
    There is also an interesting from Xerox PARC, "UNIX Needs A True Integrated Environment: CASE Closed" http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-4_UNIX_Needs_A_True_Integrated_Environment.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-4... For the TL;DR; crowd "We 've painted a dim picture of what it takes to bring IPEs to UNIX. The problems of locating. user interfaces. system seamlessness. and incrementality are hard to solve for current UNIXes--but not impossible. One of the reasons so little attention has been paid to the needs of IPEs in UNIX is that UNIX had not had good examples of IPEs for inspiration. This is changing: for instance. one of this article's authors has helped to develop the Small talk IPE for UNIX (see the adjacent story). and two others of us are working to make the Cedar IPE available on UNIX. What's more. new UNIX facilities. such as shared memory and lightweight processes (threads). go a long way toward enabling seamless integration. Of course. these features don't themselves deliver integration: that takes UNIX programmers shaping UNIX as they always have--in the context of a friendly and cooperative community. As more UNIX programmers come to know IPEs and their power. UNIX itself will inevitably evolve toward being a full IPE. And then UNIX programmers can have what Lisp and Small talk and Cedar programmers have had for many years: a truly comfortable place to program."
- MisterTea 1y ago
  > object orientation is kind of everything is a file 2.0 in the form everything is an object That is why I love Plan 9. 9P serves you a tree of named objects that can be byte addressed. Those objects are on the other end of an RPC server that can run anywhere, on any machine, thanks to 9p being architecture agnostic. Those named objects could be memory, hardware devices, actual on-disk files, etc. Very flexible and simple architecture.
tankenmate 1y ago
Some GOSIP (remember that?) implementations on some Unicies did have files for network connections, but it was very much in the minority. Since BSD was the home of the first widely usable socket() implementations for TCP/IP it became the norm; sockets are a file, but just not linked to any filesystem and control is connect()/accept() and the networking equivalent (setsockopt()) of the Unix system call dumping ground; ioctl().
- pjmlp 1y ago
  I don't remember any of the ones I used having it, or then I missed it. Kind of, sockets don't do seek().
  - fuzztester 1y ago
    Psst - don't tell().
  - tankenmate 1y ago
    Not all devices support seek either, they're still files; ENOSYS
zokier 1y ago
Well it depends on what "file" means. Linuxian interpretation would be that file is something you can get file descriptor for. And then the "everything is a file" mantra holds better again.
- pjmlp 1y ago
  Although many people nowadays misunderstand Linux for UNIX, it still isn't the same.
- tsimionescu 1y ago
  Windows is actually much closer to this limited, meaningless, form of the "everything is a file" meme. In Windows literally every kernel object is a Handle. A file, a thread, a mutex, a socket - all Handles. In Linux, some of these are file descriptors, some are completely different things. Of course, this is meaningless, as you can't actually do any common operation, except maybe Close*, on all of them. So them being the same type is actually a hindrance, not a help - it makes it easier to accidentally pass a socket to a function that expects a file, and will fail badly when trying to, for example, seek() in it. * to be fair, Windows actually has WaitForSingleObject / WaitForMultipleObjects as well, which I think does do something meaningful for any Handle. I don't think Linux has anything similar.
  - marcosdumay 1y ago
    > Of course, this is meaningless, as you can't actually do any common operation, except maybe Close*, on all of them. You can write and read on anything on Unix that "is a file". You can't open or close all of them. Annoyingly, files come in 2 flavors, and you are supposed to optimize your reads and writes differently.
    - tsimionescu 1y ago
      You can call write() and read() on any file descriptor, but it won't necessarily do something meaningful. For example, calling them on a socket in listen mode won't do anything meaningful. And many special files don't implement at least one of read or write - for example, reading or writing to many of the special files in /proc/fs doesn't do anything.
star-glider 1y ago
Linus finally relented and changed it to "everything is a stream of bits." Still, it's a useful metaphor and way to think about interacting with bits of the OS.

TrackerFF 1y ago

Having observed my fair share of beginners transition from win to linux, the most common source of pain I've seen is getting used to the file permissions, and playing fast and loose with sudo.

ok123456 1y ago

The problems of commercial Unix in 1993 are totally different from Linux in 2025.