The future of TUNES

[Tom Novelli]

Greetings all,

It seems that despite efforts to revive it, the Tunes project has been
dormant for 5 years or so. There are 17 people on this mailing list,
and most of us are working on something that's somehow related to
Tunes, but as a cohesive effort there's nothing happening. I'm not
hopeful that that'll change, as explained in my 'post-mortem' essay
[1] on Tunes, written last year. Bottom line, I think Tunes was
sidelined by the consumerization of computing, and maybe Tunes was too
ambitious anyhow. I don't know how you all feel, but that's my
opinion.

What's next? Do we update the website to say the project is inactive,
and just keep this mailing list around as a "computer visionaries'
club"? Close the list too? Or does someone want to keep Tunes going?

Thanks,
Tom

References
1. http://tnovelli.net/dream/tunes2010.html

[Brian Rice]

On Mon, Jan 10, 2011 at 3:15 PM, Tom Novelli <tnov...@gmail.com> wrote:

Greetings all,

It seems that despite efforts to revive it, the Tunes project has been
dormant for 5 years or so.  There are 17 people on this mailing list,
and most of us are working on something that's somehow related to
Tunes, but as a cohesive effort there's nothing happening.  I'm not
hopeful that that'll change, as explained in my 'post-mortem' essay
[1] on Tunes, written last year.  Bottom line, I think Tunes was
sidelined by the consumerization of computing, and maybe Tunes was too
ambitious anyhow.  I don't know how you all feel, but that's my
opinion.

I'll respond quickly, to mainly say that I agree with your overall assessment, and that we've all matured quite a bit since the project's initial run. I still feel that TUNES ideas are the core of what I want to promote in my career, and am working still on Slate (and now Atomo with a young undergrad) to develop as many of the ideas as possible on the language-side of the approach. There is also the FONC effort which is relevant but not externally visible yet.

What's next?  Do we update the website to say the project is inactive,
and just keep this mailing list around as a "computer visionaries'
club"?  Close the list too?  Or does someone want to keep Tunes going?

I'm not sure, but I want to keep some kind of ongoing discussion thread about the vision and where current software progress fits into that. There are plenty of places now to discuss topics like these in a larger setting but very few venues that can focus on an overall guiding philosophy and vision for the future. Rather than (say) a programming language popularity/coolness match. Certainly the commoditization of virtualization makes the reach of strange systems ideas a little easier.

Maybe I'll have more to say later once I've had some time to consider our possibilities. It has occurred to me to just "re-brand" every TUNES idea into different garb/language but I haven't put something coherent together around that yet.

Thanks,
Tom

References
1. http://tnovelli.net/dream/tunes2010.html

--
-Brian T. Rice

[Quarzoliquido]

