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

121–130 of 311 posts

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

#121

Post by mpweiher »

afr0ck wrote: post #47

The simple, everything is a file, model of Plan9 is what makes the namespaces API as clear and as general as it is. All the objects export the same file API. Every interaction with the OS objects is done through file open, create, read, write, etc. But it has it's drawbacks. First, it's not always easy to map every object operation into either an open read or write. With time, we should have seen a lot of ugly interf…

Storage Combinators manage to unify a lot of this with a somewhat nicer, REST-based and object-oriented interface (they came out of something I called in-Process REST). Byte-oriented interface are much easier to fit on top of that than the other way around.

Almost more importantly, they don't claim to be universal. Instead, you can still send messages where that makes sense. The approaches are much simpler and powerful when combined than when each tries to be everything. Yes, you are allowed to say "synergies".

With the corresponding object streams (that can be specialised to byte-streams as well), we have something I like to call Plan A from Userspace.

https://2019.splashcon.org/details/splash-2019-Onward-papers...

https://objective.st

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

#122

Post by exitb »

SubjectToChange wrote: post #74
exitb wrote: post #22

Earlier quoted context omitted.

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…

> More code doesn’t necessarily imply more resource usage.

That's true! Yet, somehow we found ourselves in a situation where most people use computers, to chat, read news etc, all of which would be possible with much less resources. All done with the use of platforms that we literally can't rewrite, as they're too complex. It's certainly not find's fault, but the complexity creep starts somewhere.

Plan 9, as a research OS, is not a useful platform to base your next business on, but it does serve as a baseline we can relate our "real" platforms to.

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

#123

Post by jlokier »

arp242 wrote: post #68
geosh wrote: post #57

Earlier quoted context omitted.

... | xargs grep -Hn regex This will also be faster, because you fork less.

Using \+ instead of \; will do the same (fork less). du -a will need to do a stat to get the file size, which is comparatively expensive; I don't think find will (not sure)?

You're right, find won't call stat() unless it needs to. It doesn't need to for recursing through the directory tree because readdir() returns dirent.d_type these days to determine if a name is a directory.

Yes, those stat() calls can be very slow in aggregate on a large tree, especially from HDD (due to seeking) or network filesystem, if the stat information isn't already in cache.

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

#124

Post by samus »

TwentyPosts wrote: post #94
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?

The operation system already very much behaves like an object-oriented system, even in a languages without language support for this: you ask the OS for a handle, which has to be passed as the first argument to any system call. The kernel has figure out what object the handle refers to and redirect the call to the appropriate subsystem. This is abstraction and polymorphism. And of course, the kernel won't give you any access to internals by default, which gives you encapsulation.

The argument of GP is that file-oriented interfaces like `rewind` or `seek` are ill-suited for anything that doesn't behave like a seekable file. `read` and `write` work well for anything with a streaming interface, but are utterly unsuitable for things like processes. You'd have to layer protocols on top of it.

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

#125

Post by mikepurvis »

randomdata wrote: post #26
pcwalton wrote: post #13

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

The big lesson Plan 9 seemed to have learned is that maintenance is a drag and a hinderance. find may be objectively better than du | grep for the user, but once introduced then the developers have to essentially maintain the same thing twice and carry that baggage forever into the future. In a parallel universe where Unix did not take on so much baggage, perhaps it could have even naturally evolved towards Plan 9 an…

I always feel guilty that find . | grep is easier for me than remembering how find's flags work. But I think it's really a case of my brain rejecting exactly the redundant baggage you're speaking of here.

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

#126

Post by pomalat »

miga wrote: post #96

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…

wrt #4: No, the big thing about Plan 9 is that each process has its own view of the filesystem, and can modify it without any privileges. This would break the unix security model because unix has setuid.

Quote from https://utcc.utoronto.ca/~cks/space/blog/unix/WhyNoUserNames...:

> Imagine that Unix had this feature and still had setuid, and you would like root privileges. No problem; make a custom namespace for /etc that has a version of /etc/shadow, /etc/group, and /etc/sudoers that have known passwords and list you as authorized. Now run sudo. Done.

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

#127

Post by hardware2win »

prmoustache wrote: post #40
stefncb wrote: post #25

Earlier quoted context omitted.

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.

Context switch??

After longer usage you do that without any thinking

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

#128

Post by bmacho »

bmacho wrote: post #73
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 se…

edit: probably I did not even install it, but it was a live system.

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

#129

Post by bufio »

phrenicfraud wrote: post #95
didntcheck wrote: post #55

Earlier quoted context omitted.

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.

User error.

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

#130

Post by arp242 »

stefncb wrote: post #116
arp242 wrote: post #80

Earlier quoted context omitted.

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…

I learned the chords very quickly, but everyone works differently. What kind of feedback exactly would you expect from it? I can't immediately think of anything that would make it much better. I guess animations could help, but then they might just be distracting. I think the main thing people get confused by besides the chording is the teleporting of the cursor, but then you realize it's actually really useful once…

> What kind of feedback exactly would you expect from it?

I don't know exactly; this is one of those things where I'd have to implement some things and play around to see what works. Something like some text popping up maybe? I don't know. More advanced users can always just disable these sort of things (I also set up my Vim to not show "-- INSERT --" because at this point it's never helpful for me and it looks a bit nicer this way, but obviously for loads of people it's a very helpful thing).

Post reply on HN