vitanuova.com · Domains · Slashdot Mirror

This has been done before with Inferno/Limbo by CondeZer0 · 2004-09-12 09:28 · Score: 2, Interesting · on .Net On Lego Mindstorm

For people with good taste and that program in the language that was meant to be the true C successor: Limbo, we have had Styx-on-a-brick for a long time, and you can get the source for it too: http://www.vitanuova.com/inferno/co/rcx/

Styx-on-a-brick is really cool and fits directly into the Unix way of doing things:

% mount -A /net/legolink /n/remote % cd /n/remote % ls motor sensor % ls motor motor/0 motor/1 motor/2 motor/012 % ls sensor sensor/0 sensor/1 sensor/2 # Start motor... % cd motor % echo -n f7 > 0 # Reverse the motor... % echo -n r7 > 0 # Stop the motor... % echo -n F0 > 0 # Run the motor for 5 seconds... % echo -n r7 > 0; sleep 5; echo -n F0 > 0 # Ok, lets play with a sensor... % cd /n/remote/sensor % echo b0 > 0 % cat 0 0 # Click the button a few times and then try reading the sensor file again % cat 0 4 # Let's try a blocking read on the sensor % echo b5 > 0 % cat 0 # [click the button 5 times] 5 # Ok, we're done playing - unmount the brick namespace % ls /n/remote /n/remote/motor /n/remote/sensor % unmount /n/remote % ls /n/remote %

And then you can easily connect it an Inferno Grid: http://www.vitanuova.com/solutions/grid/demogrid.h tml

Why use a bad Java clone(that is what .NOT is after all) when you can use an elegant and KISS language like Limbo? Not to mention that Inferno brings the ideas of Unix into the distributed environment world in the most beautiful way... Paraphrasing God Henry Spencer: Those who don't understand the work done at Bell Labs are doomed to reinvent it, poorly.

uriel

P.S.: And yes, for those still living under a rock, Both Inferno and Plan 9 are Open Source. Inferno: http://www.vitanuova.com/inferno/net_download4T.ht ml Plan 9: http://plan9.bell-labs.com/plan9dist/

P.P.S.: For those that don't know what Inferno is and to bypass SlashDot filters here is some text from Dennis M. Ritchie himself: Limbo is a programming language intended for applications running distributed systems on small computers. It supports modular programming, strong type checking at compile- and run-time, interprocess communication over typed channels, automatic garbage collection, and simple abstract data types.

And here is an extract from an interview with Ken God Thompson, creator of Unix and co-inventor of C:
Computer: How does your work on Plan 9 and Inferno derive from your earlier work on Unix? What are some of the new ideas arising out of this work that could and should apply to distributed operating systems in general?
Thompson: [...] In Plan 9 and Inferno, the key ideas are the protocol for communicating between components and the simplification and extension of particular concepts. In Plan 9, the key abstraction is the file system any thing you can read and write and select by names in a hierarchy and the protocol exports that abstraction to remote channels to enable distribution. Inferno works similarly, but it has a layer of language interaction above it through the Limbo language interface which is [somewhat] like Java, but cleaner.

This has been done before with Inferno/Limbo by CondeZer0 · 2004-09-12 09:28 · Score: 2, Interesting · on .Net On Lego Mindstorm

For people with good taste and that program in the language that was meant to be the true C successor: Limbo, we have had Styx-on-a-brick for a long time, and you can get the source for it too: http://www.vitanuova.com/inferno/co/rcx/

Styx-on-a-brick is really cool and fits directly into the Unix way of doing things:

% mount -A /net/legolink /n/remote % cd /n/remote % ls motor sensor % ls motor motor/0 motor/1 motor/2 motor/012 % ls sensor sensor/0 sensor/1 sensor/2 # Start motor... % cd motor % echo -n f7 > 0 # Reverse the motor... % echo -n r7 > 0 # Stop the motor... % echo -n F0 > 0 # Run the motor for 5 seconds... % echo -n r7 > 0; sleep 5; echo -n F0 > 0 # Ok, lets play with a sensor... % cd /n/remote/sensor % echo b0 > 0 % cat 0 0 # Click the button a few times and then try reading the sensor file again % cat 0 4 # Let's try a blocking read on the sensor % echo b5 > 0 % cat 0 # [click the button 5 times] 5 # Ok, we're done playing - unmount the brick namespace % ls /n/remote /n/remote/motor /n/remote/sensor % unmount /n/remote % ls /n/remote %

And then you can easily connect it an Inferno Grid: http://www.vitanuova.com/solutions/grid/demogrid.h tml

Why use a bad Java clone(that is what .NOT is after all) when you can use an elegant and KISS language like Limbo? Not to mention that Inferno brings the ideas of Unix into the distributed environment world in the most beautiful way... Paraphrasing God Henry Spencer: Those who don't understand the work done at Bell Labs are doomed to reinvent it, poorly.

uriel

P.S.: And yes, for those still living under a rock, Both Inferno and Plan 9 are Open Source. Inferno: http://www.vitanuova.com/inferno/net_download4T.ht ml Plan 9: http://plan9.bell-labs.com/plan9dist/

P.P.S.: For those that don't know what Inferno is and to bypass SlashDot filters here is some text from Dennis M. Ritchie himself: Limbo is a programming language intended for applications running distributed systems on small computers. It supports modular programming, strong type checking at compile- and run-time, interprocess communication over typed channels, automatic garbage collection, and simple abstract data types.

