AltME groups: search

Fossil serves distributed versioned databases and it only has 500 
KB resident right now

I love AltMe, but it has things that annoy me as well. Since we don't 
know exactly why it doesn't scale (yes, we can guess), I don't think 
just making the back end a DB is a guaranteed fix, or perhaps even 
that simple. And I don't think it will happen. I fear the R3 chat/rebdev/??? 
model will scale even worse than AltMe as I think the msg db is a 
single file and still a naive implementation designed for small-scale 
use.


Like Graham, I've thought that something like Git--a system designed 
for distributed, differenced, repositories of information--might 
be used. I haven't seen it done however.

What ar our options?

1) Live with AltMe, and roll worlds when they get too slow.
2) Find an alternative.
3) Implement our own.

Is #1 painful enough to drive us to #2 or #3?

no but I should not risk it untill I have my own backup,  I use it 
as a  sort of  distributed note pad

The name server was supposed to be distributed over the world, but 
once when it was down it turned out that it runs on one DSL line

(the previous version sources , examples and 2 more blog posts about 
actor-net can be found here http://itmmetelko.com/blog/2009/06/08/playing-with-making-an-actor-like-distributed-system-in-rebol-3/
)

I wrote a blogpost with code about the usage of actor-net lib that 
we chatted with Graham a little (few days back) http://itmmetelko.com/blog/2009/07/03/rebols-actor-net-used-for-real-distributed-system/

who said he was going to implement a distributed Erlang system in 
Rebol .... some time ago !

it is ok, that is how ti was distributed in the past - packed

there are also websites that offer free hosting (with issue tracking 
and other typical stuff ) of OS projects for distributed vcs-s Bazaar, 
Mecurial and Git ... I stopped using svn and went to bazaar and I 
like it  ... there is comparison of various such sites here http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities

On the interest in Orca. As I mentioned before, Orca is included 
in Syllable 0.6.1. In that form, many thousands of copies have been 
distributed already all over the world. We're currently up to about 
4500 downloads of the install CD, so those would presumably be people 
really running the system, 2300 live CDs and an unknown number of 
VMware images, which have been very popular in the past. It's also 
in the shops on the DVD version of Linux Format magazine. I don't 
know how big the DVD part of its circulation is, but it must be many 
thousands

Yesterday I came up with a way to change the DevBase model so that 
it would keep (and enhance) the workflow management functions and 
still get most of the benefits of a distributed vcs. Yes, it would 
depend on making the DevBase client a reblet run by the browser above, 
but that would be a bonus for R3 anyways.

I sure hope all these mezzanines don't get distributed with REBOL. 
 Because even if they are still distributed as a package with the 
main bin then it is still bloat.

R3 will be less bloated than R2, but you are still missing something: 
you say "the main bin" which assumes that R3 will be distributed 
in a single monolithic binary like it is in R2. Not doing that is 
the reason for the split of the host code. Build your own monolith 
if you like, including whatever functions you need.

what OSGi is or is becoming is a similar environment as IOS, if I 
recall some of the details. With distributed OSGi, the services that 
make up an application can be located anywhere

as said before, rebol with erlang like concurrency is a 
dooropener for many professional projects. btw mnesia,
the distributed hybrid database is very nice too.

I think, that the "main problem" may be, that the uniform deviates 
are only rarely what is needed, quite often it is necessary to transform 
them to normal, lognormal, exponential, or otherwise differently 
distributed deviates

no, the hits are expected to be uniformly distributed, i.e. the same 
number of hits for 0.0 as for any interior point is expected

aha, yes, the numbers aren't uniformly distributed; well, can you 
test it?

OK, so let's forget the higher level models right now - there can 
be many over time :-) But multiplexing is one aproach, whereas combining 
it with concurrency is the other thing. So far Cheyenne spawns processes. 
We want R3 to be distributed computing king, no? :-)

i got that {icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR>^M

icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.8<BR>^M
icy-name:OUIFM^M
icy-genre:Rock^M
icy-url:http://www.ouifm.fr^M
content-type:audio/mpeg^M
icy-pub:1^M
icy-br:128}
>>

I suppose having non-blocking async http and ssl, coupled with timers 
could make for a nice distributed system via ws:// . Could have clusters 
of Cheyenne :)

Does anyone know how the 2.7 SDK is distributed to previous SDK owners?

Giuseppe, in the context of REBOL as a messaging/data language, can 
you picture how it might work as a class-based model? And do you 
think a class-based model is more appropriate in distributed environments?

you can simply do a block to struct conversion within the C layer.


the extensions docs show how to read and create new blocks, with 
working examples... you just need to continue from there on.


googling how to connect to a dll in real time will give you examples 
in C, but many dll's which are distributed as tools also come with 
their equivalent static .lib files so you might not need to do a 
run-time link to the dll.  OpenGL, for example came with both.

See distributed IPC http://www.linuxjournal.com/article/2417

So, there is the possibility then of two ipc mechanisms .. one for 
local ipc, and for one distributed ipc ...

Once your libraries are distributed (and installed), you already 
have the proper library suiting your specific platform.

Carl seems to have some specific stuff in mind for vid direction 
but he is just not going to get to it anytime soon...I do not see 
a prob with you guys coming up with an alternate vid (rebgui for 
r3) in the mean time...each gui may be addressing different needs 
anyway. Carl's VID, when ready, can become the defacto and distributed 
with R3 but in the mean time we can use the alternate to push R use 
forward.

Yes, we are on the same page. I see this as built upon a messaging 
infrastructure. It doesn't need to be elaborate today, in what it 
supports, but the design should allow us to extend and build on it. 
i.e. we need a message bus that we can tap into, inside an app, interprocess, 
and distributed.

it seems to be a broken exe. a new one should be distributed.

that's not certain yet as he has not made any evaluation yet, but 
it will be a publicly distributed GUI, so you can at least get to 
use it.

github is popular for source code but not for distributable modules. 
Many Ruby/Gems source code can be found on github but they are still 
distributed via GEMS.

because people would expect to have things like ftp, smtp, pop3 in 
the distributed exe

Adrian, that's what RSS feeds were supposed to be for, though. I'm 
not sure how much of a good idea it is to replace distributed technologies 
with centralized ones, but it looks like humans go for popular ideas, 
not good ones.

A "concise summary" may be a bit problematic, as distributed version 
control really is a bit of a paradigm shift compared to CVS or SVN.

distributed source controls are much more flexible and easy to use 
than centralized ones like svn.

Ok. So much for distributed automated build, test, release.

Well, latest AGG version (2.5) is distributed under GPL, development 
has stopped in 2006, it doesn't support hardware acceleration AFAIK, 
so it's a no-go. Cairo seems like a more modern graphic vector engine. 
Anyway, it is open to any contributor, as I don't plan to work personally 
on a View-like engine for Red.

BTW, Red will probably be distributed both as a standalone exe and 
as a dynamic library. So if people wants or needs to deeply rely 
on C libs, they could embed Red in a C project easily.

Tamas sent me a link today about a nice little SSL/TLS library (http://polarssl.org). 
The bad thing is that it's GPL, but the license extends to FOSS License 
Exception: http://polarssl.org/license_exception


As I understand it, it would be possible to use it for Red but every 
future Red binary publicly distributed would have to come with also 
the PolarSSL source code and a copy of the GPL library. I think that 
burden would be too high for future Red corporate users. What do 
you think?

The Boost Software License is even more permissive in this regard, 
and should therefore make sure that Red/System-produced binaries 
can be distributed without any restriction.