»

[Einstein]

Crumb wrote:
@Einstein

AROS m68k should have it.

Does it even exist ?

...or when it does (AROS m68k) :-)

..or when it does (IEUAE/AROS 68k) ;-)

Imagine that I drag an Icon from the host OS desktop to an opus5 window... will it copy the file? I doubt it :-)

Good question, I'm not exactly fluent in workbench.library (or many other system libraries for that matter) but is there any obstacle ? any problems routing (and converting) between "objects" of the host and emulated desktop systems ? there shouldn't be, unless some endian-ness gets in the way.

BTW, have you actually tried OS4/MOS at all? Have you tried "GLUAE"? It's more or less the same kind of launcher the bounty wants to achieve but without the layers patch to show windows with other background.

That's just it, isn't it ?

BTW, a patch exist for EUAE to show the windows on top of Linux ones. Unfortunately it's not very advanced and shows all the windows in the same "layer" so host OS windows can't be between emulated WB windows.

I know, I pointed that out in the news announcement of the assigned bounty ;-)

Now let's suppose EUAE integration gets finished and you decide to use something called AROS2. First of all... why not use a Linux kernel or any other kernel like NewOS? Then you get posix compatibility. But automatically all AROS/AmigaOS devices/libraries become incompatible. Who cares anyway since Linux&GNU already has all the drivers we could want, these are actively developed and it also has tons of interesting libraries?

It would be more motivating for some reason (pride ?) having an "own" kernel, but I won't complain if the dev(s) would adopt a premade one.
As for the rest, actually i don't have some mysterious affection for everything AmigaOS, my ideal OS would be something new, inspired by the simplicity and (the once unique) modularity of AmigaOS, but really revised, I' like a new API that's crafted based on high flexibility and simplicity, that is, the API would not dictate certain things it really should not do, not in 2008+, I already explained what type of filesystem layer I would like to have in robs blog, that was just an example.

You could modify it to get a directory structure similar to AmigaOS, to boot reading an Startup-sequence file, to store commands on /c instead of /bin you could add amiga style path support, you could add a WB like desktop that avoids using XWindows (or maybe not, maybe you want to run all the GUI on top of XWindows).

I know that.

Since we agree amiga apps are old and modern linux apps are more useful and interesting there's no sense in keeping graphics.library. We could switch to Cairo for every graphic operation (switching to Cairo would make sense even on current AROS... intuition/graphics could run on top of it). AHI is also outdated, we could use OpenAL instead of it.
See... amiga stuff and API is outdated... there's little you would reuse on a modern OS.

But that's not up to me :-), besides I already stated *my* perception of amiga-like-ness, so I have no problems adapting to better API, but if some of it could be unique, designed from scratch then why not ?

If I started an amiga inspired OS (note I say amiga inspired and not amiga-like) I would choose a kernel like linux or NewOS and try to adapt existing software to run in a similar way as AmigaOS.

If I did start an OS (hehe), I would not put together premade kernel and modules, but write from scratch, implement new ideas not seen before, I would do that for fun, and to point out to the OS world: look at the power and flexibility of this baby of mine, and I did it all alone! now wouldn't that make the OS more attracting and appealing then just putting premade components together ? But as I said, I personally won't object.

Changing the kernel to keep a directory structure similar to AmigaOS wouldn't be difficult.

My personal perception of amiga "inspired" is not to clone things i regard "amiga like", but to take inspiration by the positive aspects, but most importantly to evolve it to a level that would make a regular user just adore it.

The problem reusing current AROS stuff is that it wouldn't have an easy way to communicate with the new OS. There's no much difference between standard OS libraries/components/devices and third party ones (the exception may be exec/dos/graphics/intuition/layes). That would cause that current AROS sources would be hard to adapt.

Remains to be seen what comes out of it.

When I say Amiga-like I mean OSes that work the same way as AmigaOS. Just like when I say Unix-like I expect the OS to include a set of posix functions, to have similar commands and I expect to code all unix-like OSes in more or less the same way. I'm not refering just to the end-user view.

I understand that, we have different views obviously.

What I'm trying to say is that if you get rid of the amiga/aros API why call your fork amiga or aros? Or why show it as successor of amiga/aros if it's not related to it (just using a similar GUI in the first versions?). GEM and MacOS looked and were used in a similar way but they were not related.

I explained that with the blind cousin analogy above. Anyway, since rob called the possible project "not-AROS" I think that answers your question.

