Linux Namespaces Are a Poor Man's Plan 9 Namespaces
1–10 of 311 posts
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#2As 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
#3As 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?
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#4The pros argument seems a little disingenuous/backwards - plan 9 brought the future including things like /proc - which was implemented in UNIX.
I loved a lot of the ideas on plan 9, but it really was unusable as a day to day environment.
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#5As 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.
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 lines of code [2], about a third of the size of Lua.)
[1]: https://9p.io/wiki/plan9/Unix_to_Plan_9_command_translation/...
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#6Could you do this with some kind of eBPF approach?
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#7As 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.
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
#8Earlier 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.
I agree with you to some extent, but the solution is fd: change the tool's interface to make simple things easy. Deleting the tool entirely does nobody any favors. As bad as find(1) is for simple stuff, piping du(1) to grep(1) is worse.
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#9As 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.
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?
Re: Linux Namespaces Are a Poor Man's Plan 9 Namespaces
#10Earlier 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.
Is that a problem? A simple tool is good if it can solve complex problems, but a simple tool that can't is just an underdeveloped tool. Sometimes you need a complex tool to solve a complex problem.
I think a good mini language bridges the gap between interactive commands and programming. Sometimes you need to spend an hour writing a program to do something complicated. But because of various "extraneous features" built into UNIX commands, you rarely need to spend an hour manually poking at the filesystem. The mini language gets you almost as productive as a full-fledged programming language, without feeling like you're programming. (How do you know you're programming? If you "git init" and start committing stuff, you're probably programming. If your carefully-crafted thing scrolls into .history obscurity, then you're interacting.)