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

221–230 of 311 posts

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

#221

Post by lproven »

rhabarba wrote: post #216
lproven wrote: post #209

Earlier quoted context omitted.

I think that you misunderstand my point here. As far as the UI goes, the critical distinction is not about how it looks on screen or how it is rendered, it's about modal versus nonmodal user interfaces. I happened to side with Larry Tesler on this: "don't mode me in!" As far as Emacs goes, I was more thinking about its strange set of user interface conventions and terminology, which pre-date (and conflict with) indus…

All text editors are modal editors though, all text editors have a command mode and an input mode. In (q)ed/ex/vi and their direct and/or spiritual successors, you'll reach Command Mode by pressing Escape. In Emacs, it's Ctrl/Alt/Meta. In Acme, it's the mouse. Even editors which (almost?) follow the CUA standards have a Command Mode - using the Ctrl modifier key.

I think that may be over-generalising a point into irrelevance.

All editors have commands of some kind, yes. Otherwise, it's not an editor.

But holding down a modifier key is not a mode in the software. You could sort of argue it's a mode of the keyboard,. or of the key, but I think it's over reaching.

I've seen editors with no menus, no visible UI at all, just hotkeys that do stuff. It is still a UI even if it is not visible. There are apps for blind Windows users with no visible presence on the screen at all, such as the Qwitter Twitter client.

If pressing the Ctrl key suddenly made the app switch into a different type of operation until you pressed it again, that might count, but it doesn't. The app doesn't even need to know. It just knows "keycodes #F to #Z enter letters, but #A to #E are commands". There are no modes here.

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

#222

Post by thesuitonym »

arp242 wrote: post #80
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.

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"

It definitely is that. That's a really great thing when the designers needs and assumptions match your own, but if they don't, you end up wondering what these bozos were thinking.

For what it's worth, Rob Pike was a big proponent of the mouse-driven design, and he has some very thoughtful essays/articles/emails about why he feels that way. I can't say I agree with him 100%, but it's clear that the decisions weren't arbitrary.

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

#223

Post by crabbone »

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…

Wait until you realize you need asynchronous I/O operations, and then you also need to manage caching on I/O operations, and you also need to distinguish appends from over-writes, and that you also need to care about who allocates memory for the buffer being written to / read from...

And then comes concurrency and exceptions... UNIX "design" anticipated none of the above. And it's not like these things were somehow unknown at the time. The "designers" thought they are making something remarkable by cutting corners and making a "simple" (but really a half-baked) OS.

It's such a shame that UNIX became the vector for the spread of the Internet and eventually infected virtually every computer system on Earth. It's even a greater disappointment that its "design" decisions are still revered as the holy Bible in academia and in the industry.

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

#224

Post by tytso »

lproven wrote: post #148
miga wrote: post #99

Earlier quoted context omitted.

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…

It doesn't need cgroups or containers, because every process has its own namespace, its own view of the network-global filesystem, so everything is in a container by default. It doesn't need a microkernel, because the concept of microkernels is to split a big monolithic kernel into lots of small simple "servers" running in user space, and have them communicate by passing messages over a defined communications protoco…

Cgroups are a lot more than just "namespaces". It is also the mechanism by which you can constrain how much CPU, Memory, Network Bandwidth, Storage IOPS or Throughput, etc., processes in a particular cgroup or container can use.

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

#225

Post by hdidhdish »

jerf wrote: post #187
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…

I wrote a while ago about how Go is more UNIX than UNIX, which in context really meant is more Plan 9 than Plan 9: https://www.jerf.org/iri/post/2931/ The idea there is that the particular way interfaces work in Go is possibly the way that Plan 9 should have worked. In reality, trying to fit everything into a file is still non-functional, because not everything is a file. But if you instead have a hierarchy of interf…

so golang is a poor man's erlang?

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

#226

Post by rhabarba »

lproven wrote: post #221
rhabarba wrote: post #216

Earlier quoted context omitted.

All text editors are modal editors though, all text editors have a command mode and an input mode. In (q)ed/ex/vi and their direct and/or spiritual successors, you'll reach Command Mode by pressing Escape. In Emacs, it's Ctrl/Alt/Meta. In Acme, it's the mouse. Even editors which (almost?) follow the CUA standards have a Command Mode - using the Ctrl modifier key.

I think that may be over-generalising a point into irrelevance. All editors have commands of some kind, yes. Otherwise, it's not an editor. But holding down a modifier key is not a mode in the software. You could sort of argue it's a mode of the keyboard,. or of the key, but I think it's over reaching. I've seen editors with no menus, no visible UI at all, just hotkeys that do stuff. It is still a UI even if it is no…

I’m not even sure if the point IS relevant at all. The software-side difference between “the user pressed I, am I in command mode?” and “the user pressed I, did he also press Ctrl?” is not that big.

Granted, one is Shift and one is Caps Lock…

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

#227

Post by numbsafari »

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…

> it's not always easy to map every object operation into either an open read or write

A lot of what defines REST works well here. The "Uniform Interface" creates a simple API that can scale to a surprising amount of functionality.

Not saying it doesn't have it's downsides, but you can accomplish a lot with minimal increase in the surface area of that "uniform interface".

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

#228

Post by bwanab »

crabbone wrote: post #223
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…

Wait until you realize you need asynchronous I/O operations, and then you also need to manage caching on I/O operations, and you also need to distinguish appends from over-writes, and that you also need to care about who allocates memory for the buffer being written to / read from... And then comes concurrency and exceptions... UNIX "design" anticipated none of the above. And it's not like these things were somehow u…

What's an existing example of a non-'half-backed' OS?

I personally liked VMS for concurrency, but for dealing with code and coding there was no contest that Unix was far better. I think the reality is they're all half-baked since none can satisfy every need.

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

#229

Post by taeric »

hardware2win wrote: post #127
prmoustache wrote: post #40

Earlier quoted context omitted.

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

Ish. Just changing where you are oriented can impact how some people are thinking. By nature of their orientation.

Moving to a mouse primes my brain to start thinking spatially about things. Which is not something I'm typically doing when looking at textual/symbolic things. I can see some value in doing it, of course.

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

#230

Post by vilunov »

nine_k wrote: post #176
torginus wrote: post #45

Earlier quoted context omitted.

I personally don't like WASM. I think the Native Client (which is more than a decade old today) was a much better technical solution. It used actual cpu native assembly bundled with a verifier, and had actual good integration into low-level platform APIs like graphics, threading, etc. instead of using this weird Javascript bridge approach. Due to it being native code from the start, it also had none of the startup pe…

Actual CPU native assembly? It would need to support x86, x64, and aarch64 by now. (And likely RISC-5 in the near future.) The point of VMs like WASM is not (specifically) performance though, even if performance is desirable. It's the minimal, fixed standard, and the isolation. If you badly need native performance, develop a native application %)

Or it could get translated to the target ISA by the user-agent Rosetta-style, suffering the same warmup issues, but only on some architectures.
Post reply on HN