I’m not sure that people who think ”containers are just like VMs” should have any business working with containers.
Two Objects Not Namespaced by the Linux Kernel (2017)
51–59 of 59 posts
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#52> 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 t…
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.
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.
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#53> 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 t…
I thought "everything is a file" referred to user land.
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#54Earlier quoted context omitted.
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’…
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).
”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)
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#55Earlier quoted context omitted.
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…
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…
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)
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#56Earlier quoted context omitted.
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…
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)
No, the poster said: "unless you're a C++ hacker you can't actually work with most of it." That strongly implies COM. The Windows APIs are C.
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#57Earlier quoted context omitted.
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).
”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 t…
Great point.
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#58Earlier quoted context omitted.
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).
”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 t…
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).
Re: Two Objects Not Namespaced by the Linux Kernel (2017)
#59Earlier quoted context omitted.
This proposal implements clock offsets, but does it support continuous time scaling? One clock-handy use case would be to run your programs really slow or fast (or backwards!), for testing purposes. What use-case would you have for this? Making sure your program runs properly in the near presence of a black hole?
Your snark aside, clocks are not perfect, and a malfunctioning clock might speed up or slow down. Also, speeding up the clock is a technique already used in testing enviroments [1]. [1]: https://github.com/majek/fluxcapacitor
Sorry, I honestly didn't mean to be snarky. It was a genuine question. I couldn't really see the real-case justification for testing a clock that slowed down, sped up, or went backwards. But you're right, malfunctioning clocks would be an example.