Live data from Hacker News

Linux Namespaces Are a Poor Man's Plan 9 Namespaces

yotam.net

11–20 of 311 posts

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

#11
post #9
post #5

Earlier quoted context omitted.

Looking at the Unix to Plan 9 translation [1] gives me a different opinion. To name one egregious example, omitting find(1) in favor of piping du(1) (what is supposed to be a disk usage analyzer) to grep(1) is not an improvement; it's just user-unfriendliness in service of minimalist aesthetics. (Contrary to popular belief, find(1) is not a particularly "bloated" program; Rust's "fd" implementation is under 7,000 lin…

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.…

Realistically yes. But I would still use it.

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

#12
post #6

Could you do this with some kind of eBPF approach?

eBPF works because it only runs programs that pass its own static-analyzer - which basically means programs have to be specifically written for eBPF - you can't just take an arbitrary C program and have it run as an eBPF program.

The restrictions on eBPF programs are... legion, just count all the "No, you can't" answers in the FAQ: https://www.kernel.org/doc/html/latest/bpf/bpf_design_QA.htm...

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

#13
post #9
post #5

Earlier quoted context omitted.

Looking at the Unix to Plan 9 translation [1] gives me a different opinion. To name one egregious example, omitting find(1) in favor of piping du(1) (what is supposed to be a disk usage analyzer) to grep(1) is not an improvement; it's just user-unfriendliness in service of minimalist aesthetics. (Contrary to popular belief, find(1) is not a particularly "bloated" program; Rust's "fd" implementation is under 7,000 lin…

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.…

> If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched?

If the poor stitching were taken as a point of pride and the community refused to fix it, then yeah, I'd assume that that community values purity over practicality. Which is exactly how I feel about Plan 9: it had good ideas and was an improvement over Unix in many ways, but it was a regression in others, in large part due to choosing minimalist aesthetics over usability.

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

#14
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.…

> If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched? If the poor stitching were taken as a point of pride and the community refused to fix it, then yeah, I'd assume that that community values purity over practicality. Which is exactly how I feel about Plan 9: it had good ideas and was an improvement over Unix in ma…

But the fact is that you could get a decent find into Plan 9 in a day's work. Hell, you could probably just compile some existing Go version of find without any changes. Trying to get Plan 9-style namespaces into Linux is not nearly so trivial.

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

#15
post #7
post #5

Earlier quoted context omitted.

Looking at the Unix to Plan 9 translation [1] gives me a different opinion. To name one egregious example, omitting find(1) in favor of piping du(1) (what is supposed to be a disk usage analyzer) to grep(1) is not an improvement; it's just user-unfriendliness in service of minimalist aesthetics. (Contrary to popular belief, find(1) is not a particularly "bloated" program; Rust's "fd" implementation is under 7,000 lin…

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

Hear hear. When I use find I only use it for the recursive dir listing with no arguments. I always pipe it into grep because I know grep better.

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

#16
post #3
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.

Did it live too far in the future for the time?

Just as its sucessor, Inferno.

Which is what ChromeOS and Android are mostly today, leaving C to the kernel, or tiny special purpose libs, and everything else in a managed language, Limbo.

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

#17
post #7
post #5

Earlier quoted context omitted.

Looking at the Unix to Plan 9 translation [1] gives me a different opinion. To name one egregious example, omitting find(1) in favor of piping du(1) (what is supposed to be a disk usage analyzer) to grep(1) is not an improvement; it's just user-unfriendliness in service of minimalist aesthetics. (Contrary to popular belief, find(1) is not a particularly "bloated" program; Rust's "fd" implementation is under 7,000 lin…

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

And it makes easy things hard.

All the time arguments and size parameters and rules about depth and boolean syntax and the print0 for pipeline integration ... it makes me long for DOS interfaces from the 80s. There has to be a way to do it with less intellectual lifting every time.

Maybe just a simple set of bash reads will help - that's how I do ssh port forwarding - I was tired of getting confused.

Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video". (This would be at the frontend in this (currently) fictional helper script)

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

#18
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.

Never tried but I remember reading it was very dependent on the mouse. I probably wouldn't like it.

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

#19
post #16
post #3

Earlier quoted context omitted.

Did it live too far in the future for the time?

Just as its sucessor, Inferno. Which is what ChromeOS and Android are mostly today, leaving C to the kernel, or tiny special purpose libs, and everything else in a managed language, Limbo.

And how close is Go to Limbo?

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

#20
post #14

Earlier quoted context omitted.

> If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched? If the poor stitching were taken as a point of pride and the community refused to fix it, then yeah, I'd assume that that community values purity over practicality. Which is exactly how I feel about Plan 9: it had good ideas and was an improvement over Unix in ma…

But the fact is that you could get a decent find into Plan 9 in a day's work. Hell, you could probably just compile some existing Go version of find without any changes. Trying to get Plan 9-style namespaces into Linux is not nearly so trivial.

It's not about "find" in particular, that was just an example brought up to illustrate the general point. If "find" was the only thing missing to bring Plan9 up to Linux usability standards, that would indeed be easy to fix.
Post reply on HN