I'm seeing this list from some months ago, but i'm checking tunes.org
from 2002, my silence is lack of understanding from these topics (i
can't code more than XML, XHTML), i'm thirsty about news from TUNES,
being good or bad news, i prefer that than silence.

Good luck guys,
QuarzoLiquido

[Tom Novelli]

On Wed, Jan 12, 2011 at 2:47 PM, Quarzoliquido <cuarzo...@gmail.com> wrote:

I'm seeing this list from some months ago, but i'm checking tunes.org
from 2002, my silence is lack of understanding from these topics (i
can't code more than XML, XHTML), i'm thirsty about news from TUNES,
being good or bad news, i prefer that than silence.

 

It's interesting that you're still following Tunes.  You must have a lot of patience, and I suppose you appreciate Tunes for what it is (a quiet, thoughtful, constructive conversation among geeks, charitably speaking) rather than what it was intended to be (software you can use).

 

Good luck guys,
QuarzoLiquido

Thanks!

-Tom 

[Quarzoliquido]

Hello, Tom,
In fact, if in TUNES hasn't much code to see, there exist an amount of
knowledge that makes this places a good chance for discuss over the
orthodox technology. At least, here are many new ideas that will
became real, due to these talks.

~QuarzoLiquido

[Tom Novelli]

On Mon, Jan 10, 2011 at 6:29 PM, Brian Rice <brian...@gmail.com> wrote:

On Mon, Jan 10, 2011 at 3:15 PM, Tom Novelli <tnov...@gmail.com> wrote:

Greetings all,

It seems that despite efforts to revive it, the Tunes project has been
dormant for 5 years or so.  There are 17 people on this mailing list,
and most of us are working on something that's somehow related to
Tunes, but as a cohesive effort there's nothing happening.  I'm not
hopeful that that'll change, as explained in my 'post-mortem' essay
[1] on Tunes, written last year.  Bottom line, I think Tunes was
sidelined by the consumerization of computing, and maybe Tunes was too
ambitious anyhow.  I don't know how you all feel, but that's my
opinion.

I'll respond quickly, to mainly say that I agree with your overall assessment, and that we've all matured quite a bit since the project's initial run. I still feel that TUNES ideas are the core of what I want to promote in my career, and am working still on Slate (and now Atomo with a young undergrad) to develop as many of the ideas as possible on the language-side of the approach. There is also the FONC effort which is relevant but not externally visible yet.

Oh yeah, FONC is notable for their emphasis on implementation simplicity.  I've seen their META-style parser (OMeta) and their compiler/VM bootstrapping project (idst/Pepsi), but I haven't followed what they're doing for the past year or two.  Their wiki says they're working on hardware description/modeling, static-dynamic continuums, OLPC hacking, graphics libraries, etc.  Some of that is just to see how new ideas work out in practice.  Would you say FONC is more focused on the low level, while you're focused on high-level language design with Slate, and Atomo is a 'kernelization' of Smalltalk?

 

What's next?  Do we update the website to say the project is inactive,
and just keep this mailing list around as a "computer visionaries'
club"?  Close the list too?  Or does someone want to keep Tunes going?

I'm not sure, but I want to keep some kind of ongoing discussion thread about the vision and where current software progress fits into that. There are plenty of places now to discuss topics like these in a larger setting but very few venues that can focus on an overall guiding philosophy and vision for the future. Rather than (say) a programming language popularity/coolness match. Certainly the commoditization of virtualization makes the reach of strange systems ideas a little easier.

Maybe I'll have more to say later once I've had some time to consider our possibilities. It has occurred to me to just "re-brand" every TUNES idea into different garb/language but I haven't put something coherent together around that yet.

Yeah, it would be nice to get this discussion going again, and forget about maintaining a website/wiki (which never seemed to serve TUNES very well).  All we really need is a brief FAQ to explain the purpose of this group and the original (or revised) guiding philosophy -- which basically comes down to "freedom and utility", right?  We'd have to expound upon how that applies to software.

I'd say collaborative development is no longer part of TUNES' purpose.  Historically, most of the successful software R&D projects (e.g. Unix; I said successful, not ideal) were conceived and initially developed by 1 to 5 people (at a single institution) with very modest goals -- not by diverse committees with grand visions.  We're 

working on separate projects and that's fine.  We don't want collaboration to undermine individual efforts -- one of which may be the next big success (and the others forgotten... a humbling thought.)

This is the kind of forum I would like to see: thoughtful, slow-paced, not too demanding on my time, somewhat formal, respectful, visionary but grounded in reality, not too extreme.  I want to discourage trolling, attention-seeking, blatant self-promotion, inane comments, and flamewars (which were problems here way back in the 1990s).  I think we can agree to disagree... we should welcome opposing opinions instead of shooting them down.  I wish Google Groups had an option to delay message delivery for a day or two, snail-mail pace, just to cool down heated conversations. :)

Some topics for discussion:

- Re-branding TUNES ideas/jargon, or changing the language of computer science/tech in general.

- The impact of virtualization... and, is it a long-term solution or just a stepping stone?

- Simplifying TUNES ideas in light of the profusion of cheap little special-purpose computer gadgets.

- Ideas for a fully decentralized Internet, and for a sane alternative to the WWW.

- Reflections on the achievements and shortcomings of web frameworks like Django, Seaside, jQuery...

- Science fiction ideas?  Sci-fi writers can be instrumental in shaping and disseminating technological visions.

--

Tom Novelli

[Chirag Anand]

Hey, sorry for the late reply. But here are my few bits on the TUNES
project.

I agree with the things which you said in that blog, and not being a
part of the core team, I can't say much about the problems which lead to
this state of TUNES.
But generally saying that I've been a fan of the site since my college
days, using it as a source of wide information about operating systems,
languages etc. I still use the wiki for my own small project.

I've been involved in kernel development myself, though I am not that
experienced with it, but I think I would like to get involved or in
trying to revive it again. Being still in my 20s, my opinion is that TUNES
still has a lot of potential, and it would be worth another shot with it?
Everone learns from mistakes, and we can try avoiding them this time?
Anyones who can contribute to the project in some way or the other,
should do it. Yes, our lives are busy, but we do have time to make at
least one commit in say 5 months (just saying). I know that there will be
lots of planning which still needs to be done, and at least some
timeline is required.

I might not be experienced enough to do all of the above, its just that,
I wanted to let you guys know, that I'm game!

--
Regards
Chirag Anand

Blog: http://techfreaks4u.com/blog/?author=16
anything weird is worth a try...

[Tom Novelli]

On Mon, 31 Jan 2011 05:24:25 +0530
Chirag Anand <anand....@gmail.com> wrote:
>
> Hey, sorry for the late reply. But here are my few bits on the TUNES
> project.
>
> I agree with the things which you said in that blog, and not being a
> part of the core team, I can't say much about the problems which lead
> to this state of TUNES.
> But generally saying that I've been a fan of the site since my college
> days, using it as a source of wide information about operating
> systems, languages etc. I still use the wiki for my own small project.

Great, glad to hear it's useful to you. Too bad it's no longer
editable, but I don't think we have the energy to edit it like we did
when we were mostly students. Other students are probably doing the
same thing now... hopefully evaluating current projects through the
lens of history...

> I've been involved in kernel development myself, though I am not that
> experienced with it, but I think I would like to get involved or in
> trying to revive it again. Being still in my 20s, my opinion is that
> TUNES still has a lot of potential, and it would be worth another
> shot with it? Everone learns from mistakes, and we can try avoiding
> them this time? Anyones who can contribute to the project in some way
> or the other, should do it. Yes, our lives are busy, but we do have
> time to make at least one commit in say 5 months (just saying). I
> know that there will be lots of planning which still needs to be
> done, and at least some timeline is required.
>
> I might not be experienced enough to do all of the above, its just
> that, I wanted to let you guys know, that I'm game!

Hmm... I gather from your blog that you're interested in doing
self-modifying code (or dynamic compilation) in an OS kernel, either by
modifying Linux or starting from scratch (booting with GRUB - a
sensible expedient). Sure, why not. OpenGL drivers already do it
(badly, in most cases) in order to compile GPU code. People have
'embedded' interactive interpreters/compilers in kernel modules...
Richard Hohensee did that with H3SM about 10 years ago, and there have
been others since. Seems like a good way to try out kernel development
in other languages, and to interactively debug kernel code.

Linux and C really aren't that bad. At least C is simple, stable, and
easy to interface with at the machine code level. I've played with
Python, Ruby, Javascript, Lisp, Scheme, Lua, and C++ in the last few
years, but I'm back to C as a compiler implementation language. At
least C is stable, consistent, ubiquitous, and easy to interface with at
the machine level. Linux is heavily supported by corporate users who
care more about servers, but we *could* fork it and transform it into a
simpler OS for us programmer-users... of course, that's still a ton of
work.

Let's keep talking...

Tom

[Loki Verloren]

i see it's now been a few years even since there was any activity here, but maybe i can kickstart some activity with some suggestions. part of the reason why, in the past, radical projects that change the basic architecture of operating systems never got very far was for lack of a commercial hardware product or app development community to surround it, probably more important is the latter. however, now that we have an operating system like android, in which the linux core is put right into the background, and in the foreground, a high level language bytecode virtual machine... this is a perfect opportunity for someone to revive a project like this, stick on top of it the java VM of android, dalvik, and show the advantages of radical change in the underlying system architecture. another area, that was somewhat discussed in the early days was servers, i think web servers, back in the day, but right now, to take one of these new generation nosql type databases like foundationdb, on top of a riding bare metal core like TUNES... compounding the 25x+ boost in read/write performance of these new types of databases, with completely reprogrammable file and network access systems, it could be something that actually goes somewhere. all someone needs to do is cook up a good marketing campaign to get seed funding from angels, and bam, back in action. 

i am now following very closely a new project called 'ethereum', i think that if this system were layered on top of a nokernel core, that the two things would naturally reinforce, as the distributed processing side of ethereum is very much open-ended and anarchic in its structure, same on the outside as tunes project is on the inside.

but in these times, there is loads of money being thrown at sometimes very flimsy ideas, and the cost of turning out a hardware device has dropped so low - if a no kernel system were put on one of these shiny new risc based low-power systems and demonstrated the massive performance increase found by tunes devs back in the early days, that it could start some serious work again on rethinking the core. right now, even microkernels, despite their major advantages, are still not in many devices, save for blackberries with their qnx core. the nt and x kernels are marginally better than the monolithic kernels, but fundamentally, why do we have to be locked into one choice for threading and resource arbitration at kernel level? 

sooner or later it's going to be back on the table, and i think sooner is maybe sooner than we think. a no-kernel system could run libos' of android and gnu/linux and win32 and what have you, with kernel-privileged speed jit compilers and bytecode engines, in theory it could be possible to even have a system capable of running multiple platform applications on it seamlessly and concurrently. probably not so important for handheld devices but more useful for server systems, but with tech like ethereum and bitcoin, to be able to run a high performance, low latency server based system, which is what all p2p systems are, the latency properties of a nokernel system could be precisely the thing that pushes this tech forward even faster as it could potentially be utilising every last millisecond to much greater advantage than on top of a monolithic or hybrid kernel. plus there is the distributed processing angle. every millisecond counts, especially with blockchain systems. 

i think that all we need to see to have this topic come back to the surface is to have someone demonstrate these new bytecode virtual machines running on bare metal, eliminating the advantage of native code by taking out the latency of kernel protection.

just some thoughts, anyway.

[Hendrik Boom]

On Sat, Dec 13, 2014 at 12:37:57PM -0800, Loki Verloren wrote:
> i see it's now been a few years even since there was any activity here, but
> maybe i can kickstart some activity with some suggestions. part of the
> reason why, in the past, radical projects that change the basic
> architecture of operating systems never got very far was for lack of a
> commercial hardware product or app development community to surround it,
> probably more important is the latter. however, now that we have an
> operating system like android, in which the linux core is put right into
> the background, and in the foreground, a high level language bytecode
> virtual machine... this is a perfect opportunity for someone to revive a
> project like this, stick on top of it the java VM of android, dalvik, and
> show the advantages of radical change in the underlying system
> architecture.

Android isn't the only one.

You might be interested in the relatively unknown OS called Inferno.

Remember Plan 9? WHich Bell Labs developed after Unix more of less
with hindsight as "Unix done right"? Well, Inferno was developed by
Bell Laps as Plan 0 done right. While Bell Labs was submerged in a
series of corporate takeovers, Inferno has surfaced under several free
licenses. Have a look at http://www.vitanuova.com/inferno/ They're
selling it under proprietary licenses, but also distribute it for free
under the GPL.

Inferno contains yet another programming language, Styx, which is
implemented in bytecode, and is well-integrated into the way Inferno
works. Inferno is available on bare metal, or as a program in user
space on Linux, Windows, and Mac.

I had to umzip the distro and look around to find the pdf files that
contain the styx documentation, but it's worth a read. Look at the
relevant Wikipedia entries, too.

In Inferno, everything's a file. Or rather everything's in teh file
system, which isn't quite the same thing.

It's not the self-verifying, self-implementing OS that Tunes wants, but
it is interesting,

> another area, that was somewhat discussed in the early days
> was servers, i think web servers, back in the day, but right now, to take
> one of these new generation nosql type databases like foundationdb, on top
> of a riding bare metal core like TUNES... compounding the 25x+ boost in
> read/write performance of these new types of databases, with completely
> reprogrammable file and network access systems, it could be something that
> actually goes somewhere. all someone needs to do is cook up a good
> marketing campaign to get seed funding from angels, and bam, back in
> action.
>
> i am now following very closely a new project called 'ethereum', i think
> that if this system were layered on top of a nokernel core, that the two
> things would naturally reinforce, as the distributed processing side of
> ethereum is very much open-ended and anarchic in its structure, same on the
> outside as tunes project is on the inside.

Links, please?

>
> but in these times, there is loads of money being thrown at sometimes very
> flimsy ideas, and the cost of turning out a hardware device has dropped so
> low - if a no kernel system were put on one of these shiny new risc based
> low-power systems and demonstrated the massive performance increase found
> by tunes devs back in the early days, that it could start some serious work
> again on rethinking the core. right now, even microkernels, despite their
> major advantages, are still not in many devices, save for blackberries with
> their qnx core. the nt and x kernels are marginally better than the
> monolithic kernels, but fundamentally, why do we have to be locked into one
> choice for threading and resource arbitration at kernel level?

The choice that *has* to be made is the choice of protocols for
resource arbitration. Not the actual arbitration, but unless disparate
processes agree on how they communicate, they cannot.

>
> sooner or later it's going to be back on the table, and i think sooner is
> maybe sooner than we think. a no-kernel system could run libos' of android
> and gnu/linux and win32 and what have you, with kernel-privileged speed jit
> compilers and bytecode engines, in theory it could be possible to even have
> a system capable of running multiple platform applications on it seamlessly
> and concurrently. probably not so important for handheld devices but more
> useful for server systems, but with tech like ethereum and bitcoin, to be
> able to run a high performance, low latency server based system, which is
> what all p2p systems are, the latency properties of a nokernel system could
> be precisely the thing that pushes this tech forward even faster as it
> could potentially be utilising every last millisecond to much greater
> advantage than on top of a monolithic or hybrid kernel. plus there is the
> distributed processing angle. every millisecond counts, especially with
> blockchain systems.
>
> i think that all we need to see to have this topic come back to the surface
> is to have someone demonstrate these new bytecode virtual machines running
> on bare metal, eliminating the advantage of native code by taking out the
> latency of kernel protection.

For some bytecodes, the code desity gained by using the bytecode means
less time reading it from secondary storage. Even with the loader
using CPU time to translate the bytecode to machine code, it's still a
win.

>
> just some thoughts, anyway.
>
> On Tuesday, 11 January 2011 00:15:35 UTC+1, Tom Novelli wrote:
> >
> > Greetings all,
> >
> > It seems that despite efforts to revive it, the Tunes project has been
> > dormant for 5 years or so. There are 17 people on this mailing list,
> > and most of us are working on something that's somehow related to
> > Tunes, but as a cohesive effort there's nothing happening. I'm not
> > hopeful that that'll change, as explained in my 'post-mortem' essay
> > [1] on Tunes, written last year. Bottom line, I think Tunes was
> > sidelined by the consumerization of computing, and maybe Tunes was too
> > ambitious anyhow. I don't know how you all feel, but that's my
> > opinion.

Definitely too ambitious. Though all my dreams are too ambitious, and
some fit into the general drift of TUNES. I'm currently working on a
new type-based proof checker. Yet another one. My last was written in
the 80's in an idiosyncratic dialect of Scheme without continuations and a
number of syntaxx changes. I still have most of the source code.

It's based on constructive type theory, which means that the concept of
proof is more oor less equivalent to the concept of a program. I'd
like the programs to resemble the programs we normally code, rather
then being in a rather restrictive normal-order lazy-evaluation
pure-functional language.

I don't mind adapting the language to the proof system, but my ancient
project has definitely gone too far in th8is direction.

> >
> > What's next? Do we update the website to say the project is inactive,
> > and just keep this mailing list around as a "computer visionaries'
> > club"? Close the list too? Or does someone want to keep Tunes going?

Keep it open. Admit it's, for the most part, inactive. Admit that is
was too ambitious. But a computer visionaries' club is still useful,
and the website has a lot of useful information on it.

If the website is to be shut down, let me know, so I can clone it, just
in case.

***

Should I try documenting some of this ancient stuff?
Should I try posting what I'm working on online while it's still in
typo-filled drf stages for comments and critique, long before it
crystallizes into code?
Will I get any replies to these posting so I'll get useful feedback?

***

My pie-in-the-sky projects. Only a few have any real effort behind
them.

A self-verifying verifier cum programming language.

A document format for word processors, document compilers, web sites,
articles, essays, books, and programs, and works well with
distributed revision control systems like monotone and git.

A distributed, replicated wiki.

A way of organising a file system to make it actually possible to find
things.

A few novels.

-- hendrik

> >
> > Thanks,
> > Tom
> >
> > References
> > 1. http://tnovelli.net/dream/tunes2010.html
>

> --
> You received this message because you are subscribed to the Google Groups "TUNES Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tunes-projec...@googlegroups.com.
> To post to this group, send email to tunes-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/tunes-project.
> For more options, visit https://groups.google.com/d/optout.

[Charles Turner]

Hi Hendrik,

On 13 December 2014 at 23:21, Hendrik Boom <hen...@topoi.pooq.com> wrote:
> For some bytecodes, the code desity gained by using the bytecode means
> less time reading it from secondary storage. Even with the loader
> using CPU time to translate the bytecode to machine code, it's still a
> win.

That sounds interesting. Can you elaborate more, or provide links to
experiments demonstrating it please?

Thanks!
Charlie.

[Hendrik Boom]

This was done with Wirth's Oberon, and is described in an article in
the Communications of the ACM called something like "Slim binaries"

http://dl.acm.org/citation.cfm?id=265576 but you have to be a ACM
member so as to read more than the abstract. Or find a local
academic dead-tree library.

http://wiki.tcl.tk/4400 some discussion about it.

Google "slim binaries" for more information.

There;s a link I don't have permissin to access on out own
http://tunes.org/wiki/slim_20binaries.html

-- hendrik

>
> Thanks!
> Charlie.

[David Barbour]

On Sat, Dec 13, 2014 at 2:37 PM, Loki Verloren <loki.v...@gmail.com> wrote:

a no-kernel system could run libos' of android and gnu/linux and win32 and what have you, with kernel-privileged speed jit compilers and bytecode engines, in theory it could be possible to even have a system capable of running multiple platform applications on it seamlessly and concurrently.

I think a promising area for a revived Tunes project would be unikernels [1] and lightweight virtual machines like VirtualBox, to be run as VPS or cloud processors. Another interesting area to target might be VR and AR systems, where latency is a serious problem and the market is very open to new ideas.

[1] http://queue.acm.org/detail.cfm?id=2566628

On Tuesday, 11 January 2011 00:15:35 UTC+1, Tom Novelli wrote:

There are 17 people on this mailing list, and most of us are 

working on something that's somehow related to Tunes

It would be lovely to have a summary of person→project (with hyperlinks). 

 

Tunes was sidelined by the consumerization of computing

I have an outsider's perspective on this. I only encountered Tunes after the project was dying.

I think Tunes failed more because the vision grew more ambitious than anyone knew how to concretely accomplish. The project became a big brainstorming session. People were tossing in ideas like "self-extensible syntax" and "automatic interface generation" without clearly evaluating them and their roles, nor investigating their concrete realizations and problematic feature interactions. Nobody was keeping Tunes grounded and well founded.

Several of the design cornerstones were very questionable. As a specific example: Reflection breaks abstractions and compromises security and hinders source-transforming optimizations, so it should require some pretty hefty justifications. Its description in the manifesto was just '...', from which I infer that reflection (and alternatives, variants, etc.) were not deeply evaluated. Nonetheless, it became a major point of Tunes design. A mistake, IMO. 

 

What's next?  Do we update the website to say the project is inactive, 

and just keep this mailing list around as a "computer visionaries' 

club"?  Close the list too?  Or does someone want to keep Tunes going? 

 

It might be neat to re-read the original manifestos and discuss. 

I'd also be interested in some Tunes developer's opinions on my re-envisioning of at least some major aspects of the Tunes vision [2].

[1] http://tunes.org/papers/WhyNewOS/WhyNewOS.html

[2] https://groups.google.com/d/msg/reactive-demand/gazxhLLXscQ/_2YpJ6b3-6sJ

[David Barbour]

Arthur Whitney's K language is interpreted, but frequently achieves excellent performance comparable with compiled and hand-optimized code because the amount of computation per token read is very high. 

I imagine a collection-oriented bytecode could achieve similar properties.

 

[Hendrik Boom]

On Sat, Dec 13, 2014 at 11:40:41PM +0000, Charles Turner wrote:

Of course there's also the Styx language, part of the Inferno OS I mentioned.
It's also compiled to bytecode and (I believe) subsequently translated
to machine code. Though there are likely also machines where it is
simply interpreted because the translation to machine code hasn't been
implemented yet.

>
> Thanks!
> Charlie.

[Hendrik Boom]

On Sat, Dec 13, 2014 at 12:37:57PM -0800, Loki Verloren wrote:

> i see it's now been a few years even since there was any activity here, but
> maybe i can kickstart some activity with some suggestions.

It probably is time for me to try too document some of my personal
projects, because they seem to be TUNES-relevant.

Is the TUNES website still in operation, or am I viewing an inert
archive at tunes.org?

Is it possible for me to sign up and become a participant, placing
documents on the wiki and so forth?

My current web page is rather disorganised at
http://topoi.pooq.com/hendrik
I'd have rather more incentive to document what I'm doing, what I've
done, and tentative progress on what's current if it were on a site
thhat has some chance of people actually looking at it.

And I think some of it is relevant.

- hendrik

[Tom Novelli]

On Sat, Dec 13, 2014 at 8:23 PM, Hendrik Boom <hen...@topoi.pooq.com> wrote:

Is the TUNES website still in operation, or am I viewing an inert
archive at tunes.org?

Is it possible for me to sign up and become a participant, placing
documents on the wiki and so forth?

It's an archive, 100% static HTML including the wiki.  As far as I know the site hasn't been touched since 2011, and the only TUNES activity (such as it is) is here.

I have no interest in reviving TUNES.  Better to start fresh, set achievable goals, and have a BDFL.

-Tom

[Vaše jméno]

my notes (and a work-in-progress prototype), fwiw:
https://docs.google.com/document/d/1NQCoEghY5rGyEx9tRulQlPz8Do1JPA8O-uoLq3tpTJk/pub
confusing and messy and not too interesting, i know;)

