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

31–40 of 311 posts

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

#31

Post by doctor_eval »

pcwalton wrote: post #5
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.

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…

Perhaps depends on your definition of “user friendly” - Find is certainly not going to be at the top of my own list. Half the time I use ls -lR | grep because I can’t be bothered to rediscover the right find option - which won’t even do what I want the first time I try it.

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

#32

Post by comex »

pcwalton wrote: post #8
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.

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.

That's half of the solution. The other half, I'm convinced, will be a tool that makes complex things possible. After all, if I really need some complex filtering, find's primitive logical operators probably wouldn't even be sufficient. To that end, I love how Nushell's leading example on their home page is

    ls | where size > 10mb | sort-by modified
It seems so elegant! Down with strings! …But it's not my life yet, since last time I wanted to try Nushell they didn't have scripting yet, and I have yet to circle back around to it. There's also Elvish and PowerShell and Oil Shell but they all have their own issues.

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

#33

Post by Un1corn »

totallywrong wrote: post #18
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.

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

Yes, Plan 9 made some bad choices in retrospect, at least in my opinion. The big dependency on the mouse is one of them but also assuming people will be in managed networks.

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

#34

Post by vbernat »

doctor_eval wrote: post #31
pcwalton wrote: 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…

Perhaps depends on your definition of “user friendly” - Find is certainly not going to be at the top of my own list. Half the time I use ls -lR | grep because I can’t be bothered to rediscover the right find option - which won’t even do what I want the first time I try it.

Then you can use "find | grep".

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

#35

Post by afr0ck »

jjtheblunt wrote: post #19
pjmlp wrote: post #16

Earlier quoted context omitted.

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?

If I remember correctly, they have similar concurrency models. They were both written the same author as well, Rob Pike.

Edit: fixed a typo

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

#36

Post by jabl »

pcwalton wrote: post #5
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.

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 would guess the minimalism was a practical choice at the time, given it was a pretty small team making an entire OS. Had Plan 9 ever become some kind of commercial (or even open source) success, I'm sure a find command would eventually have found its way in.

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

#37

Post by skissane »

kristopolous wrote: post #17
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.

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…

> and the print0 for pipeline integration

The existence of things like `-print0` is the downside of Unix's "all files/pipes are byte streams" design decision.

The IBM mainframe implementation of the pipeline idea – CMS Pipelines [0] – makes pipes record-based instead. Since the pipes are not streams of bytes, rather records with out-of-band boundaries, there is no need to reserve a special character (whether LF or NUL) to serve as a record separator.

> Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video"

It is a pity that Unix never had a "file type" field in the filesystem, unlike classic MacOS, Acorn RISC OS, among others. I suppose both those systems had the limitation that the file type was just a number, subsequent experience has demonstrated it needs to be a much longer string (such as a MIME type or Apple UTI). The problem with file extensions is the same extension ends up being used by completely unrelated applications for completely unrelated file formats – e.g. nowadays .doc is normally assumed to be legacy binary Microsoft Word, but many older archives it is a plain text file instead, or sometimes even some other word processing format.

[0] https://en.wikipedia.org/wiki/CMS_Pipelines

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

#38

Post by foul »

pcwalton wrote: post #5
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.

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…

Yeah find is a bad example for bloat, compared to GNU echo or GNU yes. find AFAIK is mentioned more for horror stories, Bernstein insults, as an example for alien parts of UNIX-like OSes which prevent from a streamlined, predictable-in-your-head experience. "It isn't windows server", a statement which devoids of meaning sometimes with powershell and with Azure cloud apis, but eh.

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

#39

Post by nine_k »

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.

Plan 9 had many improvements over Unix of its times. It opened up too late to conquer the world though. Some good things from it were imported into Solaris and Linux later.

Technological progress likes to reinvent itself, looping back to the same idea that did not work last time, and maybe making it a hit finally. Two examples:

- Apple Newton, 1992 (a flop) -> Palm Pilot, 1997 (niche success) -> Apple iPhone, 2007 (world domination).

- Java Virtual Machine, 1994 (server-side world domination, a flop in the browser) -> Inferno OS, from the makers of Unix and Plan9, 1996 (a flop) -> WASM (prospects of world domination in the browser).

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

#40

Post by prmoustache »

stefncb wrote: post #25
totallywrong wrote: post #18

Earlier quoted context omitted.

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

It is, but for what it's worth using the mouse is much more pleasant than what we're used to ime. It's weird at first, especially with the teleporting thing but it works really well. Also, if you're gonna try it do it either with a proper three-button mouse or with a large-ish and easy to press scroll wheel button. Otherwise it's really frustrating.

Just the idea of context switching from mouse to keyboard is so annoying to me outside of graphic editing. I installed vinium for firefox recently and it has been a game changer.
Post reply on HN