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

Plan 9: The way the future was

catb.org

Post reply on HN
Print view View original

71–80 of 86 posts

Re: Plan 9: The way the future was

#71

Post by koenigdavidmj »

rbanffy wrote: post #70
koenigdavidmj wrote: post #68

Earlier quoted context omitted.

It comes with a library called APE (see [1]), which provides most POSIX-y things implemented in terms of Plan 9 native API:s. (For example, BSD socket operations are just functions wrapping the normal file reads and writes that you would do in native Plan 9 code.) Some things do not work, though (permissions models are a bit different, and chroot is entirely unimplemented, for instance). 1: http://doc.cat-v.org/plan_…

That shouldn't prevent things like scripting languages or web browsers to be ported.

Right. Even X11 got ported at some point, so there is not really a reason why it wouldn't work other than lack of interest.

Re: Plan 9: The way the future was

#72

Post by jff »

rbanffy wrote: post #70
koenigdavidmj wrote: post #68

Earlier quoted context omitted.

It comes with a library called APE (see [1]), which provides most POSIX-y things implemented in terms of Plan 9 native API:s. (For example, BSD socket operations are just functions wrapping the normal file reads and writes that you would do in native Plan 9 code.) Some things do not work, though (permissions models are a bit different, and chroot is entirely unimplemented, for instance). 1: http://doc.cat-v.org/plan_…

That shouldn't prevent things like scripting languages or web browsers to be ported.

The difficult thing is getting it ported correctly. As several people have shown, it's easy to get Go running. However, getting Go running properly in such a way that you can continue to get updates from upstream is much more difficult. So you end up with ancient versions of gmake, gcc, python, mercurial, Go, etc., all mostly-functional but no longer getting bugfixes, because it's much more difficult to make a nice clean port that can be accepted into the upstream.

Oh, and given that the major web browsers all seem to be written in C++, and we don't have a C++ compiler... that's problematic.

Re: Plan 9: The way the future was

#73

Post by morphles »

I recently tried plan 9 for a bit. Though i understand all the cool things it does and agree with a lot of it. One thing really disappointed and struck me as totally brain dead: there is no such thing as terminal emulator or it seems something like text only mode. In general it seems to me that achieving keyboard only control (that is comfortable to use) is not really possible at least for now.

Re: Plan 9: The way the future was

#74

Post by adobriyan »

strictfp wrote: post #48
adobriyan wrote: post #34

Earlier quoted context omitted.

> The idea is not to have one unconfigurable binary reciever, It _is_ configurable, why do you think it is not? This idea that somehow one can fit any interaction with hardware into a filesystem ends when hardware becomes complex enough to simply NOT fit (like modern GPU). How do you guarantee atomicity when saving configuration with tar(1)? Linux recently deprecated textual conntracking data interface in favour of s…

I actually tried to point out that configurability _is_ very possible with such an API. Your complexity argument does not hold. If I can control something with a C API, why not with a file API? Take atomicity as an example. C has no inherent concept of atomicity. Yet you can acheive atomicity by using C. So why not with a REST or file-based interface? You also mention speed. Interesting since complexity and performan…

> Take atomicity as an example. C has no inherent concept of atomicity. Yet you can acheive atomicity by using C. So why not with a REST or file-based interface?

You achieve atomicity because inside kernel handler of relevant imaginary ioctl(2) which dumps all hardware configuration there is synchronization primitive which provides necessary guarantees, so this imaginary ioctl(HW_GET_STATE) writes coherent state to userspace.

If you merely expose individual hw config into flat files, POSIX directory semantics does not guarantee you atomicity. So, you have to invent something instead, like additional file which kinda sorta provides locking. But if you invented it, you have implicitly mandated that ALL users must be nice and go through locking API/file, whatever. At this point, nothing prevents rogue (and more importantly) buggy userspace from messing with well-behaving users.

At this point, you've failed to provide something another developer is asking you to provide, namely, a guarantee that hw state will be coherent.

Re: Plan 9: The way the future was

#75

Post by bitwize »

thristian wrote: post #7

The impression I got was that the guys behind Unix were annoyed when their operating-systems research was stalled in the name of "API compatibility", so they started Plan 9 and actively resisted commercialisation for as long as possible (for example, they gave it the least marketable name they could think of). There's so many interesting ideas in Plan 9, I'm occasionally tempted to install it and try it out... but th…

If AT&T could successfully market an OS with a name that sounds like "eunuchs", they weren't going to be dissuaded by something innocuous like Plan 9.

And indeed, Plan 9 is conceptually cool as balls, but Acme and Sam make me want to chuck expensive electronic equipment out the window.

Re: Plan 9: The way the future was

#76

Post by bitwize »

mhd wrote: post #57
hollerith wrote: post #47

Earlier quoted context omitted.

For over a decade, dozens of actual people used Plan 9 as their main environment. (Many but not all of these people worked at Bell Labs.) I tend to believe that Smalltalk has also seen serious numbers of actual users. In contrast, who has ever used Oberon as their main software environment except perhaps students required to do so to pass some class?

If we're talking about popularity contests here, all the "contestants" aren't doing very well…