Dne neděle, 14. prosince 2014 2:54:26 UTC+1 Tom Novelli napsal(a):

[Hendrik Boom]

On Sun, Dec 14, 2014 at 11:10:41AM -0800, Vaše jméno wrote:
> my notes (and a work-in-progress prototype), fwiw:
> https://docs.google.com/document/d/1NQCoEghY5rGyEx9tRulQlPz8Do1JPA8O-uoLq3tpTJk/pub
> confusing and messy and not too interesting, i know;)

Indded. Confusing, but also puzzling. It looks as if it might be interesting if I
could understand it.

My first questions:

What are they notes about?
What it the protoype a prototype *for*?

-- hendrik

[Vaše jméno]

lemon is a projectional editor and hopefully one day also a language/shell inside it. You could say a desktop environment, or im curious to try using lemon as a basis of a user interface to some user-level functionality. The notes are centered around it but cover everything related, its hard to draw a line. There are links explaining the whys and hows of projectinal editors and other language topics, and an attempt to analyze similar projects.

More questions?:)

i will surely announce it if lemon ever reaches alpha or something. Im in the middle of rewriting the frontend, and then i want to work on a more serious language and parser integration (marpa). If anyone thinks they can advise on building a visual language, or knows standard programming language theory but can think outside of the box, or maybe thinks that we could turn parts of the notes themselves into something generally useful, let me know


