Plan 9 and Inferno do this better and more simply
on
Sun Launches JXTA
·
· Score: 3
Looks like there is a trend of inventing half-baked complex "protocol based" distributed systems, ever struggling to find a decent basic abstraction for generalized communication between application processes in different machines: proprietary RPC mechanisms, myriad in-compatible application spesific XML languages, JXTA "pipes", Linda/Jini tuples, CORBA "objects" and finally a hodgepodge of classical text line based TCP/IP application protocols with a mix of transport and presentation layer issues unsolved.
Plan 9 "only" has distibuted files. With dynamic, on-the fly synthesized algorithmic response. With authentication, security and distributed user management with group rights. With naming and access categorization bits.With unified interface for intra-node and inter-node tarffic. With straihtforward binding to classical channel stuctures for multiprogramming intra-process messaging and synchronization with a flexible threading concept. With compatibility with all classical local static data file access code and algorithms. With distributed inheritance and with stackable half-transparent union directories.
Download Rob Pike's and friends' Plan 9 and Inferno from Vita Nuova pages and onwards to Bell Labs pages.
...And for multithreaded programs, a message
passing paradigm is generally the best approaching my experience...
If you are looking for languages that make avoiding bugs easier, look beyond C++...
Inferno's Limbo uses just that. And has a nice GUI multithreaded debugger. Runs on all platforms. And the source is publicly available.
Styx / 9P is so much better, and simpler
on
Perl and .NET
·
· Score: 1
Contrast both SOAP and Corba to Styx/9P, the object protocol of Inferno and Plan 9, also available for other environments as a product which at least used to be called InfernoSpaces. It was available as Java classes and C libraries for several development environments.
You just mount all your remote procedures as a hierarchy of files. You call them by opening them and writing to them. You receive the results by reading them.
You can inherit / modify / augment / restrict functionality of a set of procedures / files by mounting file sets (objects) as a stack / union directory, where the topmost names hide the lower names.
Listing, naming and accessing of "remote objects" become trivial. Permanent and transient objects look the same, and just like regular files. Commands are usually issued as text content. So bindings to functions are language independent.
Optional authentication, data integrity and confidentility are built in, and can be configured at run time, transparent to the programmer.
Here in Helsinki, Finland, there is a long time project to rebuild the Töölö bay area. I asked the city officials to convert their CAD stuff to Quake maps and put them to the net as level files for the public to go for test walks.
For public city planning that would be great. You could not only look at things, but test actual living in them, with other people.
Plan 9 / Inferno does it...
on
Pipes In GUI's
·
· Score: 1
In Plan 9 and Inferno all objects communicate through network transparent text or binary channels. The Plan 9 main user interface framework ACME is built on such set of files. The concept of "plumbing" allows run time combining of different application into systems with channels.
Fantastic article by TheDullBlade. I agree in every place. BTW, one of the best balances between language and mouse is in Wirth's Oberon system, now best manifested by Plan 9 ACME. I think the real innovations will come in programming techniques which solve complex cross-organizational security, networking, modularization and re-use needs, not in user interfaces. Again, see Plan 9 and its cousin Inferno.
The current release of Plan 9 will must soon have Inferno available as an optional subsystem, because that is such and obvious application. The existing Inferno version for old Plan 9 was not mentioned, because it seems to be in need of a little tuning to reduce some now redundant functionality in the new Plan 9 environment.
See also:
The design of the Inferno virtual machine Phil Winterbottom and Rob Pike
A program can export a file hierarchy, which it read and writes, forming a file server, or "procedural file system". Say
/myserver/control /myserver/data
What if I want to modify the program? I can write another file server, which exports a similar, but different hierarchy. This program reads strings written to "control", copies them to debug, and then reroutes them to the original program.
/myserver/control /myserver/debug
Now I mount the original hierarchy to a process name space. Then I mount the latter hierarchy on top of it, like in a stack. The result is:
/myserver/control /myserver/debug /myserver/data
The "data" file shows transparently through from the original hierarchy!
What is this? It is inheritance! Objects! But the objects can inherit from each other, even if they are written in different languages, I don't have access to their implementation and they are mounted while running on different machines and stacked dynamically at run time!!!!!!!!!
Why do people always stress the story aspect of games. Does football have a "story"? Or "monopoly"? Does anyone care if Doom or Quake had a story? Games are not books of the modern era. Books are. Games are something else. The most important interaction between people and the world happens with hands and eyes. That's why graphic intensive finger candy is great. But good games don't need fancy graphics, Pokemon does not, board games do not. Because people are symbol handling machines, and they like playing with symbols. This is a broader concept than language of words and stories. I don't object to stories in games, but I have yet to see one which is not infantile.
A little clarification: the public info on the web site is about the old version 1.0 from 1995 or so, the new release 2.0 is known there by the codename "Brazil". For recent information see comp.os.plan9!
Moreover: Inferno is a separate product, which does not come with Plan 9, but can be run efficiently on top of Plan 9, or on bare hardware.
(A wide range of interesting architectures is supported by both Plan 9 and the native OS option of the Inferno VM.)
Did you know that Plan 9 2.0 is coming soon from Bell Labs, and the main architect Rob Pike?
Plan 9 is the next reasearch version of Unix from the real programmers. Way superior to tired, old Unix clones.
Plan is a distributed, multiprocessor system form the start. It has the most elegant threading model (processes have freedom to share resources like memory space selectively). It's distribution mechanism with procedural file systems and union directories provides language independent, persistent network objects with inheritance.
The new version is more Unix compatible than the old one, which was maybe a little too much for an average non-educated hacker to grasp.
Plan 9 has application programmer transparent cryptographic authentication and security at networked object / file access level. Any set of resources can be set up as a per process file name space to guarantee security of any binary.
Plan 9 also integrates tightly with Inferno, which is a virtual networked OS and VM which is everything Java should have been, and available for a wide range of platforms, including Windowzes and Linux.
I thought Slashdot readers where people with basic understanding of a concept of a "data format". So how is everybody having the concepts of syntax and semantics so confused with XML?
Standardizing XML public DTDs is practically no easier than standardizing any other public data formats. Whether they are binary, ASCII or Unicode based makes no real difference.
Interpreting XML documents conforming to a given DTD is practically no easier than interpreting any other standard data formats. The syntaxes (where XML helps) are not the challenge, the semantics are (no help from XML in converting the semantics of one DTD to another).
Something like XSL is nice, but again: standardizing on one form of machine interpretable rendering instuctions (semantics specification language) is no easier than on other, regardless whetehr the instuctions are XSL, Postscript, TeX, Tk, OpenGL or whatever.
In good or bad, it might be so that scarce disk caches for material will exclude distribution of all but the most requested material. This might exclude minority harms like kiddie porn, harmful facts/lies about individuals, etc... in practice.
This also brings flooding threats. Anyone can flood the servers with pseudorequest to populate the caches with material they desire. Here the sytems could use a general technique for service denial and flooding prevention: associate a cost to a transaction, whether it be just a longish delay or perhaps a "fee", e.g. an identified account which keeps no track of what data you fetch, but logs the amount of traffic you generate and limit it.
I just read today a paper buy some Bell labs guys, which talked about one peculiar aspect of real world files and file collections. It was in a recent conference proceedings of some Data Compression folks. I'll get the reference, if anyone is interested. Anyway, the point was this: in many situations a large cellection of real world data has long repating sequences, which are ralatively far apart of each other. Thus sliding window dictionary compression protocols like the zip-family fail to notice them. They researched some real world data examples and found, that if a simple 150 line C program is used to pre- and post-process gzip compression, in many cases the resulting added compression can be significant. The pre-processor scans the data for long, faraway repeating sequences and replaces them with simple references to earlier instances. I think that even a regular file system of any multiuser computer tends to have a lot of this kind of redundancy: same pieces of statically linked code in executable, same or almost the same text in different version of documents, not to mention almost or total dupilicates between different users of the same files. If the file system itself, or in the case of the Freenet project, the document database, could use this kind of high granularity redundancy checking and compression, it would not matter at all, whethet a server has millions of copies of the same data in different files: the total disk space used would be in the order of one copy only!
I have the impression that implementing a 2n-bit instruction set requires exponentially more die area compared to an n-bit architecture?
Modern Intel 32-bit processors have tens of millions of transistors. The 80286 processor, with 16 bit architecture, had something like 125 000 tansistors.
Imagine a processor die which would run hundreds of tightly coupled equal 16-bit cores, with a modern clock frequency of 1 GHz.
The arithmetics that a program does can be broken to sub-problems that work within 16-bit number sets. When you need bigger numbers, you could use software emulation of bigger numbers. Accessing large data sets should be done through object methods anyway, not by direct addressing, so you don't necessarily need the traditionally desirable large, flat address spaces.
All in-die processor cores could have a sizable private memory for higly dynamic small objects like run-time system constructs and such.
It should be easy to design and optimize a processor, which is built of small equal, cloned parts.
Of course you would need parellel programming techniques to use the power. But modern languages like Bell labs Alef and Limbo make it fairly easy and starightforward to write highly parallellizable prgrams. Most current systems use threading anyway. The channel abstraction in Hoares "Communicating sequential processes", later in Occam language and in those Bell languages I mentioned works nicely in this kind of arcitecture.
Linux is simple and well understood. This goes for the kernel, this goes for the whole Linux culture. Open source and generally open communication ensures optrimization and simplicity, power, flexibility and finally, I predict, also ease of use.
Above all it gives insurance againts malicious, hidden, evil things. If there is a security problem in Linux, everybody will know it. If someone has a fix, it is ditributed to all, for free, fast.
This is definitively what we need, what I have been dreaming of for years, and what we will have. A universal, global radio standard. It is defined to be flexible enough to work on ALL of the frequency spectrum.
The standard is a minimal resource negotiation rule. It only manages time dynamic power and frequency negotiation and a handshaking protocol for choosing the actual desired data comms protocols. It is left for the market to compete for implementations for detailed interoperability and data comms protocols within this framework. All legacy protocols, especially all analog stupidity, should then be gradually phased out or made changed to comply to the new dynamic resource negotiation standard.
George Gilder wrote an article about some radio veteran researcher a few years ago who had long been pursuing ideas on these lines. I lost the reference to that article, anyone have it?
Spying is a form of agressive politics, like war is. We don't just accept the fact that a country with bigger guns can wage a war against smaller countries. We should not accept espionage by the superpower as inevitable.
Espionage like war sometimes happens, and sometimes some people feel it is the right thing to do. But we should try to set up means and rules for freedom and privacy, as much as is possible.
Luckily spying is relatively easy to prevent with modern cryptographic methods. We just need to keep them free. I hope these news make the rest of EU countries understand this. Governments here in Scandinavia already take it for granted that everybody has the right to use/buy/sell whatever privacy tools they want to.
A court of law may try to force a suspect to open up secret data in a criminal case, but only after a legal process.
Slashdot Mirror
Looks like there is a trend of inventing half-baked complex "protocol based" distributed systems, ever struggling to find a decent basic abstraction for generalized communication between application processes in different machines: proprietary RPC mechanisms, myriad in-compatible application spesific XML languages, JXTA "pipes", Linda/Jini tuples, CORBA "objects" and finally a hodgepodge of classical text line based TCP/IP application protocols with a mix of transport and presentation layer issues unsolved.
Plan 9 "only" has distibuted files. With dynamic, on-the fly synthesized algorithmic response. With authentication, security and distributed user management with group rights. With naming and access categorization bits.With unified interface for intra-node and inter-node tarffic. With straihtforward binding to classical channel stuctures for multiprogramming intra-process messaging and synchronization with a flexible threading concept. With compatibility with all classical local static data file access code and algorithms. With distributed inheritance and with stackable half-transparent union directories.
Download Rob Pike's and friends' Plan 9 and Inferno from Vita Nuova pages and onwards to Bell Labs pages.
Inferno's Limbo uses just that. And has a nice GUI multithreaded debugger. Runs on all platforms. And the source is publicly available.
Contrast both SOAP and Corba to Styx/9P, the object protocol of Inferno and Plan 9, also available for other environments as a product which at least used to be called InfernoSpaces. It was available as Java classes and C libraries for several development environments.
See The Styx Architecture for Distributed Systems, Styx/9P-search on Google, a real life example of an interface to remote functionality, Styx manual pages, Inferno home and Plan 9 home.
You just mount all your remote procedures as a hierarchy of files. You call them by opening them and writing to them. You receive the results by reading them. You can inherit / modify / augment / restrict functionality of a set of procedures / files by mounting file sets (objects) as a stack / union directory, where the topmost names hide the lower names.Listing, naming and accessing of "remote objects" become trivial. Permanent and transient objects look the same, and just like regular files. Commands are usually issued as text content. So bindings to functions are language independent.
Optional authentication, data integrity and confidentility are built in, and can be configured at run time, transparent to the programmer.
The Styx Architecture for Distributed Systems
See also info about Lucent VPN Firewall products, which also run on top of Inferno: Google-search
Here in Helsinki, Finland, there is a long time project to rebuild the Töölö bay area. I asked the city officials to convert their CAD stuff to Quake maps and put them to the net as level files for the public to go for test walks. For public city planning that would be great. You could not only look at things, but test actual living in them, with other people.
In Plan 9 and Inferno all objects communicate through network transparent text or binary channels. The Plan 9 main user interface framework ACME is built on such set of files. The concept of "plumbing" allows run time combining of different application into systems with channels.
See acme command acme "methods" plumb command plumb "methods"
Fantastic article by TheDullBlade. I agree in every place. BTW, one of the best balances between language and mouse is in Wirth's Oberon system, now best manifested by Plan 9 ACME. I think the real innovations will come in programming techniques which solve complex cross-organizational security, networking, modularization and re-use needs, not in user interfaces. Again, see Plan 9 and its cousin Inferno.
Efficiency has been a major design criteria. In theory, most of Plan 9 is very opimized.
In practice, it is faster than anything else, because it is small, flexible and simple, thus easier to optimize for the task at hand.
The current release of Plan 9 will must soon have Inferno available as an optional subsystem, because that is such and obvious application. The existing Inferno version for old Plan 9 was not mentioned, because it seems to be in need of a little tuning to reduce some now redundant functionality in the new Plan 9 environment.
See also:
The design of the Inferno virtual machine
Phil Winterbottom and Rob Pike
http://www.cs.bell-labs.com /cm/cs/who/rob/hotchips.html
And I note, that Plan 9/ Inferno has a security model, which is a millennium more advanced than that of Java.
Ceterum censeo: XML is a hoax. Luckily, Plan 9 has no use of it whatsover.
Embedded special versions of Plan 9 / Inferno run Lucent's very fast Managed Firewall and a high end Access server product line, among other things.
A program can export a file hierarchy, which it read and writes, forming a file server, or "procedural file system". Say
/myserver/control
/myserver/data
What if I want to modify the program? I can write another file server, which exports a similar, but different hierarchy. This program reads strings written to "control", copies them to debug, and then reroutes them to the original program.
/myserver/control
/myserver/debug
Now I mount the original hierarchy to a process name space. Then I mount the latter hierarchy on top of it, like in a stack. The result is:
/myserver/control
/myserver/debug
/myserver/data
The "data" file shows transparently through from the original hierarchy!
What is this? It is inheritance! Objects! But the objects can inherit from each other, even if they are written in different languages, I don't have access to their implementation and they are mounted while running on different machines and stacked dynamically at run time!!!!!!!!!
Why do people always stress the story aspect of games. Does football have a "story"? Or "monopoly"? Does anyone care if Doom or Quake had a story? Games are not books of the modern era. Books are. Games are something else. The most important interaction between people and the world happens with hands and eyes. That's why graphic intensive finger candy is great. But good games don't need fancy graphics, Pokemon does not, board games do not. Because people are symbol handling machines, and they like playing with symbols. This is a broader concept than language of words and stories. I don't object to stories in games, but I have yet to see one which is not infantile.
See Rob's home
http://www.cs.bell-labs.com/cm/cs/who/rob/
for some other nice stuff. Abovel all, see
http://plan9.bell-labs.com/plan9/ and
http://inferno.bell-labs.com/inferno/
to see what he consideres relevant work in systems research.
Personally, Rob is my greatest, and only idol, and I feel Plan 9 just solves all the problems of the world elegantly.
(The message commented by this message should have been a reply to my message about Plan 9 yesterday.)
A little clarification: the public info on the web site is about the old version 1.0 from 1995 or so, the new release 2.0 is known there by the codename "Brazil". For recent information see comp.os.plan9!
Moreover: Inferno is a separate product, which does not come with Plan 9, but can be run efficiently on top of Plan 9, or on bare hardware.
(A wide range of interesting architectures is supported by both Plan 9 and the native OS option of the Inferno VM.)
Did you know that Plan 9 2.0 is coming soon from Bell Labs, and the main architect Rob Pike?
Plan 9 is the next reasearch version of Unix from the real programmers. Way superior to tired, old Unix clones.
Plan is a distributed, multiprocessor system form the start. It has the most elegant threading model (processes have freedom to share resources like memory space selectively). It's distribution mechanism with procedural file systems and union directories provides language independent, persistent network objects with inheritance.
The new version is more Unix compatible than the old one, which was maybe a little too much for an average non-educated hacker to grasp.
Plan 9 has application programmer transparent cryptographic authentication and security at networked object / file access level. Any set of resources can be set up as a per process file name space to guarantee security of any binary.
Plan 9 also integrates tightly with Inferno, which is a virtual networked OS and VM which is everything Java should have been, and available for a wide range of platforms, including Windowzes and Linux.
http://www.cs.bell-labs.com/plan9/
http://plan9.bell-labs.com/cm/cs/who/rob/
http://inferno.bell-labs.com/inferno/
I thought Slashdot readers where people with basic understanding of a concept of a "data format". So how is everybody having the concepts of syntax and semantics so confused with XML?
Standardizing XML public DTDs is practically no easier than standardizing any other public data formats. Whether they are binary, ASCII or Unicode based makes no real difference.
Interpreting XML documents conforming to a given DTD is practically no easier than interpreting any other standard data formats. The syntaxes (where XML helps) are not the challenge, the semantics are (no help from XML in converting the semantics of one DTD to another).
Something like XSL is nice, but again: standardizing on one form of machine interpretable rendering instuctions (semantics specification language) is no easier than on other, regardless whetehr the instuctions are XSL, Postscript, TeX, Tk, OpenGL or whatever.
In good or bad, it might be so that scarce disk caches for material will exclude distribution of all but the most requested material. This might exclude minority harms like kiddie porn, harmful facts/lies about individuals, etc... in practice.
This also brings flooding threats. Anyone can flood the servers with pseudorequest to populate the caches with material they desire. Here the sytems could use a general technique for service denial and flooding prevention: associate a cost to a transaction, whether it be just a longish delay or perhaps a "fee", e.g. an identified account which keeps no track of what data you fetch, but logs the amount of traffic you generate and limit it.
http://computer.org/proceedings/dcc/0096/00960287a bs.htm
The article was
"Data compression using long common strings"
J. Bentley and D. McIlroy
p. 287 in the book
"Proceedings - data compression conference DCC '99"
Edited by James A. Storer and Martin Cohn
IEEE computer society
Los Alamitos, California, 1999
It is available in the link above for a price.
I just read today a paper buy some Bell labs guys, which talked about one peculiar aspect of real world files and file collections. It was in a recent conference proceedings of some Data Compression folks. I'll get the reference, if anyone is interested. Anyway, the point was this: in many situations a large cellection of real world data has long repating sequences, which are ralatively far apart of each other. Thus sliding window dictionary compression protocols like the zip-family fail to notice them. They researched some real world data examples and found, that if a simple 150 line C program is used to pre- and post-process gzip compression, in many cases the resulting added compression can be significant. The pre-processor scans the data for long, faraway repeating sequences and replaces them with simple references to earlier instances. I think that even a regular file system of any multiuser computer tends to have a lot of this kind of redundancy: same pieces of statically linked code in executable, same or almost the same text in different version of documents, not to mention almost or total dupilicates between different users of the same files. If the file system itself, or in the case of the Freenet project, the document database, could use this kind of high granularity redundancy checking and compression, it would not matter at all, whethet a server has millions of copies of the same data in different files: the total disk space used would be in the order of one copy only!
I have the impression that implementing a 2n-bit instruction set requires exponentially more die area compared to an n-bit architecture?
Modern Intel 32-bit processors have tens of millions of transistors. The 80286 processor, with 16 bit architecture, had something like 125 000 tansistors.
Imagine a processor die which would run hundreds of tightly coupled equal 16-bit cores, with a modern clock frequency of 1 GHz.
The arithmetics that a program does can be broken to sub-problems that work within 16-bit number sets. When you need bigger numbers, you could use software emulation of bigger numbers. Accessing large data sets should be done through object methods anyway, not by direct addressing, so you don't necessarily need the traditionally desirable large, flat address spaces.
All in-die processor cores could have a sizable private memory for higly dynamic small objects like run-time system constructs and such.
It should be easy to design and optimize a processor, which is built of small equal, cloned parts.
Of course you would need parellel programming techniques to use the power. But modern languages like Bell labs Alef and Limbo make it fairly easy and starightforward to write highly parallellizable prgrams. Most current systems use threading anyway. The channel abstraction in Hoares "Communicating sequential processes", later in Occam language and in those Bell languages I mentioned works nicely in this kind of arcitecture.
Linux is simple and well understood. This goes for the kernel, this goes for the whole Linux culture. Open source and generally open communication ensures optrimization and simplicity, power, flexibility and finally, I predict, also ease of use.
Above all it gives insurance againts malicious, hidden, evil things. If there is a security problem in Linux, everybody will know it. If someone has a fix, it is ditributed to all, for free, fast.
The standard is a minimal resource negotiation rule. It only manages time dynamic power and frequency negotiation and a handshaking protocol for choosing the actual desired data comms protocols. It is left for the market to compete for implementations for detailed interoperability and data comms protocols within this framework. All legacy protocols, especially all analog stupidity, should then be gradually phased out or made changed to comply to the new dynamic resource negotiation standard.
George Gilder wrote an article about some radio veteran researcher a few years ago who had long been pursuing ideas on these lines. I lost the reference to that article, anyone have it?
Spying is a form of agressive politics, like war is. We don't just accept the fact that a country with bigger guns can wage a war against smaller countries. We should not accept espionage by the superpower as inevitable.
Espionage like war sometimes happens, and sometimes some people feel it is the right thing to do. But we should try to set up means and rules for freedom and privacy, as much as is possible.
Luckily spying is relatively easy to prevent with modern cryptographic methods. We just need to keep them free. I hope these news make the rest of EU countries understand this. Governments here in Scandinavia already take it for granted that everybody has the right to use/buy/sell whatever privacy tools they want to.
A court of law may try to force a suspect to open up secret data in a criminal case, but only after a legal process.