And here is an extract from an interview with Ken God Thompson, creator of Unix and co-inventor of C:
Computer: How does your work on Plan 9 and Inferno derive from your earlier work on Unix? What are some of the new ideas arising out of this work that could and should apply to distributed operating systems in general?
Thompson: [...] In Plan 9 and Inferno, the key ideas are the protocol for communicating between components and the simplification and extension of particular concepts. In Plan 9, the key abstraction is the file system any thing you can read and write and select by names in a hierarchy and the protocol exports that abstraction to remote channels to enable distribution. Inferno works similarly, but it has a layer of language interaction above it through the Limbo language interface which is [somewhat] like Java, but cleaner.

This has been done before with Inferno/Limbo by CondeZer0 · 2004-09-12 09:28 · Score: 2, Interesting · on .Net On Lego Mindstorm

For people with good taste and that program in the language that was meant to be the true C successor: Limbo, we have had Styx-on-a-brick for a long time, and you can get the source for it too: http://www.vitanuova.com/inferno/co/rcx/

Styx-on-a-brick is really cool and fits directly into the Unix way of doing things:

% mount -A /net/legolink /n/remote % cd /n/remote % ls motor sensor % ls motor motor/0 motor/1 motor/2 motor/012 % ls sensor sensor/0 sensor/1 sensor/2 # Start motor... % cd motor % echo -n f7 > 0 # Reverse the motor... % echo -n r7 > 0 # Stop the motor... % echo -n F0 > 0 # Run the motor for 5 seconds... % echo -n r7 > 0; sleep 5; echo -n F0 > 0 # Ok, lets play with a sensor... % cd /n/remote/sensor % echo b0 > 0 % cat 0 0 # Click the button a few times and then try reading the sensor file again % cat 0 4 # Let's try a blocking read on the sensor % echo b5 > 0 % cat 0 # [click the button 5 times] 5 # Ok, we're done playing - unmount the brick namespace % ls /n/remote /n/remote/motor /n/remote/sensor % unmount /n/remote % ls /n/remote %

And then you can easily connect it an Inferno Grid: http://www.vitanuova.com/solutions/grid/demogrid.h tml

Why use a bad Java clone(that is what .NOT is after all) when you can use an elegant and KISS language like Limbo? Not to mention that Inferno brings the ideas of Unix into the distributed environment world in the most beautiful way... Paraphrasing God Henry Spencer: Those who don't understand the work done at Bell Labs are doomed to reinvent it, poorly.

uriel

P.S.: And yes, for those still living under a rock, Both Inferno and Plan 9 are Open Source. Inferno: http://www.vitanuova.com/inferno/net_download4T.ht ml Plan 9: http://plan9.bell-labs.com/plan9dist/

P.P.S.: For those that don't know what Inferno is and to bypass SlashDot filters here is some text from Dennis M. Ritchie himself: Limbo is a programming language intended for applications running distributed systems on small computers. It supports modular programming, strong type checking at compile- and run-time, interprocess communication over typed channels, automatic garbage collection, and simple abstract data types.

And here is an extract from an interview with Ken God Thompson, creator of Unix and co-inventor of C:
Computer: How does your work on Plan 9 and Inferno derive from your earlier work on Unix? What are some of the new ideas arising out of this work that could and should apply to distributed operating systems in general?
Thompson: [...] In Plan 9 and Inferno, the key ideas are the protocol for communicating between components and the simplification and extension of particular concepts. In Plan 9, the key abstraction is the file system any thing you can read and write and select by names in a hierarchy and the protocol exports that abstraction to remote channels to enable distribution. Inferno works similarly, but it has a layer of language interaction above it through the Limbo language interface which is [somewhat] like Java, but cleaner.

This has been done before with Inferno/Limbo by CondeZer0 · 2004-09-12 09:28 · Score: 2, Interesting · on .Net On Lego Mindstorm

For people with good taste and that program in the language that was meant to be the true C successor: Limbo, we have had Styx-on-a-brick for a long time, and you can get the source for it too: http://www.vitanuova.com/inferno/co/rcx/

Styx-on-a-brick is really cool and fits directly into the Unix way of doing things:

% mount -A /net/legolink /n/remote % cd /n/remote % ls motor sensor % ls motor motor/0 motor/1 motor/2 motor/012 % ls sensor sensor/0 sensor/1 sensor/2 # Start motor... % cd motor % echo -n f7 > 0 # Reverse the motor... % echo -n r7 > 0 # Stop the motor... % echo -n F0 > 0 # Run the motor for 5 seconds... % echo -n r7 > 0; sleep 5; echo -n F0 > 0 # Ok, lets play with a sensor... % cd /n/remote/sensor % echo b0 > 0 % cat 0 0 # Click the button a few times and then try reading the sensor file again % cat 0 4 # Let's try a blocking read on the sensor % echo b5 > 0 % cat 0 # [click the button 5 times] 5 # Ok, we're done playing - unmount the brick namespace % ls /n/remote /n/remote/motor /n/remote/sensor % unmount /n/remote % ls /n/remote %

And then you can easily connect it an Inferno Grid: http://www.vitanuova.com/solutions/grid/demogrid.h tml

Why use a bad Java clone(that is what .NOT is after all) when you can use an elegant and KISS language like Limbo? Not to mention that Inferno brings the ideas of Unix into the distributed environment world in the most beautiful way... Paraphrasing God Henry Spencer: Those who don't understand the work done at Bell Labs are doomed to reinvent it, poorly.

uriel

P.S.: And yes, for those still living under a rock, Both Inferno and Plan 9 are Open Source. Inferno: http://www.vitanuova.com/inferno/net_download4T.ht ml Plan 9: http://plan9.bell-labs.com/plan9dist/

P.P.S.: For those that don't know what Inferno is and to bypass SlashDot filters here is some text from Dennis M. Ritchie himself: Limbo is a programming language intended for applications running distributed systems on small computers. It supports modular programming, strong type checking at compile- and run-time, interprocess communication over typed channels, automatic garbage collection, and simple abstract data types.

