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

71–80 of 311 posts

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

#71

Post by asim »

xxs wrote: post #49
asim wrote: post #23

Everything as a file was an interesting architecture in the 70s. The whole system was dependent on that model so it made total sense. In the 00s and beyond I thought everything as a service was a better model. Called through an API. Basically RPC. But even that has failed. It's very difficult to approach a new system from that perspective. I think you can design a protocol to say what the model of interaction should…

>Called through an API. Basically RPC This doesn't map well to hardware

Realistically neither do files. I think it really comes down to our common abstractions. Everything is IO. For the most part shared memory maps are what drives the most performance and ease of use.

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

#72

Post by t43562 »

mike_hearn wrote: post #59

The Plan 9 design wasn't as great as people like to think and it wouldn't have survived in the advertised form if Plan 9 actually had taken off. Actually it was already losing that aesthetic coherence quite early on in its lifetime. Hierarchical nouns, a fixed collection of verbs and a stream of bytes is aesthetically pleasing and can be helpful for developers hacking around, but is too limited and low level a vocabu…

A model need not be copied to be better. IMO there are lots of reasons for people to pursue their own ideas or ideas that don't require fundamental upgrades to their operating system.

I can also imagine doing the reverse of what you suggest in that libraries could implement fundamental mechanisms like RPCs and the file model would just be one form of interface to them. This would enable all programs to work to a minimum level with a new source or sink of data.

So you wouldn't need to rewrite code to be able to make it send data via your new RPC mechanism or dump data to your strange new distributed backup mechanism. That would be tremendously powerful.

If you had to do something very specific then the choice to access it via a more complex API would be there.

In fact if we forgot about files per se we could just look at models of access like: 1) sequential serial 2) low latency random access 3) heirarchical namespace 4) search-based namespace 5) high latency request/response

That way a file manager for example, could treat a namespace like my remote ssh drive differently from my local disk which offered low latency random access by not trying to generate thumbnails on it and not blocking while reading the names in it.

i.e. the file model is possibly too simple for its own good but that doesn't mean we couldn't make it better.

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

#73

Post by bmacho »

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.

Can't everyone design a better OS than the current operating systems? More features, easier to use as a user, safer, easier to write programs for it, less bugs, more compatibility, etc. I am using operating systems for years, and I have ideas how they should work on the surface.

But it will be slower, and won't have any useful software written for it, also you won't be able to use internet or your GPU. (To be fair several years ago I tried the HURD distribution ArchHurd. I just installed on it on my laptop, and by luck internet just worked, and had a firefox running so it was good.)

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

#74

Post by SubjectToChange »

exitb wrote: post #22
jrockway wrote: post #10

Earlier quoted context omitted.

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" bui…

Find is not simple - it's easy, but internally complex. It's fine to solve a complex problem with a complex tool, but it's troublesome when people mostly use it to solve simple problems. And the trouble is that this kind of approach spreads to every single component in the system, which means that we're using insane amount of code and cpu load to solve really simple problems on daily basis. Plan 9 is not an answer to…

…we're using insane amount of code and cpu load to solve really simple problems on daily basis.

Piping programs together is almost always going to use significantly more resources than one program doing it all. More code doesn’t necessarily imply more resource usage.

Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.

I don’t want to be all around negative about plan 9, but I don’t see it as really solving any interesting problems. Indeed it is far easier to write slim, elegant systems when forgoing feature parity and/or competitive performance.

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

#75

Post by xxs »

asim wrote: post #71
xxs wrote: post #49

Earlier quoted context omitted.

>Called through an API. Basically RPC This doesn't map well to hardware

Realistically neither do files. I think it really comes down to our common abstractions. Everything is IO. For the most part shared memory maps are what drives the most performance and ease of use.

According Linus (and everything is a file) "File" actually mean byte array/"stream of bytes"[0]. The latter maps proper well to all cache hierarchy.

[0]: https://yarchive.net/comp/linux/everything_is_file.html

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

#76

Post by arp242 »

comex wrote: post #32
pcwalton wrote: post #8

Earlier quoted context omitted.

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, sin…

zsh solves this with globbing qualifiers:

  ls -t *(Lm+10)
"L" for the "file size" qualifier (why "L"? For "less than size", I think – probably because "s" is already used for setuid), "m" for megabytes, "+" for "larger than". You can also add "om" or "Om" to sort by mtime, but ls will reorder it so you need the -t flag (or the -U flag to not sort things).

The syntax is not easy, even byzantine, but it's a lot less to type and pretty convenient in interactive shells.

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

#77

Post by ykonstant »

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.

Does this deal with arbitrary filenames (having newlines, control chars etc) correctly? Or does Plan9 forbid such filenames?

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

#78

Post by rcxdude »

xiphias2 wrote: post #66
zokier wrote: post #58

Earlier quoted context omitted.

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

it's a more modern API to system calls in general, though most of the focus is on IO.

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

#79

Post by ykonstant »

t0suj4 wrote: post #24
jrockway wrote: post #10

Earlier quoted context omitted.

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" bui…

After staring down find(1) on an AIX system I regret not going down the du | grep path. At least that way I wouldn't be stuck trying to mash GNU's parameters into completely incompatible version of find.

If your system supports `man 1p` (loading the posix manual for each supported utility), it is a good idea to reference that instead of the default manpage; it is more likely for your utility to support posix options than GNU extensions in legacy and non-linux systems.

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

#80

Post by arp242 »

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.

One problem I had is that I often just messed up the buttons, especially in the chords, and there's not a whole lot of feedback. I also messed up some things like letting go of the mouse button too soon by accident. Granted, I never spent that long with it, but it's not very mnemonic and requires some amount of motor skills I don't seem to have (e.g. in Vim "dw" is mnemonic for "delete word" and you get more feedback).

Plan 9 in general seems very much like a system "by the designers, for its designers" with not all that much attention to user-friendliness. To some degree that's also the case for Unix, but with Unix other people took the thing they made at Bell Labs and made it somewhat user-friendly (and even then, its received plenty of criticism for it). In Plan9 that step never really happened.

Post reply on HN