Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Plan 9 from Bell Labs

github.com

Post reply on HN
Print view View original

61–70 of 90 posts

Re: Plan 9 from Bell Labs

#61

Post by black_knight »

Sir_Cmpwn wrote: post #43
simonblack wrote: post #42

Earlier quoted context omitted.

But how do you 'paste' without a middle button? That's the bit I miss most when I have to use a 2-button mouse. Thank god the guys who invented the scroll-mouse had the sense to build the middle-button into the scroll-wheel axle.

I'm not against a three-button mouse, I'm against its overuse. Example: in plan9, you can't hit "up" to re-use the last command you typed into a terminal. You have to copy+paste it with your mouse.

Not quite true. The command "" (much like bash's !!) runs the previous command you entered. It can also be given a prefix of a command and search the history for this command.

See wintext(1).

Re: Plan 9 from Bell Labs

#63

Post by black_knight »

bastawhiz wrote: post #45

Can someone explain why Plan 9 matters? I mean this legitimately. How is this differentiated from yet another flavor of *nix? I'm sure it was hot shit back in the early 90s, but I don't see much of an appeal other than as a curiosity like OS/2.

What I find most amazing is how the kernel is more like a file system multiplexer. Its job is to present a file system to each process built from mounting virtual file systems from all sorts of programs and remote machines.

If I want to access files from a remote machine — mount its file system. Want to play my music from my laptop using the speakers connected to my stationary computer — mount its sound card into my device folder. If want to use another machine as a network gateway — I mount its /net.

Even the editor acme has its own file system, which makes writing a script doing something fancy in my editor really easy. The file system gives easy access (read/write) to anything from the currently selected text in each window, to the "menu" at the top (called the tag). And if I write a script, it is executed anywhere in acme by middle clicking its name.

What makes this all work smoothly is that mounted file systems can overlap, and that each process is presented its own name space. This completely removes the need for symbolic links and unix sockets.

Re: Plan 9 from Bell Labs

#64

Post by jamespo »

rcarmo wrote: post #35
mischief6 wrote: post #29

Earlier quoted context omitted.

http://www.jonschneider.com/images/jsblog/ThinkpadTrackpoint... works for me! btw, you can simulate mb 2 and 3 by holding down keyboard modifiers while clicking mb1.

Well, then, I'll just go and get rid of my Macs. And the Magic Trackpads I use on my desktops, too. Not really, no.

Well that's the problem with locked in proprietary hardware

Re: Plan 9 from Bell Labs

#65

Post by 1ris »

edwintorok wrote: post #60
nsajko wrote: post #23

Earlier quoted context omitted.

Relevant SSH bashing: http://harmful.cat-v.org/software/ssh :)

So what is Plan9's alternative to SSH? SSL seems even worse than SSH in terms of algorithms that you have to negotiate, and thanks to misconfigurations you can end up in a situation with no shared ciphers (if server accepts only RC4 and client rejects RC4 for example). Maybe tinyssh could qualify as an alternative...

There is cpu for plan9. It's a remoteshell does does mount the local filesystem, so you can continue to work.

I don't think tinyssh is less complex, as it is compatible.

Re: Plan 9 from Bell Labs

#66

Post by mhd »

ThomPete wrote: post #4

As an interface designer Plan9 have always fascinated me yet I found it incredible hard to find many other designers who were into it's concepts. I always loved the "everything is an object" approach and in a better world this not NeXT or Windows would be our underlying principle.

> I always loved the "everything is an object" approach

Which sadly isn't at all what Plan9 does, in the usual "worse is better" way of Unix. Objects would allow a bit more versatility than the "everything is a file, usually one with plain UTF-8 text" approach. (And actually, Windows is closer to an object world with COM, as evidenced by e.g. the core model of PowerShell)

Of course, an object-model has a hard time when the rest of the world and the net is talking in files, you're also much more likely to create a walled garden.

As for simplicity, I can understand that regarding systems like Smalltalk (or possibly lisp machines), although Oberon serves as a prime counter-example here. It did inspire the Acme editor, and here you can see that if your basic text model is objects, not just a byte-stream, some extensions are easier to do (different fonts, syntax highlighting, widgets).

And yes, I'm aware that the usual response to that was and is "you don't need that". Milages obviously do vary.

Re: Plan 9 from Bell Labs

#67

Post by soong »

donatj wrote: post #46
bastawhiz wrote: post #45

Can someone explain why Plan 9 matters? I mean this legitimately. How is this differentiated from yet another flavor of *nix? I'm sure it was hot shit back in the early 90s, but I don't see much of an appeal other than as a curiosity like OS/2.

It's more *nix than unix. Everything is a file. UI interaction is done via files. It doesn't cut corners at it - it takes it to the extreme. It is the logical successor to unix that never took off because unix is "good enough"

Yes, one can't stress enough how much Plan 9 is not Unix. When Bell Labs eventually gave up on Research Unix and started from scratch they deliberately broke with almost every standard and convention in existence.

The programming language (Plan 9 has its own C dialect), breaking with POSIX, abolishing the process/thread dualism and doing away with the root user just to name a few.

By getting rid of all these inherited liabilities they were able to create a much slicker, much more uniform and most importantly truly network centric OS, which in many aspects (not necessarily in terms of performance) still surpasses modern unix-derived operating systems(you know...the usual suspects). On the other hand the lack of backwards compatibility and the high barrier of entry prevented Plan 9's widespread adoption outside the research community.

On the contrary if we need new functionality today the way to go seems to be piling new layers of abstraction on top of the already overly complex stuff we gatherd over the years until everything becomes an incomprehensible mess of special cases(16 million loc linux kernel, anyone?). That of course is a good ol' tradition, which started when we first fumbled network support into the unix kernel and thereby broke the open-read-write-close interface convention.

To summerize: Plan 9 is not Unix. Thankfully...

Re: Plan 9 from Bell Labs

#68

Post by rian »

Sir_Cmpwn wrote: post #16
rcarmo wrote: post #15

Earlier quoted context omitted.

Yeah, but that makes sense at the OS level. UX-wise (and generally speaking, for most common uses of a computer these days), Plan9 is, sadly, almost useless. I myself only use it because I _like_ messing about with different (and arguably better) operating systems, but it's very, very, VERY hard to do so for general "work" or even browsing the web.

I've considered spending time on plan 9 making the UX less crappy. I think the stuff under the covers is fantastic but the UX is not great. The three button mouse thing is pretty stupid, for one.

While modernizing and redesigning the Plan 9 UI is a valiant cause, it may not be the most efficient way to accomplish your goals.

I'd venture to say that Plan 9 was never meant to be a mainstream OS. It essentially served as a playpen for new OS/systems ideas and research at Bell Labs at the time.

A lot of those ideas were pretty influential: union mounts, per-process namespaces, user-space file systems, UTF8, human-readable protocols, rfork(), file-object interface ubiquity, concurrent programming model, etc. You can see how these ideas have pervaded our current systems landscape.

The implementation of Plan 9 itself is great, but I don't think success of the Plan 9 project should be limited to whether or not its specific implementation stays current and modern. The UX was never designed with the common user in-mind, and it arguably was never the core focus for the system. A greater success would be to see its actual core ideas spread out into other mainstream systems.

So instead of making the Plan 9 UX more modern, why not work on getting some of its missing features into Linux instead? Last time I checked, Linux still needs a union-mount implementation. This way, the world benefits.

BTW, you might like this: http://swtch.com/plan9port/

Re: Plan 9 from Bell Labs

#69

Post by maggit »

bastawhiz wrote: post #45

Can someone explain why Plan 9 matters? I mean this legitimately. How is this differentiated from yet another flavor of *nix? I'm sure it was hot shit back in the early 90s, but I don't see much of an appeal other than as a curiosity like OS/2.

Your comparison to OS/2 may be apt. The details are a bit murky for me, but as far as I can tell from Wikipedia[1], OS/2 3.0 was at some point simply renamed to Windows NT, which of course is the underlying technology for Windows as we know it today.

That is; Plan 9 is a research project and it is relevant the way research is relevant: For the future.

[1]: http://en.wikipedia.org/wiki/OS/2

Re: Plan 9 from Bell Labs

#70

Post by amaranth »

rian wrote: post #68
Sir_Cmpwn wrote: post #16

Earlier quoted context omitted.

I've considered spending time on plan 9 making the UX less crappy. I think the stuff under the covers is fantastic but the UX is not great. The three button mouse thing is pretty stupid, for one.

While modernizing and redesigning the Plan 9 UI is a valiant cause, it may not be the most efficient way to accomplish your goals. I'd venture to say that Plan 9 was never meant to be a mainstream OS. It essentially served as a playpen for new OS/systems ideas and research at Bell Labs at the time. A lot of those ideas were pretty influential: union mounts, per-process namespaces, user-space file systems, UTF8, human…

Union filesystems are (finally) supported in mainline Linux as of the most recent (3.18) release.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

Post reply on HN