Dne neděle, 14. prosince 2014 20:44:27 UTC+1 Hendrik Boom napsal(a):

[Hendrik Boom]

On Sat, Dec 13, 2014 at 08:54:24PM -0500, Tom Novelli wrote:
>
> It's an archive, 100% static HTML including the wiki. As far as I know the
> site hasn't been touched since 2011, and the only TUNES activity (such as
> it is) is here.
>
> I have no interest in reviving TUNES. Better to start fresh, set
> achievable goals, and have a BDFL.

To get a project like this under way, when even the design is up in the air,
you need to make a useful, working component. It needs to be the kind of thing that
would fit into the desired final system (whatever it will turn out to be), but also be
useful in itself. Ideally, it should fit a gap in the application landscape, so that
it gets actual users -- users who use it because it's useful to them, not merely
because they want experience towards the Grand Project.

Well, maybe several such components.

Now in a grand design, there are probably slots that can -- provisionally -- be filled
by existing code, eventually to be replaced. For example, if we want a software
development environment, we may be able to start building it on top of an existing
operating system. Perhaps the umtimate aim is to build such an operating system, but
you have to start somewhere. You can't build a programming language that runs ono
the new operating system and an operating system that's coded in the new language
simultaneously.

What are the essential new components for a TUNES-like system?

