Most people stop at stage 2, stage 3 hits when you decide to write a filesystem, stage 4 when you've finished your first filesystem. Stage 5 is when you start working on kernel internals. No one can tell you how to reach stage 6, you must discover it for yourself.
If you can recognize "nothing" then "nothing" must be something right? So if nothing is a file, because /dev/null says so, then nothing MUST be something to be a file. And therefore /dev/null can't be nothing.
The word "nothing" is the English word describing the concept of nothing. And I have to use the word to describe the concept. So yes, you are correct the word is itself "something". So that is probably one point for "nothing" to not exist.
I have now consumed 3 cups of tea. And my head now hurts from thinking about nothing. I should never have stepped into this post.
in fact that gets used in abstract mathematics to first introduce the natural numbers. the empty set (nothing) (which you define as 0) is not itself nothing, so you can define the set that contains just the empty set, which now is not empty itself, but contains one element, so you define that as 1 ...
Unfortunately, no one can be told what a file is. You have to see it for yourself.
This is your last chance. After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the file system goes.
I feel like it's more of a "If I tried to tell you what this was, you wouldn't believe me" than a "I am physically incapable of explaining the idea that you're plugged into a computer".
Okay, but what are blocks then? A file is really just a bunch of blocked stacked together with the inode metadata also sitting on another block, so is everything just blocks or because you can emulate a block device on a filesystem, are blocks themselves files? If that last part is true then files are infinitely recursive and my head is starting to spin.
You are almost ready to take the next step. But to do so, you must unlearn what you think you know. Write a filesystem that does not have blocks for a media without pages, and you will find the footprints of your next teacher.
Linux is closer than other *nixes (sysctl equivalents in some platforms are not files, but they are files in Linux).
However get very far into network and the file-like behaviors become more limited. From an application, at least you have a decent chance of having unseekable, but otherwise 'file-like' interaction with stream protocols. Then you need recvmsg/sendmsg. Then you want to deal with low level interaction with the network stack and dealing with NETLINK and such..
The troubles between stage 2 and 6 are probably realizing dirs are not files, and seeing that device and driver files are different things from data files.
Then stage 6 would be realizing that filesystems themselves just sit on device files. The directories and data files are in the device files. In truth, everything is a device file.
But then, I propose a stage 7. Because when you trace it all back, with mounts pointing to device files sitting in mounted file systems, you see that /dev is a tempfs, mounted in a tempfs, in which device files are "mounted". The fondamental root, /, is underneath the root filesystem a tempfs too. At boot, the kernel makes a tempfs, and later overlays the rootfs mounted from the /dev mounted in the root tempfs.
Everything is a filesystem, ever,thing is mounted. The true files, device files, are mounted too. They are the mounting of a kernel module in the same way a directory - a filesystem - is a mounted kernel module.
The Linux world is a ying and yang between dir structures and mounted kernel modules. In all of this, data files, the "true files", don't even show up. At the end, it's just the kernel talking to itself.
Don’t leap ahead, or you will come to a false conclusion. Write a filesystem, then write another using a completely different approach for a system without a kernel. Then run them on each others targets. Only then will your mind be clear enough to see.
Hm, I wrote a btrfs tool once that operates on an unmounted btrfs partition (so I can introduce forbidden states).
And I wrote a normal fuse-based emulated fs to fool a game into loading my custom infinite world as a save.
The old masters did not have fuse and there are more devices than your SSD. Write a log formatted filesystem for an SPI flash chip, and move your fuse-based system onto a HDD. Then the next path will be revealed.
It makes more sense when you realize that it's not that everything is files it's that everything can be treated as a file. There are other APIs to interact with things, but everything can be interacted with as if it was a file. It doesn't seem as bonkers like this.
Exactly. A file is really just a way to understand a collection of bits. So saying everything is files is like saying everything in computers can be described as sets of bits, which is not a terrible heuristic.
Yeah, it sort of depends on the definition of the word file. "File" in the sense that it can be interacted with like a file versus "file" in the sense that it's data on a disk. But then, if you're really thinking about it, data on a disk isn't a file, it's data, and we can just interact with it like a file.
Generally speaking, a handle is an opaque reference to an os object; the typedef here makes that clear. Linux uses the same general concept as well, though file objects are typically referenced through file descriptors rather than windows style handles.
But some things are directories (like cgroups). And Networknamespaces were also controled in a weird way.
And then there are kernel features which are not exposed through a file or syscall but through a special type of socket.
Directories are just files if you squint at then right, and sockets are basically files too. As another commenter said, it's not that everything is literally a file, but that it presents as a file, and can be interacted with as one.
Haha no my friend uses Linux and I haven't made the switch because I was under the impression that you have to be a command line wiz. Then he went on a rant about graphical interface.
Eh, there are distros where you will never need to touch a command line if you don't want to. In fact, most modern mainstream ones are that way: Mint, Fedora, Ubuntu, etc.
Though I don't understand the fear of the command line. My grandmother owned two computers in her life and both of them were command line only. She was not a researcher at a university, a professional programmer or anything like that, just a normal person with a high school education.
She just wasn't afraid to read the manual and try things. I still remember the spiral-bound manual with post-its covered in her nurses shorthand.
She used them to run the books for the family business, first an Apple ][, then a PC running DOS. She also used them to write letters and the church newsletter, practice Bridge, organize her family genealogy work, and things like that.
75 replies
Stages of POSIX enlightenment:
Most people stop at stage 2, stage 3 hits when you decide to write a filesystem, stage 4 when you've finished your first filesystem. Stage 5 is when you start working on kernel internals. No one can tell you how to reach stage 6, you must discover it for yourself.
/dev/nullsez nothing is also a fileAsking for a friend.
If you can recognize "nothing" then "nothing" must be something right? So if nothing is a file, because /dev/null says so, then nothing MUST be something to be a file. And therefore /dev/null can't be nothing.
Or do I just need more tea? Or maybe whisk(e)y?
The word "nothing" isn't itself nothing. It is something used to describe nothing.
The word "nothing" is the English word describing the concept of nothing. And I have to use the word to describe the concept. So yes, you are correct the word is itself "something". So that is probably one point for "nothing" to not exist.
I have now consumed 3 cups of tea. And my head now hurts from thinking about nothing. I should never have stepped into this post.
it's just a sentinel value. You ve reached the end. gimme back the length
The length is a null value.
oh god oh no oh god oh no i am gonna crash
in fact that gets used in abstract mathematics to first introduce the natural numbers. the empty set (nothing) (which you define as 0) is not itself nothing, so you can define the set that contains just the empty set, which now is not empty itself, but contains one element, so you define that as 1 ...
A file would be something. No, it was nothing.
Unfortunately, no one can be told what a file is. You have to see it for yourself.
This is your last chance. After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the file system goes.
https://xkcd.com/566/
I feel like it's more of a "If I tried to tell you what this was, you wouldn't believe me" than a "I am physically incapable of explaining the idea that you're plugged into a computer".
That way lies madness!
You'll know you've reached stage 6 when you seriously start considering running Plan 9 as a daily driver
true enlightenment: everything is a string over an IO socket
But are sockets not files?
files are named sockets 🕉️
Am I a file?
Can you read me?
Hope your name isn't Peter
In the end, we are all files. We have our read()s and write()s, in in our time we play many offsets.
"How can files be real if the filesystem isn't real?" - Jaden Smith (probably)
Okay, but what are blocks then? A file is really just a bunch of blocked stacked together with the inode metadata also sitting on another block, so is everything just blocks or because you can emulate a block device on a filesystem, are blocks themselves files? If that last part is true then files are infinitely recursive and my head is starting to spin.
You are almost ready to take the next step. But to do so, you must unlearn what you think you know. Write a filesystem that does not have blocks for a media without pages, and you will find the footprints of your next teacher.
The devnode that is used to reference the block is a file, so you come back to blocks just 'being offsets into some file'.
Though system calls, ioctls and networking credibly get away from file semantics
Files? In my Linux?
It's more likely than you think.
And the hidden 0th level that you only get after being nearly killed by a falling server rack:
"Files Aren't Things"
Which looks great on a tshirt, btw :p
Missing stage 7: Not everything is a file.
Linux is closer than other *nixes (sysctl equivalents in some platforms are not files, but they are files in Linux).
However get very far into network and the file-like behaviors become more limited. From an application, at least you have a decent chance of having unseekable, but otherwise 'file-like' interaction with stream protocols. Then you need recvmsg/sendmsg. Then you want to deal with low level interaction with the network stack and dealing with NETLINK and such..
That's where plan9 comes in!
Yes, the "did I stutter?" If everything is a file philosophy.
The troubles between stage 2 and 6 are probably realizing dirs are not files, and seeing that device and driver files are different things from data files. Then stage 6 would be realizing that filesystems themselves just sit on device files. The directories and data files are in the device files. In truth, everything is a device file.
But then, I propose a stage 7. Because when you trace it all back, with mounts pointing to device files sitting in mounted file systems, you see that /dev is a tempfs, mounted in a tempfs, in which device files are "mounted". The fondamental root, /, is underneath the root filesystem a tempfs too. At boot, the kernel makes a tempfs, and later overlays the rootfs mounted from the /dev mounted in the root tempfs.
Everything is a filesystem, ever,thing is mounted. The true files, device files, are mounted too. They are the mounting of a kernel module in the same way a directory - a filesystem - is a mounted kernel module.
The Linux world is a ying and yang between dir structures and mounted kernel modules. In all of this, data files, the "true files", don't even show up. At the end, it's just the kernel talking to itself.
Don’t leap ahead, or you will come to a false conclusion. Write a filesystem, then write another using a completely different approach for a system without a kernel. Then run them on each others targets. Only then will your mind be clear enough to see.
Hm, I wrote a btrfs tool once that operates on an unmounted btrfs partition (so I can introduce forbidden states).
And I wrote a normal fuse-based emulated fs to fool a game into loading my custom infinite world as a save.
What more do I need to reach dao?
The old masters did not have fuse and there are more devices than your SSD. Write a log formatted filesystem for an SPI flash chip, and move your fuse-based system onto a HDD. Then the next path will be revealed.
It makes more sense when you realize that it's not that everything is files it's that everything can be treated as a file. There are other APIs to interact with things, but everything can be interacted with as if it was a file. It doesn't seem as bonkers like this.
Exactly. A file is really just a way to understand a collection of bits. So saying everything is files is like saying everything in computers can be described as sets of bits, which is not a terrible heuristic.
It's like saying everything is a wave IRL.
Especially the particles
Files don't actually exist once you dig down
Bro stop digging I need those files to keep existing
Yeah, it sort of depends on the definition of the word file. "File" in the sense that it can be interacted with like a file versus "file" in the sense that it's data on a disk. But then, if you're really thinking about it, data on a disk isn't a file, it's data, and we can just interact with it like a file.
🤯
Welcome, brother. But remember that they must walk the path themselves or they will never reach true understanding.
Everything is computer.
Yep, takes a moment to wrap your head around but the longer you read linux/unix documentation, the more it makes sense why it is the case.
tldr: it's to have nicer, less complicated I/O operations
it enables just having two API calls: read() and write() to do everything
Can confirm; user is file too
Source: user
Want take it to 11 plan 9 did it.
In Windows land, it's HANDLEs...which is
typedef void* HANDLEIIRCGenerally speaking, a handle is an opaque reference to an os object; the
typedefhere makes that clear. Linux uses the same general concept as well, though file objects are typically referenced through file descriptors rather than windows style handles.But some things are directories (like cgroups). And Networknamespaces were also controled in a weird way.
And then there are kernel features which are not exposed through a file or syscall but through a special type of socket.
Aren't directories just files that say "hey i am directory ABCD and file X, Y and Z are my childs"?
Directories are just files if you squint at then right, and sockets are basically files too. As another commenter said, it's not that everything is literally a file, but that it presents as a file, and can be interacted with as one.
Well, if you go back far enough you might encounter punch cards or even switches, but then again you're not taking about modern computers anymore.
What's this "back far enough" shit, I've used punch cards and punch tape.
Fuck me I'm old.
To feel really old: http://themindsetlist.com/lists/
That's funny. I have a pair of Converse tennis shoes that are 27 years older than that list......
Class of '99 here.
There's at least a decade between the beginning of that list and people regularly using punch cards and tape. Maybe two.
Magnetic tapes and actually floppy floppy disks were the medium of choice in the interim.
I run linux off an 80s cassette. The flip side is Fleetwood Mac and Deep Purple.
(arch btw)
(arch btw)
Well there's your problem. Can I interest you in TempleOS?
You could argue that a collection of punch cards is a file
If you put them in a physical file and it gets jostled they go out of order and you have a problem. You want them in stacks.
I think technically it's only a file when it's managed by the system itself (reading, writing, modifying, storing) so punch cards are not files.
Ok you got me with this one.
Btw the mitochondria are the powerhouse of the cell.
Epstein's?
Yeah, but in the BSD land as their licensing is more Libertarian esqu.
ok then how do i access
[2b00:13c0:47:1422::5]:7236through a file?i don't think that's possible
only on plan9
But what about the fotoes?
I suspect sarcasm but in case it is not, photos are just binary files, just like videos and many other file formats.
Haha no my friend uses Linux and I haven't made the switch because I was under the impression that you have to be a command line wiz. Then he went on a rant about graphical interface.
Eh, there are distros where you will never need to touch a command line if you don't want to. In fact, most modern mainstream ones are that way: Mint, Fedora, Ubuntu, etc.
Though I don't understand the fear of the command line. My grandmother owned two computers in her life and both of them were command line only. She was not a researcher at a university, a professional programmer or anything like that, just a normal person with a high school education.
She just wasn't afraid to read the manual and try things. I still remember the spiral-bound manual with post-its covered in her nurses shorthand.
She used them to run the books for the family business, first an Apple ][, then a PC running DOS. She also used them to write letters and the church newsletter, practice Bridge, organize her family genealogy work, and things like that.