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.…
Linux Namespaces Are a Poor Man's Plan 9 Namespaces
11–20 of 311 posts
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#12Could you do this with some kind of eBPF approach?
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
#13Earlier 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 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
#14Earlier 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…
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#15Earlier 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.
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#16As 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?
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
#17Earlier 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.
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
#18As 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.
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#19Earlier 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.
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#20Earlier 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.