Not the pie-in-the-sky ideal compnents for the ideal system, but the components which
we cannot do without. The components which we need to have in order to build the rest?
The tools we use to design the system, communicate about the design, build parts
of it, review them formally and informally, test them, try them out and discuss whether
we need to change or discard them, and so forth?

Are there any existing tools that could temporarioy fill these slots (whatever they
turn out to be?)

I'd say we need distributed revision control, text production, a programming language,
and editor, an implementation for said language, and communication tools.

And they all have to work well together.

What have I left out?

-- hendrik

[David Barbour]

On Sun, Dec 14, 2014 at 5:06 PM, Hendrik Boom <hen...@topoi.pooq.com> wrote:

What are the essential new components for a TUNES-like system?

I'd say we need distributed revision control, text production, a programming language,

and editor, an implementation for said language, and communication tools.

And they all have to work well together.

What have I left out?

I'd think you also need an interesting application, something that can help drive what you do with the language for a while. 

 

[Hendrik Boom]

On Sun, Dec 14, 2014 at 12:38:26PM -0800, Vaše jméno wrote:
> lemon is a projectional editor and hopefully one day also a language/shell
> inside it. You could say a desktop environment, or im curious to try using
> lemon as a basis of a user interface to some user-level functionality. The
> notes are centered around it but cover everything related, its hard to draw
> a line. There are links explaining the whys and hows of projectinal editors
> and other language topics, and an attempt to analyze similar projects.

Thanks. The page make a lot more sense with this paragraph. Perhaps
you should put it at the start of the page, perhaps with a heading like
"What this page is about."?

As for the shall I say informal style of the notes, they strongly
resemble the style os my own notes when a project is barely underway,
and nowhere near the alpha stage.

My experience is that paragraph at the top describibg what the page is
about needs frequent revision.

>
> More questions?:)
>
> i will surely announce it if lemon ever reaches alpha or something. Im in
> the middle of rewriting the frontend, and then i want to work on a more
> serious language and parser integration (marpa).

That, I suspect, is the stage at which a project is most likely to be
positively influenced by comments from others. Before
implementation has cast everything in stone, so to speak.

> If anyone thinks they can
> advise on building a visual language, or knows standard programming
> language theory but can think outside of the box, or maybe thinks that we
> could turn parts of the notes themselves into something generally useful,
> let me know

I should try to post something about my own current project, a
type-equality checker for a dependently typed language. It's really an
unsolvable problem, but it should be possible to do enough to be
useful.

At the moment it has no code at all, unless you count a program I wrote
decades ago in a no longer usable language, probably with files
missing. One which was far more complicated than it should be, because
I hadn't figured out what I was really doing.

-- hendrik

[Hendrik Boom]

Well, one interesting application is an improved version of any of the
above, driven by frustration with any initial set of tools we cobble together.
And by "cobbling" I mean picking something off the shelf and
strucggling with it.

I'm fed up with word processors that are hostile to distributed
revision control, for example.

Fixing this needs a new save format for the word processor,
or a merge program that unpacks and repacks word-processor file
formats.

And maybe a browser that can edit this stuff while talking to a wiki.