IMHO Rob should fork. But there's little stuff that can be reused. I gave him some suggestion: design a new API and provide a library to be used on new Aros programs written for current AROS. Advice coders to stop using amigaos functions and provide them your functions. It's similar as if we were leaving amigaos and jumping to unix, you would advice coders to start using GeekGadgets. Just like that, he would define functions to do message-passing and other amiga-API stuff and AROS coders could start to migrate their code. Once most of apps and maybe libraries were adapted he would at least have something from AROS to use. Anyway since most of AROS stuff is based on old stuff and old APIs you could perfectly start from scratch changing the intuition/graphics calls by Cairo calls and stuff like that.

Not much to disagree with, only that it would be much (much) nicer with a unique overall design and API.

In conclusion: Fork AROS? Of course, but since everyone agrees that AmigaOS3.1 API is old and outdated why base your new OS on that?

If you've sent him a message I'm sure he got it ;-)

For me AROS/OS4/OS3/MOS are "amiga" :-) I may like some solutions more than the others but I like them all.

I was referring to the infamous *zealots* that rather throw themself to the trashcan than thinking with the substans between the ears, it's supposed to be used for somthing beyond eating/s????ing/sleeping and mating.

Intelligent programmers that want to write an OS without the limitations of OS3.1 won't base his code on OS3.1 compatible code.

Copying the source tree for reuse/modification/guidance of API implementaion algorithms is not necessarily *basing* in my book.

Users don't care about internals and that's the reason they shouldn't discuss internals of OSes.

Hence no reason to regard a new OS as *no* "amiga" or whatever, as long as it *feels* like it, and runs apps in an emulation layer with a few resources integrated in the host system.

You are right. Other things may look similar or use a similar GUI, but wouldn't be amiga-like. Just like running Amiga-E and a Zune clone on Linux won't make your linux box amiga-like, even if you have put a nice wb-like and even if you rename your /bin as /c and even if you create aliases so you can type "dir" instead of "ls". That's merely cosmetical.

That's *your* perception of amiga-like, mine is a different one, there's no monopoly for the generic word "like" I' afraid, if you don't like it maybe you should seek a better and more descriptive word.

Detailed suggestion:
-take linux/bsd/newos kernel and modify it if you need it
-use as much standard stuff as you can and avoid using OS3.1 code (that means avoid using AROS code)

I asked you to post *detailed* information to *him* that may fork or not fork (=leave)

-change the OS to use a similar structure to amigaos

Anyway, what structure ?

-put EUAE and add a launcher for ADF files (most of people who don't care about OS4/MOS-like emulation integration only remembers playing games on A500 in their childhood and haven't touched an amiga for years so they won't miss any program)

for the 666 time, EUAE does n-o-t, *not*, *NOT*, integrate essential "emulated" resources (windows, screens, some device messages) into the host system, are you and itix still going to claim that an upcoming *integrating*/whatever EUAE is *no different* to standard #?UAE ?

[Piru]

Where is this "integrated EUAE" then?

It's trivial to make UAE launch a game or even binary file when you doubleclick it. It is far from trivial to integrate it to the host system.

I'm afraid it won't be as seamless as some of you might hope.

IMO it's quite silly to use something that doesn't even exist yet as debate point.

[AeroMan]

What I really liked in AmigaOS is:

-It is small. It does not make sense with today´s machines, but compare Windows Vista and Windows98 running on a modern PC, and Win98 will perform better, because it is lighter. We don´t need a mammoth

-It is simple. There are no hidden and difficult to find and edit configuration files like Win and Linux.

-It boots fast. My 14MHz A1200 takes around 15 seconds to boot, My Win98 Takes around 40 seconds and my XP PC at work takes and awesome 6 minutes! I fell like loading ZX Spectrum software from tape, and see no excuses to take that long in "modern" OS's I´ve never measured my Ubuntu, but it´s not that fast also.

-You can do most of the stuff from WB. Rarely I had to go to CLI for ordinary stuff, unlike Linux. It is time to leave the command typing on the past, and use it only for development

-Software installation is simple. I´m against installers, the best isntallation for me is a directory copy. The Amiga Installer is really simple also.

-Multitasking works, unlike Windows. Yes, it could be VERY improved (memory protection and all that stuff everybody knows...), but it seems to work way better than Win (no better than Linux)

-Screens! With the drag down feature! That was really useful. Even AROS still doesn´t support it

-Big bitmap screens. Quite useful rather than multiple desktops like MacOS and some *nix. Just move the mouse and you find more space...

-Big Icons. They look cool

-Datatypes

-Easy directory structure. C, S, Devs, etc... Everything in a simple to find place

-Autoconfig. But PCI is good enough for me, and I know that this relies on hardware

-Memory gauge at WB´s bar. A free hard drive space one would be useful also

Now, if AROS have these features, I will be really happy, be it 3.1 compatible or not.
Probably all the fanatics will start shooting me with Linux this, Windows that, Mac this. This is my personal opinion, and is what I expect from "modern" OSs and can´t have at all, but had at the outdated 3.1

[Einstein]

Piru wrote:
Where is this "integrated EUAE" then?

This is the wrong place to ask the bounty assignee.
It might be taking a nap however.

It's trivial to make UAE launch a game or even binary file when you doubleclick it. It is far from trivial to integrate it to the host system.

Know that already, thanks for the info however.

I'm afraid it won't be as seamless as some of you might hope.

Read the thread, and ask about "seamless" later, or rather, don't.

IMO it's quite silly to use something that doesn't even exist yet as debate point.

It's a free world, well, not really :-( but it's a free forum..i hope.

[uncharted]

bloodline wrote:

The AROS source code is there... if anyone wanted to they could take it and get it compling on 68K... Bernd is the only one who has so far with his AFA... that sorce code is not going anywhere, It just takes someone with the motivation to do it...

It's exactly this kind of "meh" attitude that makes me want to get the AROS team and the AROS fanboys a collective slap. Open source is not an excuse to be disorganised and directionless.

I wouldn't care if AROS was a "just for fun" project, but it's always being banded about as the saviour of the platform, the only future. You can't have it both ways. You can't declare that you are going to solve everyone's problems one minute, and then pussy out the next because it's a volunteer project.

The 68k issue is a painfully obvious case where no-one thought before they declared that there was no issue. Every time binary compatibility is mentioned, this holy grail of an integrated EUAE is always put forward as the no-brainer solution, and yet no-one seems to have really thought about how it is going to work in practice. No-one appears to realised how stupid it is to have AROS, the supposedly completely Amiga-IP-free OS, reliant on Amiga Inc's IP for core functionality (and being able to run Amiga software IS core functionality).

Good open source software has good leadership. Good open source projects don't turn around to users and say "you do better", they do better themselves.

[Trev]

I think deep down Rob isn't looking for ways to improve AROS or the AROS project--he's looking for ways to improve the AROS community. It's plain from his blog that he enjoys the camaraderie and collaboration found in most Linux projects. Frankly, there just aren't enough interested developers in the Amiga community, AROS or otherwise, to make a difference in that regard.

When Amiga developers do come together in large groups, they're just as likely to kill each other as they are to help. It's a sad, sad, world we play in. There are exceptions, of course, but bad experiences amongst Amiga programmers are not uncommon.

Trev

[AeroMan]

Isn´t it time to set up a forum to discuss a spec for what we want to do ?

Let me explain: most of us are waiting for AROS to be ready, and expect it to fulfill our personal wishes. It would be nice to have a common target document to state what the community expects from AROS and which tasks must be done. And then we can try to help catching those tasks.

Other threads discusses about accelerators, Minimig implementations and other possible hardware substitutes. Shouldn´t we be discussing if this is worthy and if it is, which features it should have?
Do we need to run OS4/Morphos at all? Do we really need to have OS3.1 binary compatibility?

I agree with you that sometimes it seems we are more likely to kill each other than analyze and define which way to go.

Lots of people here have nice skills, either programming or hardware ones, and there are some personal ongoing projects in the forum. Maybe we need to join our efforts in a common direction rather than shooting randomly

[Trev]

I would coordinate your efforts with the current project leaders. Some of them are very clear on how project management, software requirements, and design specifications work.

If everyone is interested in keeping the spirit of the Amiga alive in AROS, I think the project should be asking, "What would Amiga have done if it was still run by the original hardware and software engineers?" (You can start by looking at Rebol as an example, of course, but I'd stay away from anything to do with set-top-boxes.) The hardware question is moot, and many of the software features that the Amiga and other systems of that time pioneered are quite dated. For example, context menus? Surely there's a better way to organize a program's available commands. AROS needs someone keen on advancements in interface design.