And here is an extract from an interview with Ken God Thompson, creator of Unix and co-inventor of C:
Computer: How does your work on Plan 9 and Inferno derive from your earlier work on Unix? What are some of the new ideas arising out of this work that could and should apply to distributed operating systems in general?
Thompson: [...] In Plan 9 and Inferno, the key ideas are the protocol for communicating between components and the simplification and extension of particular concepts. In Plan 9, the key abstraction is the file system any thing you can read and write and select by names in a hierarchy and the protocol exports that abstraction to remote channels to enable distribution. Inferno works similarly, but it has a layer of language interaction above it through the Limbo language interface which is [somewhat] like Java, but cleaner.

This has been done before with Inferno/Limbo by CondeZer0 · 2004-09-12 09:28 · Score: 2, Interesting · on .Net On Lego Mindstorm

For people with good taste and that program in the language that was meant to be the true C successor: Limbo, we have had Styx-on-a-brick for a long time, and you can get the source for it too: http://www.vitanuova.com/inferno/co/rcx/

Styx-on-a-brick is really cool and fits directly into the Unix way of doing things:

% mount -A /net/legolink /n/remote % cd /n/remote % ls motor sensor % ls motor motor/0 motor/1 motor/2 motor/012 % ls sensor sensor/0 sensor/1 sensor/2 # Start motor... % cd motor % echo -n f7 > 0 # Reverse the motor... % echo -n r7 > 0 # Stop the motor... % echo -n F0 > 0 # Run the motor for 5 seconds... % echo -n r7 > 0; sleep 5; echo -n F0 > 0 # Ok, lets play with a sensor... % cd /n/remote/sensor % echo b0 > 0 % cat 0 0 # Click the button a few times and then try reading the sensor file again % cat 0 4 # Let's try a blocking read on the sensor % echo b5 > 0 % cat 0 # [click the button 5 times] 5 # Ok, we're done playing - unmount the brick namespace % ls /n/remote /n/remote/motor /n/remote/sensor % unmount /n/remote % ls /n/remote %

And then you can easily connect it an Inferno Grid: http://www.vitanuova.com/solutions/grid/demogrid.h tml

Why use a bad Java clone(that is what .NOT is after all) when you can use an elegant and KISS language like Limbo? Not to mention that Inferno brings the ideas of Unix into the distributed environment world in the most beautiful way... Paraphrasing God Henry Spencer: Those who don't understand the work done at Bell Labs are doomed to reinvent it, poorly.

uriel

P.S.: And yes, for those still living under a rock, Both Inferno and Plan 9 are Open Source. Inferno: http://www.vitanuova.com/inferno/net_download4T.ht ml Plan 9: http://plan9.bell-labs.com/plan9dist/

P.P.S.: For those that don't know what Inferno is and to bypass SlashDot filters here is some text from Dennis M. Ritchie himself: Limbo is a programming language intended for applications running distributed systems on small computers. It supports modular programming, strong type checking at compile- and run-time, interprocess communication over typed channels, automatic garbage collection, and simple abstract data types.

And here is an extract from an interview with Ken God Thompson, creator of Unix and co-inventor of C:
Computer: How does your work on Plan 9 and Inferno derive from your earlier work on Unix? What are some of the new ideas arising out of this work that could and should apply to distributed operating systems in general?
Thompson: [...] In Plan 9 and Inferno, the key ideas are the protocol for communicating between components and the simplification and extension of particular concepts. In Plan 9, the key abstraction is the file system any thing you can read and write and select by names in a hierarchy and the protocol exports that abstraction to remote channels to enable distribution. Inferno works similarly, but it has a layer of language interaction above it through the Limbo language interface which is [somewhat] like Java, but cleaner.

Re:As far as I understand... by CondeZer0 · 2004-09-09 20:24 · Score: 1 · on Miguel de Icaza Debates Avalon with an Avalon Designer

What do you find interesting in a VMS and Java clones is beyond me, two of the worst technologies ever created in the history of software. Not to mention the most directly at odds with the Unix philosophy.

If you are going to "reshape this industry", you could at least try to do so into a less hideous new shape. (l)Unix has been dead for more than fifteen years[1], but better things have been around for almost as long.

If you like C but are tired of doing memory allocation, why don't you use the language that the creators of C spent twenty years designing[2] to overcome C limitations: Limbo

Rob Pike admitted that the main problems with C (as a high level language) are the lack of proper strings and the lack of garbage collection, with limbo you get that and a bunch of other really wonderful goodies, like the best parallel programming framework using CSP and the most beautiful and simple distributed environment thanks to 9p/Styx.

Not only that, but now Inferno/Limbo and Plan 9 are open source.

Note: Now you can even run most of Plan 9 user space under Linux: Plan 9 on Unix

[1] "Not only is UNIX dead, it's starting to smell really bad." -- Rob Pike circa 1991
[2] Directly or indirectly most languages developed at Bell Labs for the last 30 years have been predecessors of Limbo

Best wishes and I hope that some day you will correct your misguided ways

uriel

Re:As far as I understand... by CondeZer0 · 2004-09-09 20:24 · Score: 1 · on Miguel de Icaza Debates Avalon with an Avalon Designer

What do you find interesting in a VMS and Java clones is beyond me, two of the worst technologies ever created in the history of software. Not to mention the most directly at odds with the Unix philosophy.

If you are going to "reshape this industry", you could at least try to do so into a less hideous new shape. (l)Unix has been dead for more than fifteen years[1], but better things have been around for almost as long.

If you like C but are tired of doing memory allocation, why don't you use the language that the creators of C spent twenty years designing[2] to overcome C limitations: Limbo

Rob Pike admitted that the main problems with C (as a high level language) are the lack of proper strings and the lack of garbage collection, with limbo you get that and a bunch of other really wonderful goodies, like the best parallel programming framework using CSP and the most beautiful and simple distributed environment thanks to 9p/Styx.