At the moment I'm using Asciidoc for nonliterary writing, because it's
designed to generate books as well as web pages, and it has multiple
implementations, and others are likely to be able to find the tools to
process asciidoc filess if they need to. Documentation is a bit
informal, though.

This after I've implemented my own ad-hoc system, which I'm still using
for older stuff.

Pretty well nothing handles moving really large blocks of text
from one place to another. Revision control tends to identify it as a
block of text deleted and another inserted.

-- hendrik

[David Barbour]

On Mon, Dec 15, 2014 at 4:55 PM, Hendrik Boom <hen...@topoi.pooq.com> wrote:

maybe a browser that can edit this stuff while talking to a wiki.

I'm developing a reprogrammable wiki-based IDE, with an eye towards it doubling as a software platform for large, live-programmed applications (e.g. multi-player RPGs, robotic control). Sort of a new, multi-user version of emacs.

[Faré]

On Sun, Dec 14, 2014 at 6:06 PM, Hendrik Boom <hen...@topoi.pooq.com> wrote:
> What are the essential new components for a TUNES-like system?
>
> Not the pie-in-the-sky ideal compnents for the ideal system, but the components which
> we cannot do without. The components which we need to have in order to build the rest?
> The tools we use to design the system, communicate about the design, build parts
> of it, review them formally and informally, test them, try them out and discuss whether
> we need to change or discard them, and so forth?
>
> Are there any existing tools that could temporarioy fill these slots (whatever they
> turn out to be?)
>
> I'd say we need distributed revision control, text production, a programming language,
> and editor, an implementation for said language, and communication tools.
>
> And they all have to work well together.
>
> What have I left out?
>

Sorry for jumping in late in this discussion.

I believe that the essence of TUNES is to be found in whatever you
couldn't retrofit into Linux after the fact — or else, we could "just"
implement it as a mere Linux application.

My understanding is that the essential feature is an interactive
environment with full reflective control: the ability to do coherent
whole-system changes without everything falling apart because there is
too much informal state, because applications depend on subtle
interaction between of loosely coupled component, because you can't
contain the arbitrary runaway side-effects of the programs you run.

With the progress of sandboxing and virtualization, it would now be
possible to run such a system as a supervisor of virtual machines
(that might itself be a virtual machine under Linux, until it's mature
enough to become the main supervisor). Applications would be
restricted by capabilities that the user can always virtualize (and
might be virtualized by default indeed): So this app wants to access
your contact list? No problem, except it's a virtual contact list —
unless you really want it to see the real thing, or a subset thereof.

Other things that can't be retrofitted without excruciating pain:
system-enforced strong-typing (where applicable), proper tail call,
delimited continuations, hard real-time guarantees, garbage
collection, PCLSRing, etc. — it's easy to opt out in a VM, or to build
your own for your own applications — but if your system at large
doesn't have one of these features, then components of the system
can't rely on other components following the necessary discipline.

David Barbour notes:

> I'd think you also need an interesting application, something that can help drive what you do with the language for a while.
>

That is true. But my imagination fails, and beside a toplevel
controller for other systems, I can't imagine any specific application
that needs TUNES. The magic is precisely in the total system control.
Maybe the "killer app" would be one where control really matters — a
"shell" that is hardened against all kinds of spyware, malware, etc.,
and suitable for use by people who use cryptocurrencies, and/or who
want to evade the prying eyes of the NSA.

As a kid, I once dreamed of a layered game where at each level you try
to escape to an outer system — or find the key to decoding an inner
system. The first level would be guessing a very weak password. Then a
series of Unix privilege escalations. Then escaping Unix altogether.
Then finding an inner environment hidden in a game. etc. I believe I
mentioned that before on the mailing-list, long ago. In the meantime,
you might enjoy this much simpler but actually existing and very fun
game: http://alexnisnevich.github.io/untrusted/

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Tomorrow will be different from today and from anything that existed in the
past. Tomorrow is a utopia. The only question is to determine which.

[martinobal]

Hi, guys.

I'm glad to see TUNES still alive (or back from the dead). Alas, I'm afraid all I can offer are my layman views as a user who dreams of a better computing experience, but here it goes, FWIMBW.

Some of the most frustrating aspects of modern "desktop" computing (that is, general-purpose, end-user computing platforms) are:

1)  A broken security model, both cumbersome and ineffective (static and flat permissions, no delegation).

2)  No system-wide real-time features.

3) Cumbersome backup schemes (no satisfactory distributed, redundant backup scheme).

4) Inobservability. Inability to see where each object or entity came from. A pervasive one-way feeling that programming and computing in general is more like cooking than like building with LEGO bricks. You throw the ingredients in, see what happens, try again.

5) Manual translation everywhere. Lots of slightly-different languages and platforms, incompatible with each other, which leads to the permanent reinvention of the wheel and the prevalence of broken systems simply because they are older and therefore bigger.

6) Centralization of social networks, and cumbersome management of sharing. Impedance mismatch between the private and the social sphere. Lack of a unified approach.

Some current systems to look at:

• Genode
  
• A real-time OS built around capabilities and convenient delegation. It also has nice observability features, for instance in the windowing system.
• Hyperboria
•  "A GLOBAL DECENTRALIZED ALTERNATIVE TO THE INTERNET."
• STEPS (by VPRI): Maybe the closest thing to the TUNES vision, IMHO. Enough said.
• Of particular interest:
• Worlds (a system-wide way to test ideas reversibly and then adopt the good results immediately)
• OMeta (related to automated programming language translation)
• Maru ("a symbolic expression evaluator that can compile its own implementation language.", a better LISP).
• Protege
• "A free, open-source ontology editor and framework for building intelligent systems"
• A convenient framework on which to build an "ontology of software" for automated translation between programming languages, platforms, paradigms and so on.
• Also, expressive, explicit knowledge encoding should be a pervasive feature of a good computing platform.
• Distributed filesystems
• Of particular interest:
  
• TAHOE-LAFS
• XTreemFS
• See XTreemOS
• Distributed data stores
• F2F networks
• For a better control of privacy while sharing information.
• Distributed social networks.
• Functional reactive programming
• Tangible functional programming

I'm leaving out a few more very interesting projects, some well-known, others not so much. For instance:

Plan9

Newspeak

Clojure

Klisp (a Kernel-PL implementation)

Please feel free to add others or to coment on these. I made the list as they came to mind, and I'm pretty sure there are important omissions and not-so-important inclusions, but I guess it's a start.

In short, IMHO, some buzzwords to look at are:

