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

91–100 of 311 posts

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

#91

Post by what_the_h321 »

codedokode wrote: post #89

"Everything is a file" is not a good idea, because different objects have different interfaces. For example, a network socket is not a file because you cannot seek it. A process is not a file because you cannot send signals to a file. This also caused appearance of syscalls like ioctl - very ugly solution. Ioctl is a large and undocumented API. Pseudo-filesystems like /proc or /sys are also examples of undocumented A…

In Plan9 they implemented signals using the filesystem https://news.ycombinator.com/item?id=3077504

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

#92

Post by depr »

somnium_sn wrote: post #86

I don't know how zones were implemented in Solaris, but since the article brings up docker, I feel the original zones implementation in Solaris is a still significnatly better user experience than docker or anything similar on Linux. The combined stack of zones + crossbow and zfs was just a pleasure to work with.

There is a paper called "Solaris Zones: Operating System Support for Consolidating Commercial Workload".

It mentions aspects such as:

"At the most basic level, the kernel identifies specific zones in the same fashion as it does processes, by using a numeric ID. The zone ID is reflected in the cred and proc structures associated with each process. The kernel can thus easily and cheaply determine the zone membership of a particular process. This mapping is at the heart of the implementation."

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

#93

Post by phrenicfraud »

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.

And then replies slowly devolve into arguing about irrelevant things that were solved with the existence of Linux because plan9 sucks and Linux is just a kernel which is actually used by people and therefore they actually found ways to solve problems they were most annoyed by.

All these "X is poor man's Y" are a cope. Plan9 is poor man's because noone uses it. I'm sure on most people the irony of this statement will be lost, so I'm gonna explain: yeah, plan9 is better on paper, too bad we live in glass world.

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

#94

Post by TwentyPosts »

codedokode wrote: post #89

"Everything is a file" is not a good idea, because different objects have different interfaces. For example, a network socket is not a file because you cannot seek it. A process is not a file because you cannot send signals to a file. This also caused appearance of syscalls like ioctl - very ugly solution. Ioctl is a large and undocumented API. Pseudo-filesystems like /proc or /sys are also examples of undocumented A…

>Instead of "everything is a file", "everything implements well-documented object-oriented interfaces" would be much better idea. Why "object-oriented" specifically? Is this in any sense different from non object-oriented interfaces, eg. Rust's traits or Go's interfaces, or just to make it more clear that you're talking about interfaces in the programming languange sense?

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

#95

Post by phrenicfraud »

didntcheck wrote: post #55
tsss wrote: post #48

Earlier quoted context omitted.

The same person who is involved with Plan 9 also made Go. Taking one look at that programming language doesn't leave me very optimistic about Plan 9.

Agreed. Go is a shining example of Unix philosophy - but I don't mean that as a compliment. I mean it prioritizes ease of implementation over any other concerns and hence forces the user to reinvent many wheels. Forces round things into square holes, regardless of if that interface actually makes sense. And either completely ignores good ideas from other camps or goes sour grapes and claims they're overcomplicated an…

I remember trying to figure out what's up with Go and left in complete disbelief when I was told that I need to install nginx on my local machine and fake a DNS entry just for go's package manager to "fetch" my local package from my local machine just so I could mess around with it how that works.

All because I couldn't care less about 3rd party services like github.

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

#96

Post by miga »

I disagree with the author:

1. We could gradually port Linux `ioctl` to Plan9 namespaces, if there was understanding they greatly simplify Docker.

2. Docker and virtualization are one of most important applications of Linux, but there is still not even a proof-of-concept implementation of such on Plan9.

3. We don't need a complete rebuilding of Linux to make it more like Plan9. Both Windows and Mac OS X is an example of system that underwent radical redesigns of several subsystems.

4. All features of Plan9 could be brought to Linux by adding modules for alternative system interfaces, and deprecating old ones or blocking them with security capabilities.

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

#97

Post by phrenicfraud »

rhabarba wrote: post #64
tsss wrote: post #48

Earlier quoted context omitted.

The same person who is involved with Plan 9 also made Go. Taking one look at that programming language doesn't leave me very optimistic about Plan 9.

> The same person Go was designed by: - Robert Griesemer, known for nothing else, - Rob Pike, primarily known for sam(1), acme(1) and several other Plan 9 tools, the Blit (Unix's own graphical terminal), UTF-8 (with Ken Thompson), Inferno and Limbo, - and Ken Thompson, ancient god.

All these things you listed are objectively bad and a tumor and I'm glad that those that are gone, are gone for good, because the one that stayed is a menace to any programmer caring about his sanity.

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

#98

Post by mrAssHat »

codedokode wrote: post #89

"Everything is a file" is not a good idea, because different objects have different interfaces. For example, a network socket is not a file because you cannot seek it. A process is not a file because you cannot send signals to a file. This also caused appearance of syscalls like ioctl - very ugly solution. Ioctl is a large and undocumented API. Pseudo-filesystems like /proc or /sys are also examples of undocumented A…

Huh? Have you never written stuff to files procfs or sysfs?

Not every file there is seekable/readable - some only exist as an input interface to change some property.

The very same way there could exist a 'signals' file to write signals to.

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

#99

Post by miga »

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.

Article mentions that Plan9 missed `cgroups`, QoS.

Linux moves towards massive process sharing, and thus various of sharing controls are key to the future that is missing from 90s operating systems.

Just enable sound, run your browser and music app, and count number of processes living with `ps ef|wc -l`. I see 282 kernel threads, and 536 total processes. You will see that we live in the future, because of extensive modularization of system services, and cannot get back without sacrificing reliability and comfort.

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

#100

Post by [deleted] »

skissane wrote: post #37
kristopolous wrote: post #17

Earlier quoted context omitted.

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

[deleted]
Post reply on HN