Not only that, but now Inferno/Limbo and Plan 9 are open source.

Note: Now you can even run most of Plan 9 user space under Linux: Plan 9 on Unix

[1] "Not only is UNIX dead, it's starting to smell really bad." -- Rob Pike circa 1991
[2] Directly or indirectly most languages developed at Bell Labs for the last 30 years have been predecessors of Limbo

Best wishes and I hope that some day you will correct your misguided ways

uriel

Re:As far as I understand... by CondeZer0 · 2004-09-09 20:24 · Score: 1 · on Miguel de Icaza Debates Avalon with an Avalon Designer

What do you find interesting in a VMS and Java clones is beyond me, two of the worst technologies ever created in the history of software. Not to mention the most directly at odds with the Unix philosophy.

If you are going to "reshape this industry", you could at least try to do so into a less hideous new shape. (l)Unix has been dead for more than fifteen years[1], but better things have been around for almost as long.

If you like C but are tired of doing memory allocation, why don't you use the language that the creators of C spent twenty years designing[2] to overcome C limitations: Limbo

Rob Pike admitted that the main problems with C (as a high level language) are the lack of proper strings and the lack of garbage collection, with limbo you get that and a bunch of other really wonderful goodies, like the best parallel programming framework using CSP and the most beautiful and simple distributed environment thanks to 9p/Styx.

Not only that, but now Inferno/Limbo and Plan 9 are open source.

Note: Now you can even run most of Plan 9 user space under Linux: Plan 9 on Unix

[1] "Not only is UNIX dead, it's starting to smell really bad." -- Rob Pike circa 1991
[2] Directly or indirectly most languages developed at Bell Labs for the last 30 years have been predecessors of Limbo

Best wishes and I hope that some day you will correct your misguided ways

uriel

Re:As far as I understand... by CondeZer0 · 2004-09-09 20:24 · Score: 1 · on Miguel de Icaza Debates Avalon with an Avalon Designer

What do you find interesting in a VMS and Java clones is beyond me, two of the worst technologies ever created in the history of software. Not to mention the most directly at odds with the Unix philosophy.

If you are going to "reshape this industry", you could at least try to do so into a less hideous new shape. (l)Unix has been dead for more than fifteen years[1], but better things have been around for almost as long.

If you like C but are tired of doing memory allocation, why don't you use the language that the creators of C spent twenty years designing[2] to overcome C limitations: Limbo

Rob Pike admitted that the main problems with C (as a high level language) are the lack of proper strings and the lack of garbage collection, with limbo you get that and a bunch of other really wonderful goodies, like the best parallel programming framework using CSP and the most beautiful and simple distributed environment thanks to 9p/Styx.

Not only that, but now Inferno/Limbo and Plan 9 are open source.

Note: Now you can even run most of Plan 9 user space under Linux: Plan 9 on Unix

[1] "Not only is UNIX dead, it's starting to smell really bad." -- Rob Pike circa 1991
[2] Directly or indirectly most languages developed at Bell Labs for the last 30 years have been predecessors of Limbo

Best wishes and I hope that some day you will correct your misguided ways

uriel

Re:What's so tricky about WinFS? by I_redwolf · 2004-08-28 05:08 · Score: 1 · on Longhorn to be Released in 2006, Sans WinFS

That would be true if for except the small fact that open/closed source implementations already exist.

http://www.vitanuova.com/inferno/man/4/dbfs.html
http://www.eecs.harvard.edu/~vernal/learn/cs261r/d bfs-proposal.pdf
http://www.thyme.net/imp/dbfs.html
http://www.eamonwalsh.com/projects/masters/writeup .pdf
http://www.orafaq.com/faqifs.htm
http://relfs.sourceforge.net/Home.html

One could presumably go on.

Plan 9 by Leimy · 2004-07-31 03:56 · Score: 2, Interesting · on ANSI C89 and POSIX portability?

Plan 9 is/was the successor to Unix from the people who brought you Unix to begin with.

It's compiler suites, which approach multiple architectures a little differently, by default don't have hardly and ANSI C or POSIX support. If you need that stuff you have to use the APE frameworks. See this for more information.

The fact that it's not quite ANSI C and not quite POSIX by default shouldn't discourage you from playing with the OS though or even trying to use it. Apparently the "thin client" trend is coming back and Plan 9 systems support that metaphor quite nicely where everyone has a graphical display and a private hierarchical namespace [each process can have a different namespace in fact]. The OS is meant to be distributed across many nodes, with CPU nodes and File Serving nodes being part of a grid, but you can run it standalone fairly easily as well.

I've found that even though it doesn't have a great X implementation I can still VNC to other machines that do when I need X and that I can use ssh with their terminal emulator when I need to work with systems Plan 9 can't "mount" or "bind" into my namespace.

As you can probably tell. I was impressed.

If you don't want to mess with installing over you existing OS you can try Inferno which installs on Windows, Linux, FreeBSD and even MacOS X [but if you run Panther you will probably need this patched emulator and installer to make it work]. Once done you can build a multi-CPU-architecture grid all your own and learn the "Limbo" programming language and start harnessing those extra CPU cyucles. Inferno also supports thos hierarchical namespaces of Plan 9.

Re:UNIX forever? by JustinXB · 2004-07-26 03:10 · Score: 1 · on Unix's Founding Fathers

Check out Plan 9 from Bell Labs. It was designed by some of the people who worked on the original UNIX. It was designed to fix the problems they saw with UNIX. However, it is not based on UNIX. It's a great little OS that is sadly little known.