• Real-time
  
• Capabilities
  
• Distributed
  
• Semantic
  
• Virtual
• Consistent
  
• Recursively
• Social
• Explicit
• Functional
• Reactive
• Structured

Given the overwhelming variety of languages, platforms, paradigms and so on, I humbly think the main focus should be in translating between them rather than in picking the best one.

I like to think that good software ideas reincarnate in whatever platform happens to be fashionable, while bad ideas, no matter how dominant,  fossilize into the platform, and then into hardware, until they are eventually optimized away. In a sense, the maligned "inner platform effect" might be a blessing in disguise.

Best,

-Martin

[Vaše jméno]

im excited to see the messages from all of you. been reading thru the tunes website, and think its a good framework and i will try (no promises) to fill in more details on the HLL and UI parts

martinobal:
in case you missed my link, i have a similar list. At one point i tried distilling some items into this: https://github.com/koo5/BronzeAge/tree/master
If it catches your imagination, please let me know, and we can think about a more serious system for it.. Or, for a different approach, i think this fits into the materials of the Review subproject of tunes(?)

Fare: your OS stuff goes right past me at this point:)

dmbarbour: i'm interested in your wiki thingy, as that is an integral part of the dream UI.  So far i did two experiments at a frontend to such a thing: https://github.com/koo5/hackery/tree/master/hackery/hmmfish and trying to talk to shell from the lemon gui. Both showed serious weaknesses:) I know youve written on the topic before, so i will try to review that sometime (when it becomes an actual topic for lemon, if nobody wants to tackle it in a more general way)
As on your language thoughts, concatenativeness doesnt catch my fancy (although, why not...), but tacitness does (Implicitness in tunes lingo)

Hendrik Boom: thanks for the suggestion, i applied it and reorganized things once again. And i should give a try to Asciidoc sometime...although...i can *almost* imagine the HLL where writing my own processor would require less energy than reviewing and learning a bunch of other guys' tools, so, i will be cherishing that vision for a while...:)

Finally, i will try rephrasing my question: can anyone advise on designing the data structures of a reflective, dynamic language? Do you know of any resources? My best bet so far is digging into the source code of CITRUS, and ive been putting that off.

Dne středa, 17. prosince 2014 13:25:09 UTC+1 martinobal napsal(a):

[Tom Novelli]

On Wed, Dec 17, 2014 at 12:51 AM, Faré <fah...@gmail.com> wrote:

I believe that the essence of TUNES is to be found in whatever you
couldn't retrofit into Linux after the fact — or else, we could "just"
implement it as a mere Linux application.

My understanding is that the essential feature is an interactive
environment with full reflective control: the ability to do coherent
whole-system changes without everything falling apart because there is
too much informal state, because applications depend on subtle
interaction between of loosely coupled component, because you can't
contain the arbitrary runaway side-effects of the programs you run.

Well said.  Of course, a lot of "advanced" features from the old TUNES wish list (GC, version control, dynamic typing, reflection) are now widely used, even if there is room for improvement.  Web-dev these days is a playground of fugly implementations of TUNES ideas.  Some of those ideas are proving problematic in practice.  For example, large-scale code re-use is plagued with quality/manageability issues... I would say it's the #1 problem for both Linux and the WWW... and "solutions" ultimately lead to bigger piles of crappier code.

"State management" is important... but the concept is still vague in the minds of programmers.  OO gets it almost right, yet somehow very wrong.  Reflection sounds nice, at least in a whole-system interactive context, but it's gotten a bad reputation for undermining determinism.  Needs work. :)

I also think of TUNES as the obvious system architecture of the distant future, when innovation has ceased in hardware, platforms, language design, etc, and all legacy cruft has been eliminated.  Compatibility layers and plumbing account for ~99.99% of the code in a typical system today.  We're always trying to skip ahead in the awkward 1-step-forward-99-steps-back evolutionary process... but the world refuses to cooperate!  This is the stuff of small DIY projects and thought experiments, not communities and standards...

David Barbour notes:
> I'd think you also need an interesting application, something that can help drive what you do with the language for a while.
>
That is true. But my imagination fails, and beside a toplevel
controller for other systems, I can't imagine any specific application
that needs TUNES. The magic is precisely in the total system control.
Maybe the "killer app" would be one where control really matters — a
"shell" that is hardened against all kinds of spyware, malware, etc.,
and suitable for use by people who use cryptocurrencies, and/or who
want to evade the prying eyes of the NSA.

 

Indeed.  A minimal, dedicated/specialized, secure communication platform could be a killer app right now.  It would have to be built from scratch, hardware and software.  Could be very simple though, just text messaging.  Challenges: legal obstacles, DIY fabrication, decentralized architecture, usability.  First step: less-secure proof-of-concept software.

Server development/management seems like a killer app, but there isn't a good business case for radical changes.  It's mostly Unix/Linux, PHP, MySQL, and worse.  It's also wedded to the WWW... best to let that monstrosity die together with Unix, I say, even as I make my living from it.  I can't even imagine what will replace it; this is the consumer domain I'm talking about now.  There's no logic to it. ;)

Games too... always seemed like a good place to start, but only with a subset of TUNES features.  For all its flaws, C++ is the dominant language for game development.  There's strong demand for something better but modern languages don't fit.  We want realtime performance and (relatively) direct hardware control.  We can't take memory and data flow for granted.  GC is something we tend to fight with.  It works okay for the kind of games that run comfortably under HTML5/Javascript, but TUNES won't find an audience there.

.... In the meantime,

you might enjoy this much simpler but actually existing and very fun
game: http://alexnisnevich.github.io/untrusted/

Yeah, it is pretty fun, if a bit contrived ("you can only edit these 2 lines").  Exciting times for this genre of games involving realistic hacking and programming.

[Faré]

On Wed, Dec 17, 2014 at 2:27 PM, Tom Novelli <tnov...@gmail.com> wrote:
> On Wed, Dec 17, 2014 at 12:51 AM, Faré <fah...@gmail.com> wrote:
>>
>> I believe that the essence of TUNES is to be found in whatever you
>> couldn't retrofit into Linux after the fact — or else, we could "just"
>> implement it as a mere Linux application.
>>
>> My understanding is that the essential feature is an interactive
>> environment with full reflective control: the ability to do coherent
>> whole-system changes without everything falling apart because there is
>> too much informal state, because applications depend on subtle
>> interaction between of loosely coupled component, because you can't
>> contain the arbitrary runaway side-effects of the programs you run.
>
> Well said. Of course, a lot of "advanced" features from the old TUNES wish
> list (GC, version control, dynamic typing, reflection) are now widely used,
> even if there is room for improvement. Web-dev these days is a playground
> of fugly implementations of TUNES ideas. Some of those ideas are proving
> problematic in practice. For example, large-scale code re-use is plagued
> with quality/manageability issues... I would say it's the #1 problem for
> both Linux and the WWW... and "solutions" ultimately lead to bigger piles of
> crappier code.
>

