Evolution of AOS...

I have been reading up on Rebol lately and it sounds like Rebol could be positioning to do what Amiga, inc is trying to accomplish with Amiga Anywhere. The scope of Rebol is still expanding. Rebol is small and efficient which is very Amiga. And with the direction Rebol is headed why not just make it the new Amiga OS. It looks to me that Rebel has a lot to offer. The question is, does Amiga have anything to offer Rebol?

Does this idea fall flat on it's face or does anyone else think this is a good idea?

@goody

The reason it looks so "Amiga" is that the original AmigaOS was designed in part by the guy that designed Rebol.

I don't know that he'd be interested in walking that long-ago-road again.

@Billsey

Quote:

Carl had a problem with Amiga management, not amiga the computer. Make no mistakes, Amiga OS is Carls baby.

Given the correct situation I think Carl would jump at a chance to see Amiga go down the correct path.

I have read many cases where programmers have spoken of problems that AOS does have. Even reading what Carl has to say leads me to believe there were lots of compromises made in the creation of Amiga OS. If Carl could be free to create his OS without compromise he would love it. And we would all benefit.

But it all has to start somewhere. Why not Amiga.

With the changes in computing today I don't see AOS as the future. It might be fun and we all have good memories of it but Rebol seems to be a better path for the future than what AOS will provide. AOS was built for a desktop computer many years ago. It has taken Hyperion years to get it to where it is and it has a long ways to go yet. Rebol might be a good break in the chain and be the next evolution that is needed for todays computing. Carl is building an OS for today.

@ssolie

Quote:
Ah yes, you were there. LOL

Quote:
Amiga is just not a big enough market. And REBOL already has a passionate user base. I don't know about the developer part.

Quote:
I would expect you to have a better idea behind REBOL than I. REBOL is going self hosting. Python and similar is nothing compared to what REBOL is going to become. imnsho

Quote:

And the networking/data sharing/ etc...

The future.

@goody

Quote:

Last time I checked, the guy that gave Amiga end users decipherable networking (Holger Kruse, Miami Deluxe), was also working for Rebol and Carl, although that has been some years now.

@goody
when I first read this, I had not been on the REBOL site for some time. Just in the last few days I have been back and have read more carefully and I think you are on the right path with this, and it is very exciting.

Very important to look up the Wildman Project to quote:

"is a "secret project" that examines the question: what is the minimal environment for running REBOL? Can REBOL operate natively on specific hardware, and if it did, what components would be necessary to be successful? This project will begin early spring. Complete development will depend on our results and possibilities for potential funding."

AmigaINc apparent break with TAO had me very worried as I have had a long interest in VP technology. That Bill announced a way of getting cross platform abilities without TAO intent, made me think they were going for static compiles.

On the other hand, a stripped down AmigaOS compiled for different HW platforms, add in REBOL, a few statically compiled plugins and we really do have something looking like OS5 and a lot more beside.

It would not be AMIGA as we know it, it would be better.

AMIGADOS as a REBOL script, might be possible (REBOL calls written in the compile). The rest of AMIGADOS stripped right back to the bare essentials - and REBOL creating an application environment - this has many exciting aspects including the networking of IOS.

PLUS, if this is pulled off, the effect would be revolutionary., in terms of application size, execution and constancy across platforms. The trend to bloat would be hit hard with truly tiny efficient code that packs plenty of punch.

PS it appears AMIGA Inc has been in contact with Carl (fingers crossed - this could be exciting).

@GregS

Re: Post #8

Is this merely a speculation, or do you have a reliable source? If so, how much can you say in public?

@goody
The problem with REBOL being an OS, is that REBOL programs are still interpreted, rather than (JIT) compiled. This means that computation heavy programs are not really feasible (e.g. decompressing a music stream (such as MP3 or OGG) on the fly).

Carl has a partial solution with REBOL v3, by way of a portable assembler, but your not going to want to use that for more than tiny sections of code that get used heavily.

I assume the main reason for avoiding JIT (so far) is that it is simply a hell of a lot of work for one single CPU, and REBOL is all about being portable. So maybe it'll happen eventually, if REBOL become popular enough to justify it. Or perhaps Carl should just port REBOL to the Java VM, and let it do the hard JIT work

I have done some emails to Carl and Bill some time ago about this.

It would not surprice me if there would be some REBOL parts in the future.

DE + OS4 + REBOL, perhaps ?

@Billsey

No source, I was seeing references to Bill having been talking to Carl re the recent court case documents.

It was co-incidence that I was also looking intensely at REBOL's site at the time, trying to work out how cross-platform it could become without having a real OS that was also recompiled.