Smalltalk is a stealth weapon in the banking industry. I know Wells Fargo has a codebase based on it. I know this because roundabout 2008 I was pestered by recruiters looking for Smalltalk devs willing to move to cold, cold Minnesota. (Boston winters are more than enough for me so I bade them a courteous no-thank-you.)

Also, most of the currently trending methodology buzzwords (Extreme Programming, TDD, refactoring, etc.) emerged out of a community of Smalltalk programmers on real professional software projects.

What Smalltalk lacks is marketing hype.

Re: Plan 9: The way the future was

#77

Post by adobriyan »

strictfp wrote: post #48
adobriyan wrote: post #34

Earlier quoted context omitted.

> The idea is not to have one unconfigurable binary reciever, It _is_ configurable, why do you think it is not? This idea that somehow one can fit any interaction with hardware into a filesystem ends when hardware becomes complex enough to simply NOT fit (like modern GPU). How do you guarantee atomicity when saving configuration with tar(1)? Linux recently deprecated textual conntracking data interface in favour of s…

I actually tried to point out that configurability _is_ very possible with such an API. Your complexity argument does not hold. If I can control something with a C API, why not with a file API? Take atomicity as an example. C has no inherent concept of atomicity. Yet you can acheive atomicity by using C. So why not with a REST or file-based interface? You also mention speed. Interesting since complexity and performan…

Regarding speed and knuth argument.

At this stage real world examples show that once scale of the state becomes sufficiently large (large number of conntracks on big firewalls), text interface always lose.

So, play with toy flat text file interface if you want, but you might as well do it right from the very beginning.

Right now, /proc/stat slowness is being discussed in linux-kernel. Part of the problem: heuristics determining how many pages needs to be allocated for buffer containing text info sucks because integers written in decimal are variable sized. Kernel first allocate 1 page, only to fill it and see that 1 page is not enough for big enough machines (NR_CPUS * NR_INTERRUPTS)

2 patches are proposed: first is to allocate 2 pages from the beginning, second is (no kidding) to print decimals faster (printf "%u" can be made faster since it's known that "unsigned int" is going to be dumped and C has pathetic support for compile-time evaluation).

But the correct from every angle (except existing /proc/stat users) answer is obvious: dump BINARY info already into userspace buffer which will be appropriately sized because it's easy to multiply 3 integers). Simply ship information to who is asking, without print bullshit.

Real programming languages and environments should easily eat result (Python's struct.unpack springs to mind).

Excuses for programming languages will not.

Can you transform /proc/bus/pci/00/00.0 content into one-dimensional array of bytes with you favourite PL? And if you can't, whose problem is it?

And yet another example, Linux USB bus sniffer kernel module (don't remember exact name/config option) gained binary interface deprecating text one.

As for _inherent_ speed limitations, read(2) does memcpy(), so you have to provide mmap(2) for your file (most virtual Linux filesystems doesn't do it for majority of files).

Re: Plan 9: The way the future was

#78

Post by adobriyan »

angersock wrote: post #54
adobriyan wrote: post #34

Earlier quoted context omitted.

> The idea is not to have one unconfigurable binary reciever, It _is_ configurable, why do you think it is not? This idea that somehow one can fit any interaction with hardware into a filesystem ends when hardware becomes complex enough to simply NOT fit (like modern GPU). How do you guarantee atomicity when saving configuration with tar(1)? Linux recently deprecated textual conntracking data interface in favour of s…

This idea that somehow one can fit any interaction with hardware into a filesystem ends when hardware becomes complex enough to simply NOT fit (like modern GPU). The idea that one can fit any interaction with hardware into the mere toggling of registers and stuffing of byte buffers... I don't know what FS you're using, but any good modern filesystem (say, ZFS or something similar) should prove more than adequate for…

We're discussing anything that can do open(), read, write(), provides files and directories. Do you understand that virtual filesystems do not have problems with inode counts?

Dupping a directory means a) hw state is saved on open(), in which case you're holding it unnecessary because read() simply may not happen b) hw state is saved on first read(). OK, what to do with parallel dumpers? How to determine when transaction starts and ends? What to do if dumper process is sigkilled?

ioctl(HW_GET_STATE) doesn't have these problems, kernel knows how to kill process inside itself.

Try to save /sys/class/net/lo/* coherently and write down all assumptions which you did.

Re: Plan 9: The way the future was

#79

Post by [deleted] »

jff wrote: post #64
bct wrote: post #42

Earlier quoted context omitted.

The trick is to build ugly systems that are able to grow into beautiful ones.

That is quite a trick. The problem is that pretty soon, everyone depends on the behavior of the ugly warts in your original system, so now you're stuck with them lest you break the holy Compatibility.

[deleted]

Re: Plan 9: The way the future was

#80

Post by andrewflnr »

ori_b wrote: post #36
haberman wrote: post #12

Am I the only one who doesn't get excited about the idea of absolutely everything being a file? People seem to like the idea of being able to say things like "cat file.wav > /dev/dsp". But a sound card is a complex thing that can be configured in umpteen different ways; what if the file has a different sample rate than the card is currently running at? Even if you gerry-rigged a kernel driver that could handle this c…

>Am I the only one who doesn't get excited about the idea of absolutely everything being a file? Don't think of it as everything being a file. Think of it as accessing everything including file data through an RPC system.

It's been a while since I looked at 9P. Is it really that much like an RPC system?
Post reply on HN