Most of the individual features we were discussing have been
separately implemented or at least studied in the past two decades.
What is missing is a way to integrate them.

I would say that the pons asinorum that TUNES has to cross remains the same:
can you start from a development system and *add* GC, persistence,
distributed computation, etc., from within the system, in a
first-class extension
that doesn't require special privilege?

> Indeed. A minimal, dedicated/specialized, secure communication platform
> could be a killer app right now. It would have to be built from scratch,
> hardware and software. Could be very simple though, just text messaging.
> Challenges: legal obstacles, DIY fabrication, decentralized architecture,
> usability. First step: less-secure proof-of-concept software.
>

Custom hardware for security's sake would be a good thing to have in
the future, including "bootstrap kits" where everyone could program
their own FPGA-based board with a randomized CPU implementation that
encrypts/decrypts data in and out of the secure core — making it hard
for the board-maker to pre-seed his board with specialized hardware
interception tools to recognize and modify known variants of the code.

But we don't need that to bring value. Having a secure no-kernel
system, even on top of existing hardware, would still be an
improvement over less secure software systems. Hardware can come
later.

> Server development/management seems like a killer app, but there isn't a
> good business case for radical changes. It's mostly Unix/Linux, PHP, MySQL,
> and worse. It's also wedded to the WWW... best to let that monstrosity die
> together with Unix, I say, even as I make my living from it. I can't even
> imagine what will replace it; this is the consumer domain I'm talking about
> now. There's no logic to it. ;)
>

Crypto applications are the opportunity to move away from the WWW: Tor
is a failed model for anonymization, and asynchronous message-relaying
mix network is more promising, though the detriment of high latency
and diminished bandwidth. High latency and lower bandwidth mean that
there is a huge opportunity for non-WWW protocols. The same protocols
could also provide for a distributed alternative to facebook et al.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

There are two kinds of pacifists: those who try to disarm the criminals, and
those who try to disarm the victims.

[Faré]

On Sat, Dec 13, 2014 at 8:23 PM, Hendrik Boom <hen...@topoi.pooq.com> wrote:
> Is the TUNES website still in operation, or am I viewing an inert
> archive at tunes.org?
>

The server is still running. I don't think anyone has contributed in many years.

> Is it possible for me to sign up and become a participant, placing
> documents on the wiki and so forth?
>

As far as I can tell, the cliki is read-only right now. Do you want to
maintain it? Even the official cliki.net has moved to a newer code
base — though you might need to either port the tunes cliki extensions
or translate the contents.

Didn't someone migrate the Tunes cliki contents to mediawiki at some
point? It might not be up anymore, because a Google search can't
obviously find it :-/

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org

Passive hope is wishful thinking, a poison of the mind.
Active hope is creative passion, the mover of the universe.

[Miellaby]

Hello everyone.

I belong to this invisible mass of people who read the Tunes pages and digest them without contributing to anything. I really loved most of the concepts I learned this way and it really completed both my intuitive views about these topics, and the software engineering courses I attempted at the time.
 
TUNES covered a lot of stuff (too much?) and by browsing all the resources gathered, I eventually stumbled upon Brian T Rice's essay: The Arrow System Philosophy. The language barrier was hard for me -and still is- however this read triggered some ideas back in my mind. Fast forward to today. I'm actively working on a 15 years old project which is somehow related to Tunes' initial goals.

Entrelacs is my attempt on proposing a truly disruptive computing environment. Basically, it's an orthogonally persistent (as I learned in with Tunes) computing environment where the system behavioral function (read: everything, from programs to user data and every single machine state) is stored thanks to a single kind of building block: namely arrows. In my vocabulary, arrows are orthogonally persistent, fully-indexed, deduplicated, immutable pairs of arrows (aka. hashed-cons or 'hons').

So. A lambda expression is stored as an arrow. So are objects, arrows, closures, continuation chains, evaluation contexts, user files, applicative states. Everything ... is an arrow. While not stored as arrows, even binary objects (says, pictures) are still considered as equivalent to some intricate balls of arrows.

Strong points of this approach:  Information homoiconicity (yeah another Tunes concept), system-level reflexion, meta-programming, easy representation of a meta-hierarchies, and permanent data structures, fine-grained versioning, etc, etc. So a better foundation for most paradigms: object-oriented, functional, REST, semantic networks, you-name-it.

Entrelacs is supposed to be eventually an OS. But I'm working on a prototype in the form of a web service with a dedicated graphical terminal.

Feel free to break my demo there: http://entrelacs.googlecode.com/svn/trunk/web-terminal/index.html#pub and grab the source here: https://code.google.com/p/entrelacs/source/browse/ (code evaluation is not possible yet, only information storage); Additional readings there: https://code.google.com/p/entrelacs/wiki/ArrowParadigm

So well. From my point of view, Tunes was a successful story. What's the next step? I don't know. I propose we keep on sharing our thoughts and personal projects as we're doing so to keep motivation and find inspiration.

Merry Christmas in advance.

ps: sorry for my poor english. Writing in english is a real pain for me.

Le mardi 11 janvier 2011 00:15:35 UTC+1, Tom Novelli a écrit :

Greetings all,

It seems that despite efforts to revive it, the Tunes project has been

dormant for 5 years or so.  There are 17 people on this mailing list,

and most of us are working on something that's somehow related to

Tunes, but as a cohesive effort there's nothing happening.  I'm not
hopeful that that'll change, as explained in my 'post-mortem' essay
[1] on Tunes, written last year.  Bottom line, I think Tunes was
sidelined by the consumerization of computing, and maybe Tunes was too
ambitious anyhow.  I don't know how you all feel, but that's my
opinion.

What's next?  Do we update the website to say the project is inactive,
and just keep this mailing list around as a "computer visionaries'
club"?  Close the list too?  Or does someone want to keep Tunes going?

[d'Ars]

Greetings all,

After my last entry in notebook about "INtellectual adaptive interface for NETconnected ALFAdots strucctures tuneOS" I found this topic. I think that point began to connect.

вторник, 11 января 2011 г., 1:15:35 UTC+2 пользователь Tom Novelli написал: