Hacker News Reader

Comment by sp332 | Hacker News Reader

Plan9 was a project that intended to be more Unix than Unix. For example, when Unix says "Everything is a file... except sockets, windows, etc." Plan9 says "no really, everything is a file." Here is a list of things that are not in Plan9 http://c2.com/cgi/wiki?WhatIsNotInPlanNine Oh, and did I mention Pike was one of the original leaders of the Plan9 project?

View on HN

Ultimately, today's UNIX is not that far from this ideal. In Linux, you can make pretty much everything be an fd: signals can be delivered over a descriptor (signalfd(2)), filesystem change notifications can be delivered over a descriptor (inotify(7)), and so on. Everything ends up being something you can pass to select (or a variant), and so you don't really need to handle the different concepts in different ways: a modern Linux application reads from a bunch of fds and takes action based on what it receives.

Incidentally, this is node.js' model.

A lot of features were developed in Plan9 and then "backported" to other Unixes and Linux. /proc, UTF-8 etc. https://secure.wikimedia.org/wikipedia/en/wiki/Plan_9_from_B...

Linux also has "mount -o bind", which corresponds to Plan9's alternative to symlinking.

But mount -o bind is not very useful when only root can use it and when it doesn't include proper union mounts.

Same problem applies to one of Plan 9's key design features: private namespaces.

Work is being done in this direction, with mount and UID namespaces. The main concern is that allowing users to make these kinds of bind mounts may confuse legacy suid apps.

Which really is the problem with modern Unixes -- legacy features that expect things done in a broken way, leading to complexity and ugliness where none should exist. The new features and simplifications continue to exist in a complex world, have arcane restrictions and interactions with the old system, and generally end up increasing the complexity, instead of making things simpler.

No, that's the problem with software designed to work in the real world. Software has to work in a legacy environment to be useful. This is why Unix gets used and Plan 9 doesn't. It's also why TCP and the Web, just to name two examples, survive.

I'll quote jwz: "Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. If that's what you need, you've got options... "

Evan Martin has a nice visualization of what the Chromium binaries consist of: http://neugierig.org/software/chromium/notes/2010/11/tree-ma...

There's also "Plan 9 from User Space":

http://swtch.com/plan9port/

"Plan 9 from User Space (aka plan9port) is a port of many Plan 9 programs from their native Plan 9 environment to Unix-like operating systems."

and 9base:

http://tools.suckless.org/9base

"9base is a port of various original Plan 9 tools for Unix, based on plan9port."

> Unix says "Everything is a file... except sockets, windows, etc."

Unix said that, but in fact meant "everything has a unique descriptor associated (an integer)".

Directory is not a file, it's a set of files and other directories. Unix doesn't even tries to camouflage this simple observation and returns EISDIR.

Even in 6th Edition Unix, devices were files in the filesystem as well. And in 6th Edition Unix, you could open and read a directory as a file; that was how you found out what its children were. There was no EISDIR. I believe this behavior persisted until at least SunOS 4.

Adding sockets and windows outside the filesystem is one of the things Rob is specifically complaining about here, and in fact complained about at the time as well.

The philosophy is that everything "looks like" a file, and this achieved through the standard file API (open/read/write/close). AFAIK sockets can be used with this API, as well as directories under Linux. The abstraction leaks quite a little bit sometimes, though.

shell command line history roll your own: fn history {grep '^term%' /mnt/wsys/text|sed -e 's/^term%//'}

oh yes that is so elegant...

It's DRY writ large. With that one command you get free text history for every program you use. You don't have to include history handling in each program individually.

So include that shortcut by default. It's UI. The job of the shell is to help the user get the job done.

Same argument goes for find. Its usefulness compared to du justifies its existence.

Reply on news.ycombinator.com