REBOL could be looking at a very cut down LINUX (I have been looking in that area as well, but a very cut down LINUX still seems a megabyte eater.

So while REBOL could be looking at a separate solution the fit with AMIGAOS seems very close to the 2007 project of REBOL 3.0, and REBOL 3.0 seems to be taking on a mix of technologies that would suit OS5.

That is it I am afraid. No inside knowledge but a good fit. Then reading this thread again, the fit seems re-enforced by the thoughts of others.

Plus there was that mysterious phrase by Bill, that AI would support crossplatform by some mysterious means that was not INTENT or TAO related (I have been a great fan of the TAO VP approach, so this had me confused for a long time - how the hell could they do it).

The last bit comes from my experience working with a company using scripts to produce applications - combined with shared generalised compiled code, the size of individual applications can be made very small (this is counter intuitive - but believe me shrinkage is a big factor when so much compiled code is reproduced needlessly in every application - generalize this often used code, tends to make it smaller and more robust).

REBOLs plugin's seem to be following the same path.

That is small generalised compiled code (hence much more easily portable).

Which brings me back to OS5. Either it is done entirely through VP code, or it becomes a hybrid - the smallest underlying OS that can be ported, a small core scripting engine that can be easily ported, a collection of small generalised plugin's that can be easily ported - and apps then become mostly scripts that run exactly the same everywhere they are run.

There is no other workable solution, there is no way that traditionally compiled programs (ie stem to stern compiles) can be made easily portable - the overhead's, even with a good SDK for "transportable" C and C++ will cause even greater app bloat.

Getting something like OS5 actually moving means breaking the isolated app approach. An OS5 would require apps that are inherently as light as possible, and this means maximising shared generalised compiled code fragments (ie REBOL plugins).

I suspect that the VP TAO system may have made portablity a trivial thing, but at the expense of application bloat.

Bloating, aside from portability, is a fundamental problem with with the direction of present computer industry (not helped in the least by C++).

There are many merits in the REBOL system, one of which is the levels of abstraction possible. A good OS like AOS4, stripped absolutely bare, presents a great level of HW abstraction. REBOL supplies a great potential level of Application abstraction.

Do that right and actual port problems, while not disappearing, are dramatically reduced.

Also it makes sense of Amiga India's specialisation. And perhaps why Amiga Inc is getting so active in getting hold of the AOS4 code at this time and seems to have developed, at least, a neutral or even a good relationship with those that actually coded for AOS4. REBOLS IOS concept also seems ideal for OS5 (plus it is up and running!).

When AI was looking at TAO, AOS4 would have been seen as a sideline. Change the viewpoint and AOS4 becomes a great asset.

Basically there is just guessing involved, but when things fit so well, and the players have been talking to one another, it just looks too good to be ignored. The fact is that all the things that attracted me back to the Amiga scene could be in the making.

@ChrisH

Neither JIT nor JAVA are a good solution, the former because of the reasons you outlined, and JAVA is just too unreliably and demanding for serious apps running on small and diverse HW.

OS4 stripped down to the bare bones, gives a real platform rather than a VM, and that means a robust base once it is ported. The REBOL base, plus whatever compiled plugins make another small headache (relatively speaking) port.

The exciting thing, is that if this is put together in this way, and the plugins are well designed and generalised, the number of small apps that can be produced quickly could be huge, and space occupied by them trivial (unlike anything done in JAVA).

The only other thing I would suggest, if this is anywhere near the truth of what is being planned, and if anyone involved is reading this, is the FILE SYSTEM.

Get rid of filenames + Location, and use IDs, and World-wide Unique IDs (WUIDs - I have a system up and running, plus a useful directory system).

A File System that uses Titles for people, like header data from REBOL scripts, but uses WUIDs for file identification, surrendering REBOL blocks for file selection and reference would be a very good step to take (plus class information of course).

An XML wrapper (that converts to REBOL blocks) and can contain binary with one simple extension of XML, would make an ideal filesystem file container (like IFF) for all files on the system.

But whatever happens let it happen quickly.

@GregS

Quote:

Please expound?and explain how it is going to be easier for a person to remember what seems like a long string of numbers that they likely didn?t even choose rather than an actual name that they did choose.

@Billsey

WUIDs are not for humans, but for absolute identity of files where-ever they may be found.

The bit that humans have to remember is the title and what it is associated with.

@GregS
Quote:
FYI - Mr. Sassenrath phoned McEwen during AmiWest last year when we were curious why Amiga Inc. had not shown up. It is highly likely Carl is keeping tabs on things just in case he sees some opportunities. Nothing to be excited about really--just business as usual.

@ssolie

Back to the tea leafs for me.

REBOL does have the potential for an OS5 type solution.

TAO was also a good approach.

A mix of the two would also work.

Using a severely cut down version of OS4, ported, is an ideal low overhead platform.

I do think this last one is within the ambit of AI plans for OS5 (or whatever it ends up being called).

Static ports of an OS and then all and every program written for the OS, is a possibility, but not one without inherent problems. If it is distributed, that is user compiled apps, it could be done, but not without encryption protection of the app code. Centralised porting could produce bottlenecks as well as a distribution nightmare.

Are there other alternatives, for cross platform performance?

The REBOL approach I like for a number of reasons besides portability. Scripting can really reduce bloat to a major degree, it also lends itself to adaption, application evolution, task oriented program use, more user control of application behaviour and better generalised compiled plugin/engines that can be more easily and quickly be ported.

The waiting is getting on my nerves, especially this court case which can only really end in one way, besides which given PS3 and the VISTA disaster this is the year to really move. Anyone got a time machine? I would love to jump ahead a few months.

@GregS
If you want a time machine, try asking SpaceDruid! But I'm not sure if he's registered here?

P.S. My personal preference is not JIT or your solution, but a more higher-level kind of JIT that some have called "dynamic compilation". But while we are stuck with awful languages like C/C++, there's precious little chance of that. Scripting languages are the only alternative (to C/C++) that get's taken seriously, and nobody there seems to care about their awful (interpreted) performance. (Well, except for OCAML, which is apparently faster than C/C++, but it's a functional language, and no-one takes them seriously either.)

@ChrisH

As this is a general thread on AOS and its evolution, could you say a little bit more about "dynamic compilation"?

I presume it means that a generalised assembler like language, TAO's VP, is compiled to the particular processor on the fly, but that it is compiled for a particular configuration?

For a number of reasons I see scripting taking a central place. However, specifically compiled generalised code is a necessity (whether statically or dynamically - TAOs efforts have convinced me that the loss of speed in doing this is real, but practically negligible).

I would break things down into a number of connected but essentially independent aspects.

1) Hardware agnosticism, whether dealt with by "easy" porting or dynamic compilations. This translates into forms of software permanency as well as widespread application.

2) Software bloat, not just in terms of size, but overburdened functionality, needless code duplication, an intractable barrier for efficient usage.

3) Off the shelf do everything applications (related to point two), which effectively means adapting work to fit the the program, rather than evolve the apps to fit the needs of real world tasks.

4) Making the user into a mere appendage to software design (the cultural aspect of point two and three), the user needs the tools to dissemble and reassemble software components to fit tasks.

Obviously this last point will take time to evolve, but it begins by separating out the elements common to all software - the processing engine, from the form of presentation (GUI), the flow of data from pre-designed engines. Data handling and general flow control needs to be something that the experienced user can adapt and change.

I am against using scripting as a cure-all, it is not. Rather I want it to be the glue between high performance engines that can be harnessed together practically. There, if things are done properly, the processing overheads of the interpreted language, the simple flow control involved, is no deficit to speed at all - ideally, despite the interpretation, the processing is done within the manual mouse click (it is slower than compiled code but placed where this does not matter).

The design trick is in making truly generalised compiled processing "engines", cut down to their most efficient form.

A scripting language that is easy to learn (and remember) flexible, syntactically consistent (no specials), unbloated: Like LAU or REBOL, but not like Python, which has become overburdened by special extensions.

The last two bits:

5) A minimalist OS, to run all this.

6) A file system which "tames" and organises all the multitude of "bits and pieces" being shared.

@Dirk-B

Quote:

I?m not a fan of replacing Arexx but it seems that soon or later it will be replaced.wouldn?t be cool that Rebol replace Arexx?

@GregS

Quote:
Greg, thank you. You have answered my question, "What does amiga have to offer Rebol?"
This could be it. This could be how Carl is thinking of self hosting Rebol.

@ssolie
I think you were trying to say as much but I needed more info. You just did not hold my hand like greg did.

Quote:
I wonder how much to fan this fire...
When I was at Amiwest 2006 last October Carl made an appearance. I thought it was odd that he showed up at this particular time claiming he was looking for new Amiga hardware. (I had been at the previous 3 or 4 Amiwest shows without seeing Carl)
Now don't get me wrong. I am not claiming Carl was fibbing in any way. I just thought there was more to the story and wanted so much to ask questions. But I refrained out of respect.