7 ms·

> The current set of namespaces in the kernel are: mount, pid, uts, ipc, net, user, and cgroup. [...] [Time is] not namespaced. [...] The kernel keyring is an

> The current set of namespaces in the kernel are: mount, pid, uts, ipc, net, user, and cgroup. [...] [Time is] not namespaced. [...] The kernel keyring is another item not namespaced. I've always argued that "everything is a file" is an exaggeration. These moments make the extent of that exaggeration clear. If everything truly was a file, the only thing you would need to namespace is the filesystem. But in reality there are a lot of other kernel objects that are not files at all.

tyingq 8y ago
I agree it's unfortunate, but it doesn't really seem in conflict with "everything is a file". Making it a file is separate from making it sensible/usable for containers. Like the /proc filesystem. They are "files", but don't many don't work as expected without something like lxcfs. Like /proc/uptime, for example.
madhadron 8y ago
Everything is a file hasn't been true for Unix since almost the beginning. It's kind of like the Unix philosophy of small, independent tools...except for the database where you store all the important data.
zapita 8y ago
You are 100% correct. “Everything is a file” was more of an early design insight, which was gradually abandoned as new features were added. There is a movement of “Unix purists” who lament this deviation from founding principles, and advocate for a return to them. The most notable example is Plan 9. In Plan 9, everything actually is a file. And exactly as you said, all resources are namespaced via the filesystem. It’s quite elegant and practical. Sadly Plan 9 has remained a fringe OS, and although it influenced mainstream operating system design in many ways (including the concept of /proc), I wish that influence had been stronger.
- temac 8y ago
  hm is NT a purer Unix than Unix then? After all, it has all its object in a filesystem-like tree...
  - tadfisher 8y ago
    In Windows NT, everything is an object. This is derived from VMS, which is essentially NT's predecessor (a principal designer of both being David Cutler of Digital Research and later Microsoft).
    - jackfraser 8y ago
      The problem I always had with this was that Windows has this whole layer of objects and what might even be elegance in places all hidden under the hood, and unless you're a C++ hacker you can't actually work with most of it. CMD and the GUI tools never exposed half of it to you; Powershell helps, but it's all still very hidden and hard to get to. In comparison, Unix provides all the tools needed to take it apart and put it back together again. When you do need to interact with some syscall interface, there's almost always a complete CLI around it. It really makes it much easier to get into the nooks and crannies, inconsistencies aside.
      - atombender 8y ago
        He's talking about the kernel. The Windows NT kernel and the Windows APIs use handles to represent kernel/API objects, and every handle has things like security associated with it. For example, CreateProcess() gives you back a HANDLE value representing the process, and you can close it with CloseHandle(). Everything is a HANDLE: Files, pipes, threads, etc. A notable exception is sockets, which for historical reasons use an API modeled on BSD sockets. The object stuff you're talking about is presumably COM, which is different. COM is great, but has nothing to do with the kernel.
        hyperman1 8y ago
        He's not talking about COM. Thé HANDLEs are a handleiding to a kernel object. This means multiple differentiatie handles light exist to the same object, and handles in different processen have probably differentiatie numeric values for the same object. Think win32 handle = Unix file descriptor (roughly)
- AceJohnny2 8y ago
  I also liked QNX, when I worked with it. You really did access devices through the /dev/ system, and device-drivers were userspace programs that created files in /dev/. If your driver crashed, you could kill the userspace driver (which deleted the file under /dev) and restart it (assuming hardware blah blah blah).
  - Someone 8y ago
    ”device-drivers were userspace programs that created files in /dev/. If your driver crashed, you could kill the userspace driver (which deleted the file under /dev)” I think that shows not everything is a file. If everything were, you would start the driver by creating the file (say as a hard link from a file in /dev to the driver executable) and kill the driver by rm-ing the file. (Chances are that, if you follow this through, this idea won’t support everything we want to do with drivers, but if so, that’s an indication that “everything is a file” doesn’t work)
    - AceJohnny2 8y ago
      Great point.
    - zapita 8y ago
      To give you a sense of how far Plan9 took the idea... To open a tcp connection, you create a special “control file” at `/net/tcp/ctl` or some similar path, then write newline-terminated text commands to the file descriptor. That descriptor now represents your socket. You can also browse its contents as a directory (in plan9 each node in the filesystem can be both a regular file and a parent directory).
- pjmlp 8y ago
  It might have been elegant, but doing high performance graphics rendering wasn't something Rio was able to do.
yayana 8y ago
I've always thought of it as the preferred interface to Userland when there isn't an overriding factor. Within a kernel it seems like no one cares how the sausage is made.
caf 8y ago
I've always argued that "everything is a file" is an exaggeration. This is true, but also bear in mind that "everything is a file" didn't mean "everything is represented by a name in the mount tree", it really meant "(almost) everything is referred to by a file descriptor". It's still true that the most painful things to deal with are the ones that aren't represented by a file descriptor.
DonHopkins 8y ago
If time were a file, you could gzip it up to compress it, and store it away for later. Time files like an arrow!
- steffan 8y ago
  Fruit files like an Apple?
sytelus 8y ago
The abstraction is not really file but stream of bytes. It turns of any object with stream of bytes will need similar set of operations: open, create, read, write, close, seek etc. This is fairly generic and powerful abstraction.
- cyphar 8y ago
  The abstraction is a file descriptor. Not all things represented by file descriptors support read(2) or _llseek(2), but by representing them as file descriptors you can reuse other things like af_unix file descriptor passing.
