Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Namespaces Are a Poor Man's Plan 9 Namespaces

yotam.net

Post reply on HN
Print view View original

61–70 of 311 posts

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#61

Post by hutzlibu »

didntcheck wrote: post #52
wbl wrote: post #7

Earlier quoted context omitted.

The problem with find is that it tries to put an entire programing language into its arguments.

Sure, which lends weight to the idea that the shell should be a more extensive programming language. Then you can pass an arbitrary Predicate to the finder (which would likely just be a convenience function of about 5-20 lines), and receive a list of file objects for you to do what you want with That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has b…

"That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has become so ubiquitous and influential that we've forgotten that programs could pass more than ill-specified strings around ... The first step would be to stop putting "Unix philosophy" on a throne "

Well yes, but I think it will be hard or rather impossible to convince the unix crowd of anything good coming from windows.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#62

Post by somat »

amoss wrote: post #42
floren wrote: post #9

Earlier quoted context omitted.

I got used to `du | grep` after using Plan 9 a lot and still do it on Linux, but yeah really I think Plan 9 fans have had a tendency to ossify the pragmatic minimalism of the Bell Labs guys into a sort of cultishness... there's no reason we couldn't have find on Plan 9, but now it's almost a religious point not to have it. On the other hand, the lack of find is not a particularly good rebuttal to the original point.…

The thing that I use find for most commonly is to perform a hierarchical grep, i.e find . -exec grep -Hn regex \{\} \; How would you do that with the du | grep combo?

grep -R

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#64

Post by rhabarba »

tsss wrote: post #48
DiabloD3 wrote: post #2

As of someone who discovered Plan 9 far too late to do anything about it: everything is a poor man's Plan 9 something. Everything. All of it. Plan 9 lived in the goddamned future.

The same person who is involved with Plan 9 also made Go. Taking one look at that programming language doesn't leave me very optimistic about Plan 9.

> The same person

Go was designed by:

- Robert Griesemer, known for nothing else,

- Rob Pike, primarily known for sam(1), acme(1) and several other Plan 9 tools, the Blit (Unix's own graphical terminal), UTF-8 (with Ken Thompson), Inferno and Limbo,

- and Ken Thompson, ancient god.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#66

Post by xiphias2 »

zokier wrote: post #58
afr0ck wrote: post #47

The simple, everything is a file, model of Plan9 is what makes the namespaces API as clear and as general as it is. All the objects export the same file API. Every interaction with the OS objects is done through file open, create, read, write, etc. But it has it's drawbacks. First, it's not always easy to map every object operation into either an open read or write. With time, we should have seen a lot of ugly interf…

> First, it's not always easy to map every object operation into either an open read or write. Heck, even for basic files on disk, and even more so for sockets, the traditional open/read/write/close is starting to feel not so great. There is reason why iouring is hailed as the second coming, and it solves just part of the problems; stuff like fsync apocalypse comes to mind. And ioctls are imho completely disgusting h…

io_uring is a more modern API to file access. Actually I think it would be great if everything was a file and the communication with the kernel was only with io_uring.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#67

Post by esjeon »

To be fair, even the namespace design of Plan 9 isn't very elegant, because file-base API hits its own limit pretty quickly. Linux had to abuse `ioctl` to avoid that.

The best namespace design should come from the microkernel world, where isolation can be achieved by simply rerouting outgoing API calls to alternate servers. This will also allow injecting all kinds of crazy/complicated policies in the middle.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#68

Post by arp242 »

geosh wrote: post #57
amoss wrote: post #42

Earlier quoted context omitted.

The thing that I use find for most commonly is to perform a hierarchical grep, i.e find . -exec grep -Hn regex \{\} \; How would you do that with the du | grep combo?

... | xargs grep -Hn regex This will also be faster, because you fork less.

Using \+ instead of \; will do the same (fork less).

du -a will need to do a stat to get the file size, which is comparatively expensive; I don't think find will (not sure)?

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#69

Post by jabl »

akira2501 wrote: post #60
afr0ck wrote: post #47

The simple, everything is a file, model of Plan9 is what makes the namespaces API as clear and as general as it is. All the objects export the same file API. Every interaction with the OS objects is done through file open, create, read, write, etc. But it has it's drawbacks. First, it's not always easy to map every object operation into either an open read or write. With time, we should have seen a lot of ugly interf…

> First, it's not always easy to map every object operation into either an open read or write. It doesn't seem like it. Linux has a habit of multiplexing alternate functions through a single handle with additional and somewhat scary methods like ioctl. Plan9 manages this with servers, directories, and more than one path available for a single resource depending on what you're trying to access. This is far more sane.…

For an example, most high performance devices expose functionality as memory locations mapped into the CPU address space. In many cases it's necessary to allow userspace direct access to (part of) the memory the device exposes, such as with GPU's, RDMA NIC's and so forth. Not sure you could get high performance with a read/write stream based interface, as conceptually elegant such an interface is.

Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces

#70

Post by iopq »

didntcheck wrote: post #52
wbl wrote: post #7

Earlier quoted context omitted.

The problem with find is that it tries to put an entire programing language into its arguments.

Sure, which lends weight to the idea that the shell should be a more extensive programming language. Then you can pass an arbitrary Predicate to the finder (which would likely just be a convenience function of about 5-20 lines), and receive a list of file objects for you to do what you want with That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has b…

Unix being stringly-typed is a huge problem.

For example, I found a flatpak of a system monitor and thought it was portable. Turns out, it parses `ps` output directly, but it's not compatible with BusyBox `ps` output

https://github.com/hakandundar34coding/system-monitoring-cen...

the author literally doesn't care since it works with coreutils `ps`

it's a culture problem

Post reply on HN