You can also check out Inferno. It's a cousin of Plan 9. It keeps most of the ideas of Plan 9 while adding many that have since been ported back to Plan 9. It's a virtual machine that can run on top of OSes or natively on hardware. It has it's own language, Limbo, that runs in the virtual machine and is truly cross-platform.

Both can be downloaded freely.

Re:I always wanted to get Minix .. by anothy · 2004-06-22 19:39 · Score: 3, Interesting · on Minix from Scratch Project Established

I always wanted to mess around the code on a simple, yet an operating system you could DO something with.

i highly recommend you check out Plan 9 and/or Inferno. they both come originally from the same Bell Labs group that originally developed unix. they're extremely well-written, with very good code readability and code size/functionality ratio. for serious study, there's an excellent book (PDF available, but you'll have to search the mailing list archives for details) annotating the source of (a slightly outdated version of) the kernel, in the style of the Lions book. both are under active development, and Inferno's had (limited) commercial uptake. i know at least two universities that have used them in OS courses. seriously tight systems.

Plan 9 also has the "distinction" of being the primary inspiration for Hurd, started because Plan 9 was not then free. Plan 9 and Inferno are now both open source, and Plan 9 is also OSI-style Open Source.

Re:Comments on microkernels... by Anonymous Coward · 2004-05-21 15:04 · Score: 0 · on More From Tanenbaum

Meet Plan 9 and Inferno.

Re:Mod parent up - there is no "grid computing" by rpeppe · 2004-05-20 00:46 · Score: 1 · on GGF and Grid Security

Interesting article, thanks. My favourite quote from it:

...low technical barriers to entry...

I had to laugh. Web services are so ludicrously complex that unless you use loads of existing (complex and platform-specific) software, the technical barriers to entry are remarkably high! I've implemented some web services stuff from scratch, and it's really not easy at all. The WSDL standard drags in many other standards.

Just for a laugh, I started to try to enumerate the standards referred to, directly and indirectly, from the WSDL. I ran out of time after getting two levels deep, but already the referred-to standards totalled 4.8MB (approx. 103000 lines)! And this is a "low technical barrier to entry"?!

This enormous complexity is simply not necessary to make a decent, general-purpose framework for program accessibility and interoperability. As an example, the Styx protocol is general purpose protocol that actually does considerably more than web services, but it is completely documented in under 42K (just over 1000 lines). It references only one other standard (UTF-8), (one that I didn't include in the above count for WSDL, even though it was referred to there). You can knock up a client or a server from scratch in a couple of days. It's light-weight enough that it can be implemented on tiny devices, such as the Lego brick.

Hence my initial question. What is it with all the web services stuff?

I'd be crying if I wasn't busy being sick.

Re:Mod parent up - there is no "grid computing" by rpeppe · 2004-05-20 00:46 · Score: 1 · on GGF and Grid Security

Interesting article, thanks. My favourite quote from it:

...low technical barriers to entry...

I had to laugh. Web services are so ludicrously complex that unless you use loads of existing (complex and platform-specific) software, the technical barriers to entry are remarkably high! I've implemented some web services stuff from scratch, and it's really not easy at all. The WSDL standard drags in many other standards.

Just for a laugh, I started to try to enumerate the standards referred to, directly and indirectly, from the WSDL. I ran out of time after getting two levels deep, but already the referred-to standards totalled 4.8MB (approx. 103000 lines)! And this is a "low technical barrier to entry"?!

This enormous complexity is simply not necessary to make a decent, general-purpose framework for program accessibility and interoperability. As an example, the Styx protocol is general purpose protocol that actually does considerably more than web services, but it is completely documented in under 42K (just over 1000 lines). It references only one other standard (UTF-8), (one that I didn't include in the above count for WSDL, even though it was referred to there). You can knock up a client or a server from scratch in a couple of days. It's light-weight enough that it can be implemented on tiny devices, such as the Lego brick.

Hence my initial question. What is it with all the web services stuff?

I'd be crying if I wasn't busy being sick.

Re:Grid computing will never be secure by rpeppe · 2004-05-17 06:40 · Score: 1 · on GGF and Grid Security

You don't need a VPN to have a secure grid system. For a start, a computational grid need not allow the grid coordinator to run anything on the nodes of the grid.

It seems to be a commonly held misconception that making your node part of a computational grid implies making all of its resources available in the absence of "physical" layers of security (e.g. VPN, virtual memory protection). This is not true - in the "client pull" model, a node on the grid can choose exactly what it cares to run - and if this is a selection from a small set of trusted programs which operate within certain limits, regardless of parameters, then the client is still secure.

As Bruce Schneier might say, there's no absolute level at which you can judge a system "secure". It's all about establishing a level of security that is acceptable to you.

For one example, the grid compute-farm s/w I wrote allows you to do this.

Re:really cool... by rpeppe · 2004-05-17 06:02 · Score: 4, Informative · on Inferno 4 Available for Download

Inferno isn't entirely about speeding things up through distributed computation, although we have done that - most importantly, it provides an appropriate set of tools for dealing with today's distributed, networked world.

By using a single, simple metaphor to represent external resources (a hierarchical filesystem with streamlined semantics), it's possible to write general purpose components that are not conceivable in other systems, because their resources are not available in such a uniform way.

For instance:

Distributed resources: A simple, but deeply-thought-out protocol allows access to a resource hierarchy to be made available, transport independently, through a channel. Thus, any resource in the filesystem can trivially be made available over the network. This includes graphics, network interfaces, serial devices, raw disks, user-level filesystems, user-level program interfaces, etc, etc.
Authentication: Inferno can use a single well-defined authentication protocol to secure access to all external resources in a transparent, end-to-end fashion. Applications need not have any knowledge of this, but nonetheless gain all the benefits. If you're using this stuff, you couldn't care less about 802.11 security (or lack of it) - it's irrelevant.
Transformation: it's easy to "layer" resources; for instance I could export a read-only version of a particular resource just by forbidding all Styx Twrite, Tremove, Twstat, etc operations.
Application transparency: because everything looks like a file, and all the traditional unix tools just work on files (or byte-streams - same difference), it's possible to use all of Inferno's unix-like tools directly on devices, or aspects of a program's external interface without any extra "glue" code at all. This vastly decreases the dev-time, as you can just write independent components, test them individually, and just stick 'em together to make the final application.

Basically it's all about isolating complexity, network and everything else, into independently verifiable bits; the system lets you plug it all together.

Almost all of the complexity in most conventional systems today comes from backward compatibility requirements. Inferno can do what it does by discarding that backward compatibility - the obvious cost is that it's quite an effort to get your old programs to run underneath it. However, for many applications, that's not an issue, whereas the unreasonable complexity of other "modern" systems is.

Re:really cool... by rpeppe · 2004-05-17 06:02 · Score: 4, Informative · on Inferno 4 Available for Download

Inferno isn't entirely about speeding things up through distributed computation, although we have done that - most importantly, it provides an appropriate set of tools for dealing with today's distributed, networked world.

By using a single, simple metaphor to represent external resources (a hierarchical filesystem with streamlined semantics), it's possible to write general purpose components that are not conceivable in other systems, because their resources are not available in such a uniform way.

For instance:

Distributed resources: A simple, but deeply-thought-out protocol allows access to a resource hierarchy to be made available, transport independently, through a channel. Thus, any resource in the filesystem can trivially be made available over the network. This includes graphics, network interfaces, serial devices, raw disks, user-level filesystems, user-level program interfaces, etc, etc.
Authentication: Inferno can use a single well-defined authentication protocol to secure access to all external resources in a transparent, end-to-end fashion. Applications need not have any knowledge of this, but nonetheless gain all the benefits. If you're using this stuff, you couldn't care less about 802.11 security (or lack of it) - it's irrelevant.
Transformation: it's easy to "layer" resources; for instance I could export a read-only version of a particular resource just by forbidding all Styx Twrite, Tremove, Twstat, etc operations.
Application transparency: because everything looks like a file, and all the traditional unix tools just work on files (or byte-streams - same difference), it's possible to use all of Inferno's unix-like tools directly on devices, or aspects of a program's external interface without any extra "glue" code at all. This vastly decreases the dev-time, as you can just write independent components, test them individually, and just stick 'em together to make the final application.

Basically it's all about isolating complexity, network and everything else, into independently verifiable bits; the system lets you plug it all together.

Almost all of the complexity in most conventional systems today comes from backward compatibility requirements. Inferno can do what it does by discarding that backward compatibility - the obvious cost is that it's quite an effort to get your old programs to run underneath it. However, for many applications, that's not an issue, whereas the unreasonable complexity of other "modern" systems is.

Re:really cool... by rpeppe · 2004-05-17 06:02 · Score: 4, Informative · on Inferno 4 Available for Download

Inferno isn't entirely about speeding things up through distributed computation, although we have done that - most importantly, it provides an appropriate set of tools for dealing with today's distributed, networked world.

By using a single, simple metaphor to represent external resources (a hierarchical filesystem with streamlined semantics), it's possible to write general purpose components that are not conceivable in other systems, because their resources are not available in such a uniform way.

For instance:

Distributed resources: A simple, but deeply-thought-out protocol allows access to a resource hierarchy to be made available, transport independently, through a channel. Thus, any resource in the filesystem can trivially be made available over the network. This includes graphics, network interfaces, serial devices, raw disks, user-level filesystems, user-level program interfaces, etc, etc.
Authentication: Inferno can use a single well-defined authentication protocol to secure access to all external resources in a transparent, end-to-end fashion. Applications need not have any knowledge of this, but nonetheless gain all the benefits. If you're using this stuff, you couldn't care less about 802.11 security (or lack of it) - it's irrelevant.
Transformation: it's easy to "layer" resources; for instance I could export a read-only version of a particular resource just by forbidding all Styx Twrite, Tremove, Twstat, etc operations.
Application transparency: because everything looks like a file, and all the traditional unix tools just work on files (or byte-streams - same difference), it's possible to use all of Inferno's unix-like tools directly on devices, or aspects of a program's external interface without any extra "glue" code at all. This vastly decreases the dev-time, as you can just write independent components, test them individually, and just stick 'em together to make the final application.

Basically it's all about isolating complexity, network and everything else, into independently verifiable bits; the system lets you plug it all together.

Almost all of the complexity in most conventional systems today comes from backward compatibility requirements. Inferno can do what it does by discarding that backward compatibility - the obvious cost is that it's quite an effort to get your old programs to run underneath it. However, for many applications, that's not an issue, whereas the unreasonable complexity of other "modern" systems is.

Re:Inferno? by rpeppe · 2004-05-17 02:55 · Score: 1 · on Inferno 4 Available for Download

expicit static typing to Python's dynamic typing. (I don't like either; I prefer ML-style type inference.)

Actually, Limbo does use a certain amount of type inference (although it doesn't go nearly as far as ML). I can say: x := y; and x will be given the same type as y and assigned its value. This is more useful when dealing with functions, e.g.

x := f(); g(x); h(x);

You don't need to know what the return type of f is called, but the code gets properly statically checked. This is more than just syntactic convenience; it makes code transformation easier, because the code has less dependencies.

declarations and definitions in separate files....When editing, it's much more friendly to change these in one place

Inferno is very much about reusable software - it is formed of specialised components that can plug together in many different ways in order to create the system you're after. The key here is to have specialised, replacable components with narrow interfaces. Limbo modules are designed with this in mind. The declaration and the definition of a Limbo module are two completely independent things. All modules are loaded dynamically (but with assured static type checking). When you write a module, you implement a particular interface. Many modules might implement an interface (each differently), and many modules might use a particular interface - it's the interface itself (the header file) which is the most important component. Hence it makes complete sense for this to be in its own file. Implementation and interface are two completely separable things (you can declare your own interface locally if you wish to be completely independent).

graphics through Tk. Meaning embedded strings in a completely different, interpreted programming language.

This is debatable. For a start, Limbo strings are dead easy to use, 'cos they're a first class type, like integers or reals. So strings are actually quite a convenient representation for many things within the language.

Also, a GUI toolkit is a really big and complex thing. If you do everything in the language proper, you have to map all the GUI concepts to abstractions within the language. This results in an interface that is really big, and not necessarily easier to use (although it will let the compiler do more checking).

The Limbo tk module interface is 25 lines, comprising a grand total of 10 functions. It's really quite easy to comprehend what's going on - and the fact that all commands are strings makes it trivial to write a little prototyping shell, where you can knock up little GUI components interactively, or experiment without having to write an limbo code. You can even write little UI components in the shell.

the channel feature you mentioned. It seems like a suckier version of Erlang's message-passing

Channels are one of Limbo's most important features. Unlike Erlang's message passing, Limbo's channels are strictly local affairs - and synchronous. They're used to solve a different problem from Erlang's messages - Erlang's messages are intentionally asynchronous and unreliable. If you wish to pass messages reliably between system components, you have to build some reliability on top.

Limbo's channels are designed to make it easy to manage concurrency. In a networked application, you've usually got many things happening simulataneously - very cheap processes and message passing down channels makes it easy to structure an application as separate, independent processes, each dealing with one aspect of the program's concurrent behaviour. The usual thread-library stuff (locks, semaphores, etc) is stone age compared to this.

I don't see any redeeming qualities

Try using it. You'd be pleasantly surprised. It really is a beautiful language.

Re:Compatible by mobby_6kl · 2004-05-16 20:59 · Score: 1 · on Inferno 4 Available for Download

Yes it is :) They've got a 98/NT "platform component" here

Re:I thought a better unix was ... by Tarantolato · 2004-05-16 19:01 · Score: 5, Informative · on Inferno 4 Available for Download

I thought a better unix was linux!

Linux is better mostly because it's free. It does not fix some of the imperfections in the core design (for good reasons; that would break Posix compatibility). According the Inferno Design Principles, Inferno takes Unix ideas and applies them more consistently. For instance: everything is a file. In Inferno, what you're typing in a text editor window can be queried in something like /gui/window/...etc. Also, the network protocol is entirely file-based. Your desktop system (or smartphone, or brower plugin) sees the server or another client as part of the same filesystem that its own resources sit in.

Re:Inferno? by frenetic3 · 2004-05-16 18:36 · Score: 4, Informative · on Inferno 4 Available for Download

If you look at some of the docs, there seem to be a bunch of Bell Labs folks contributing (perhaps even principal developers)... including a doc by Brian Kernighan and lo and behold, Dennis Ritchie, the authors of one of the canonical C books ("The C Programming Language" -- more affectionately known as "K&R".)

Could be interesting stuff, especially the Limbo "C-like, concurrent" programming language (though the syntax seems like an ugly version of Python with some bizarre odds and ends tacked on like a <- operator for "channels").

-fren

Re:Inferno? by frenetic3 · 2004-05-16 18:36 · Score: 4, Informative · on Inferno 4 Available for Download

If you look at some of the docs, there seem to be a bunch of Bell Labs folks contributing (perhaps even principal developers)... including a doc by Brian Kernighan and lo and behold, Dennis Ritchie, the authors of one of the canonical C books ("The C Programming Language" -- more affectionately known as "K&R".)

Could be interesting stuff, especially the Limbo "C-like, concurrent" programming language (though the syntax seems like an ugly version of Python with some bizarre odds and ends tacked on like a <- operator for "channels").

-fren

Re:Inferno? by frenetic3 · 2004-05-16 18:36 · Score: 4, Informative · on Inferno 4 Available for Download

If you look at some of the docs, there seem to be a bunch of Bell Labs folks contributing (perhaps even principal developers)... including a doc by Brian Kernighan and lo and behold, Dennis Ritchie, the authors of one of the canonical C books ("The C Programming Language" -- more affectionately known as "K&R".)

Could be interesting stuff, especially the Limbo "C-like, concurrent" programming language (though the syntax seems like an ugly version of Python with some bizarre odds and ends tacked on like a <- operator for "channels").

-fren

Good introduction to Limbo by harikiri · 2004-05-16 18:31 · Score: 5, Informative · on Inferno 4 Available for Download

...as in the programming language for Inferno, written by Brian Kernighan, is available here.

I've briefly looked into trying out Inferno, but bear in mind it's not designed as a desktop system. Instead, the market it seems to be used in is the embedded market - so it'd be interesting to see how easy you can write server apps for application boxes with it.

However, it initially appears that Limbo is the only way to program for Inferno (prove me wrong please), which would be an obvious impediment to developer take-up.

License by vinit79 · 2004-05-16 18:15 · Score: 3, Interesting · on Inferno 4 Available for Download

The VITA NUOVA LIBERAL SOURCE LICENCE seems to be pretty good (free as in speech).

Any ideas why they didint use GPL/BSD or any other standard license. Or is there some subtle(or obvious) licensing issue

Re:Hmmm... by Anonymous Coward · 2004-05-08 04:19 · Score: 0 · on Lucent: Down But Not Out

Well, there is Inferno, which was developed at Lucent. It's a cross-platform OS meant for highly-concurrent distributed applications. You can run it as a native operating system, or hosted under your existing OS. Like Java and .NET, it uses platform indepenedent executables, meant for its Dis VM. It uses a language called Limbo, which is designed by the same people behind Unix & C, although it is very different from C.

Re:Hmmm... by Anonymous Coward · 2004-05-08 04:19 · Score: 0 · on Lucent: Down But Not Out

Well, there is Inferno, which was developed at Lucent. It's a cross-platform OS meant for highly-concurrent distributed applications. You can run it as a native operating system, or hosted under your existing OS. Like Java and .NET, it uses platform indepenedent executables, meant for its Dis VM. It uses a language called Limbo, which is designed by the same people behind Unix & C, although it is very different from C.

Forget it. by CondeZer0 · 2004-05-08 03:47 · Score: 2, Interesting · on FireFox and Longhorn: Meant For Each Other?

I don't want that crap, and I don't want Gnome's crap either.

I want a web browser, if I wanted some kind of megalomaniac "application development platform" I will use Python, thank you very much.

And as long as they don't give me access to the source under an open source license I wont touch it. I have been burned once(Windows), twice(Java), I'm not going to get burned a third time, if you want me to rely on your software you better give me the source and let me fix it(or let others fix it).

As Al Viro, one of the very few reasonable Linux kernel developers, said:

All software sucks, be it open-source [or] proprietary. The only question is
what can be done with particular instance of suckage, and that's where having
the source matters.
-- viro [http://www.ussg.iu.edu/hypermail/linux/kernel/040 4.3/1344.html]

It's sad that we have to get to this, but in the current software industry having access to the source under a open source license is the only warranty that you are not going to be royally screwed, I don't want to be at the mercy of the economic targets of some random company, I already have enough trouble taking care of _my_ business.

Life is too short to run proprietary software.
-- Bdale Garbee

And as for Gnome, I will quote viro wise words again:

Yeah... "Infinitely extendable API" and all such. Roughly translated
as "we can't live without API bloat". Frankly, judging by the GNOME
codebase people who designed the thing[GNOME] are culturally incompatible
with UNIX.

And yea, that is you, my dear Miguel, you have as little clue as RMS of what Unix is all about, I advice you that when you get tired of all that .NOT gratuitous complexity and over-designed crap you take a look at the only sane OS left: Plan 9; and if you are tired of doing "memory management", why don't you use Limbo (The Limbo Programming Language by Dennis M. Ritchie)?

uriel

Re:kinda OT by DrSkwid · 2004-05-07 08:42 · Score: 1 · on Pike 7.6 Released

Here's the protocol

http://plan9.bell-labs.com/sys/man/5/INDEX.html

one supplies an offset and count and the server returns whatever data it feels like.

So yes, you are free to play games with the units be it bytes or timecode.

one issues :
size[4] Tread tag[2] fid[4] offset[8] count[4]

and gets returned
size[4] Rread tag[2] count[4] data[count]

tag is an ID for this request, fid is an id for the file
size is the packet size, the rest is the payload.

The thing you would have to be careful of, though, is the maximum 9p packet size, which is usually set to 8k though this is negotiable.

I can imagine some system that facilitates MPEG editing by representing the MPEG as RGB24 full frames or even multiple channels for the RGB video channels or even s YUV. There's plenty of scope.

inferno also uses a 9p variant protocol, Styx, to do much the same thing. You can run Inferno as an application . Inferno as an application is a virtualized OS but aimed at embedded devices, PDAs etc.

novel debugging was implemented in Plan9...in 1994 by Anonymous Coward · 2004-05-02 05:51 · Score: 0 · on New & Revolutionary Debugging Techniques?

see this link to ACID whitepaper

also see this portion of the Inferno manual.

and this entry on citeseer.

*the* AC

Simplicity is more important by CondeZer0 · 2004-05-02 05:05 · Score: 3, Informative · on New & Revolutionary Debugging Techniques?

25 years later I still agree with Kernighan:

The most effective debugging tool is still careful thought, coupled with
judiciously placed print statements.

-- Brian W. Kernighan, in the paper Unix for Beginners (1979)

But I think the key to debugging is not the technique used for debugging, but how one wrote the code in the first place, here again God Kernighan hits the nail in the head:

Debugging is twice as hard as writing the code in the first place. Therefore,
if you write the code as cleverly as possible, you are, by definition, not
smart enough to debug it.

-- Brian W. Kernighan

Once again, at the time of debugging, simplicity shows it's superiority to the complexity that seems to be so much in fashion this days. That is why I still prefer C to C++; rc to bash; AWK/sed to Perl; Plan 9 to Linux; Limbo to Java; 9p to NFS,...

This is the forgotten key to software design: ...there are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies and the other way is to make
it so complicated that there are no obvious deficiencies.

-- C.A.R. Hoare, The 1980 ACM Turing Award Lecture

Or put in another way:

The cheapest, fastest, and most reliable components are those that aren't there.

-- Gordon Bell

Back in the topic of debugging, aside from the sacred printf, the Plan 9 debugger acid is often helpful, and now you can even use it on Linux/BSD!

Plan 9 on Unix

Also the chapter on debugging in The Practice of Programming by Brian W. Kernighan and Rob Pike is very good.

Always remember:

Simplicity
Clarity
Generality

Re:Limbo is the only legitimate successor of C by Dawn+Keyhotie · 2004-04-19 06:59 · Score: 2, Informative · on C, Objective-C, C++... D! Future Or failure?

To quote from the lead-in to your referenced documentation by Kernighan:

"Limbo is strongly typed, provides automatic garbage collection, supports only very restricted pointers, and compiles into machine-independent byte code for execution on a virtual machine."

This pretty much disqualifies Limbo as a successor language to C. C is a systems programming language, not a byte-code interpreted play-toy.

Cheers!