fulafel 8y ago
Yeah, this was one of the headline changes in Plan 9 (the second OS made by the Fathers of Unix).
- pjmlp 8y ago
  And improved in Inferno, which fixed some of Plan 9 flaws, the third OS made by the Fathers of Unix that HNers keep forgetting about.
lunchables 8y ago
I thought "everything is a file" referred to user land.

tyingq 8y ago

I agree it's unfortunate, but it doesn't really seem in conflict with "everything is a file". Making it a file is separate from making it sensible/usable for containers. Like the /proc filesystem. They are "files", but don't many don't work as expected without something like lxcfs. Like /proc/uptime, for example.

madhadron 8y ago

Everything is a file hasn't been true for Unix since almost the beginning. It's kind of like the Unix philosophy of small, independent tools...except for the database where you store all the important data.

zapita 8y ago

You are 100% correct. “Everything is a file” was more of an early design insight, which was gradually abandoned as new features were added. There is a movement of “Unix purists” who lament this deviation from founding principles, and advocate for a return to them. The most notable example is Plan 9. In Plan 9, everything actually is a file. And exactly as you said, all resources are namespaced via the filesystem. It’s quite elegant and practical. Sadly Plan 9 has remained a fringe OS, and although it influenced mainstream operating system design in many ways (including the concept of /proc), I wish that influence had been stronger.

temac 8y ago
hm is NT a purer Unix than Unix then? After all, it has all its object in a filesystem-like tree...
- tadfisher 8y ago
  In Windows NT, everything is an object. This is derived from VMS, which is essentially NT's predecessor (a principal designer of both being David Cutler of Digital Research and later Microsoft).
  - jackfraser 8y ago
    The problem I always had with this was that Windows has this whole layer of objects and what might even be elegance in places all hidden under the hood, and unless you're a C++ hacker you can't actually work with most of it. CMD and the GUI tools never exposed half of it to you; Powershell helps, but it's all still very hidden and hard to get to. In comparison, Unix provides all the tools needed to take it apart and put it back together again. When you do need to interact with some syscall interface, there's almost always a complete CLI around it. It really makes it much easier to get into the nooks and crannies, inconsistencies aside.
    - atombender 8y ago
      He's talking about the kernel. The Windows NT kernel and the Windows APIs use handles to represent kernel/API objects, and every handle has things like security associated with it. For example, CreateProcess() gives you back a HANDLE value representing the process, and you can close it with CloseHandle(). Everything is a HANDLE: Files, pipes, threads, etc. A notable exception is sockets, which for historical reasons use an API modeled on BSD sockets. The object stuff you're talking about is presumably COM, which is different. COM is great, but has nothing to do with the kernel.
      - hyperman1 8y ago
        He's not talking about COM. Thé HANDLEs are a handleiding to a kernel object. This means multiple differentiatie handles light exist to the same object, and handles in different processen have probably differentiatie numeric values for the same object. Think win32 handle = Unix file descriptor (roughly)
AceJohnny2 8y ago
I also liked QNX, when I worked with it. You really did access devices through the /dev/ system, and device-drivers were userspace programs that created files in /dev/. If your driver crashed, you could kill the userspace driver (which deleted the file under /dev) and restart it (assuming hardware blah blah blah).
- Someone 8y ago
  ”device-drivers were userspace programs that created files in /dev/. If your driver crashed, you could kill the userspace driver (which deleted the file under /dev)” I think that shows not everything is a file. If everything were, you would start the driver by creating the file (say as a hard link from a file in /dev to the driver executable) and kill the driver by rm-ing the file. (Chances are that, if you follow this through, this idea won’t support everything we want to do with drivers, but if so, that’s an indication that “everything is a file” doesn’t work)
  - AceJohnny2 8y ago
    Great point.
  - zapita 8y ago
    To give you a sense of how far Plan9 took the idea... To open a tcp connection, you create a special “control file” at `/net/tcp/ctl` or some similar path, then write newline-terminated text commands to the file descriptor. That descriptor now represents your socket. You can also browse its contents as a directory (in plan9 each node in the filesystem can be both a regular file and a parent directory).
pjmlp 8y ago
It might have been elegant, but doing high performance graphics rendering wasn't something Rio was able to do.

yayana 8y ago

I've always thought of it as the preferred interface to Userland when there isn't an overriding factor. Within a kernel it seems like no one cares how the sausage is made.

caf 8y ago

I've always argued that "everything is a file" is an exaggeration. This is true, but also bear in mind that "everything is a file" didn't mean "everything is represented by a name in the mount tree", it really meant "(almost) everything is referred to by a file descriptor". It's still true that the most painful things to deal with are the ones that aren't represented by a file descriptor.

DonHopkins 8y ago

If time were a file, you could gzip it up to compress it, and store it away for later. Time files like an arrow!

steffan 8y ago
Fruit files like an Apple?

sytelus 8y ago

The abstraction is not really file but stream of bytes. It turns of any object with stream of bytes will need similar set of operations: open, create, read, write, close, seek etc. This is fairly generic and powerful abstraction.

cyphar 8y ago
The abstraction is a file descriptor. Not all things represented by file descriptors support read(2) or _llseek(2), but by representing them as file descriptors you can reuse other things like af_unix file descriptor passing.

fulafel 8y ago

Yeah, this was one of the headline changes in Plan 9 (the second OS made by the Fathers of Unix).

pjmlp 8y ago
And improved in Inferno, which fixed some of Plan 9 flaws, the third OS made by the Fathers of Unix that HNers keep forgetting about.

lunchables 8y ago

I thought "everything is a file" referred to user land.