Amiga.org
Operating System Specific Discussions => AROS Research Operating System => Topic started by: graincloud on February 05, 2008, 11:45:09 PM
-
hi everybody, i just registered-
i'm just a very-ex-amiga user (i quit in 96) who never gave up browsing amiga sites, and in the last half year, with all the amiga legal issues going on and aros making big news i started checking amiga related stuff daily, in the last weeks mainly aros stuff..
so i was wondering why there is no discussion going on on this forum sbout the recent posts on rob norris blog--
http://cataclysm.cx/2008/02/01/i-dont-want-your-money-i-just-want-your-love/
this might be some important moment in aros history, and might be very interesting for all amiga folk out there who want a new os but have no possibility in running os4 or morphos.
i think aros deserves some attention, at least it caught mine, and made me sign up here, even though i read this site nearly every day i never did that before. it would just be great to have some opportunity to play with some amiga-like os again. i am happy with using my mac for getting all my work done, but i never forgot my amiga, which was my first machine. it had some strange mystical kind of energy field around it that i never encountered again since... i miss that.
cheers
-
I guess AROS guys don't like to hang their dirty laundry in public :-)
No, seriously it's a good question... Rob has raised some really good points... mostly that AROS has no clear direction.. now is a good time to decide what we want from AROS... the floor is open...
-
bloodline wrote:
I guess AROS guys don't like to hang their dirty laundry in public :-)
No, seriously it's a good question... Rob has raised some really good points... mostly that AROS has no clear direction.. now is a good time to decide what we want from AROS... the floor is open...
hmm i didn't think of that... but understandable- the community should sort things out internally maybe.
anyway i think it is not a good idea to further split up an already fragmented community - but i think rob is absolutely right. i am not a programmer (coming from electronic music and installation art, thus not really able to really contribute) but i'd really like to see this project grow. and grow on the basis of competitive technology.
good luck to the aros developers!
-
And here it is, does AROS replicate a seriously out of date operating system to make the retro crowd happy or does AROS take the Amiga legacy into the 21st Century at the cost of backwards compatibility. This is the choice Apple and Microsoft faced. So what is AROS? This is the €43,723.20 question.
-
for £32,576.55 I'm gonna answer; drag the legacy kicking and screaming into the 21st Century :-)
-
Aros with an up to date web browser and native (or even a good port of) UAE is all I'd want in a hobby OS. A combo' of old and new.
-
aros fork?
A fork replacement utensil?
-
yeah with integrated virtual knife and plate protection
:-P
-
i don't know what it is with the lay out of his web page but i have never wanted to read it...
-
@monami
You'll need to download the English language pack.
-
AROS1 will pretty much continue on as is for 3.1 API as it's main goal. AROS2 OTOH, maybe a major break away with it's own API and let EAUE integration take care of the orginal AOS apps. Biggest issue to be solved with AROS2 is proper management of AROS2 developement. I suppose that further clarifiaction will happen sometime this summer. Year later then I would have liked, but such as life.
Dammy
-
@bloodline
for £32,576.55 I'm gonna answer; drag the legacy kicking and screaming into the 21st Century
What have you been smoking??? If you aren't interested in legacy stuff then why base all your work in an outdated OS3.x API? That lacks any sense since almost everything related to the OS3.x API should be thrown to the trashcan. Message-passing? rubbish. Memory allocation? rubbish. Multiuser capabilities? rubbish... and the list would be long
What you want is not AROS. What you want is an open source OS that gives you an amiga-like feeling (maybe using a directory structure like AmigaOS and maybe using a similiar GUI) . That is what you are looking for, not AmigaOS.
AmigaOS *is* a system based in that crap and outdated API. If you get rid of it you'll lose source code compatility and you'll be able to label it whatever way you like, but that won't have nothing in common with amiga with the exception of perhaps a similar GUI.
Quite frankly, if what you want is killing not just binary but also source code compatibility you'd better search a new OS because you are wasting time with AROS. If you killed amiga source code compatibility it will be anything but amiga-like.
I don't know why some people has some extrange fixation with the word "amiga" and they seem to want to see some kind of new OS as "amiga next gen os". Amiga API is outdated. Live with it. If you change the API it won't have anything in common with amiga, just like AmigaDE/Anywhere/Whatever hasn't anything in common with the old amigaos and won't attract my attention. Just like OSX isn't macos and is just a different OS (based on unix) with a MacOS sandbox launcher.
If you want that you could use an amiga-like skin on WinXP/OSX/Linux/Zeta, run UAE and launch your adfs with a launcher and live happy calling it "next gen amiga".
If you were really interested in a next gen OS (inspired on AmigaOS just like BeOS) you would start from scratch, not building it over an old API that just will cause you problems.
Just like people don't build castles on marshes (with the exception of the monty phytons) you shouldn't build a "new OS" on top of an outdated API and OS.
That's the same reason Be Inc didn't build BeOS using CPM as a basis.
-
@dammy
IMHO a fork is mandatory.
A new OS shouldn't have to deal with legacy problems caused by the old 3.x API.
IMHO there's no sense in calling the new effort AROS since it won't have anything related to the original effort. It won't be a v2.x version since it would be totally incompatible and probably won't reuse much code so it will be a total rewrite.
It would be in the same league as other kernels and OSes and probably could take advantage of code written for POSIX platforms.
Being "POSIX" compatible would be a good goal.
-
Crumb wrote:
Quite frankly, if what you want is killing not just binary but also source code compatibility you'd better search a new OS because you are wasting time with AROS.
AROS does *not have* binary compaibility, but when it does (E-UAE) then that can be put on top of the new system, just like it could be put on top of any modern OS if you really wanted to. Please don't start with your usual "integrated (E-)UAE will suck because it's nothing like the emulation layers of MOS/OS4 etc etc", pesonally I don't need anything that integrated, besides I will not use any potential new OS on anything but x86 in the next decade, and if so it might not be big-endian anyway.
If you killed amiga source code compatibility it will be anything but amiga-like.
What is amiga like ? to me it is the GUI, the simplicity in the directory structure, the RAM: ENV: and ENVARC:, the preferences "use" vs "save" system (that relies on the previous two), etc, not because I'm nostalgic, well I am, to a *restricted* level, but because they are well enough done. if I cannot adapt to new (and better) API then I might as well throw myself into the trashcan ;)
I don't know why some people has some extrange fixation with the word "amiga" and they seem to want to see some kind of new OS as "amiga next gen os".
Actually in case Rob forks it, he will not include anything "amiga" in it's name, he made that clear. And btw, you contradict your self here, look below (look for "LOOK HERE").
Amiga API is outdated. Live with it.
I wont ;)
If you change the API it won't have anything in common with amiga, just like AmigaDE/Anywhere/Whatever hasn't anything in common with the old amigaos and won't attract my attention.
There's MOS, OS4, and AROS.. but wait, AROS is not "amiga" according to many amiga zealots anyway.
Just like OSX isn't macos and is just a different OS (based on unix) with a MacOS sandbox launcher.
Users don't care crap about the internals, programmers might, *intelligent* programmers will not.
LOOK HERE
If you want that you could use an amiga-like skin on WinXP/OSX/Linux/Zeta, run UAE and launch your adfs with a launcher and live happy calling it "next gen amiga".
I see, if one breaks backwards compatibilty at soure/binary level then it's "anything but amiga-like" (quoting you from above), yet, somehow magically, a different *premade* OS *is* !
If you were really interested in a next gen OS (inspired on AmigaOS just like BeOS) you would start from scratch, not building it over an old API that just will cause you problems.
Just like people don't build castles on marshes (with the exception of the monty phytons) you shouldn't build a "new OS" on top of an outdated API and OS.
That's the same reason Be Inc didn't build BeOS using CPM as a basis.
Rob made clear that amiga "inspired" is his goal (not to exclude inspiration/code from other OSs though), but if you happen to *know* that *nothing* in the old API *implementation* can be reused (simetimes with modification) than why don't you just point it to him with *detail*, you seem to care alot i mean.
-
Crumb wrote:
IMHO a fork is mandatory.
A new OS shouldn't have to deal with legacy problems caused by the old 3.x API.
IMHO there's no sense in calling the new effort AROS since it won't have anything related to the original effort. It won't be a v2.x version since it would be totally incompatible and probably won't reuse much code so it will be a total rewrite.
It would be in the same league as other kernels and OSes and probably could take advantage of code written for POSIX platforms.
Being "POSIX" compatible would be a good goal.
This sounded more sensible, gotta say your previous post left me :crazy:
-
As I see it "AROS2" as we now seem to be calling it, will still be aros but with the cruft removed... exec and all the exec style structures will still be there, but some stuff is going to need the change to support new technologies and these changes will introduce incompatibilities... A price I'm prepared to pay!
-
but when it does (E-UAE) then that can be put on top of the new system
That is not different from EUAE on Linux or WinUAE on Windows.
Even more so if you break API compatibility you can not integrate UAE into OS more than you could integrate UAE into Windows.
I see, if one breaks backwards compatibilty at soure/binary level then it's "anything but amiga-like" (quoting you from above), yet, somehow magically, a different *premade* OS *is* !
If somebody wrote Windows clone which is not binary or source compatible with Windows, is it Windows at all? ;-)
-
itix wrote:
but when it does (E-UAE) then that can be put on top of the new system
That is not different from EUAE on Linux or WinUAE on Windows.
Can you open WinUAE/AmigaOS windows as host (Windows) windows ? screens ? not even these ? how does it compare then ?
Even more so if you break API compatibility you can not integrate UAE into OS more than you could integrate UAE into Windows.
Depends what your definition of "integration" is, for me it's files, windows, screens. So, why could this not be on top of an API incompatible OS ? files are already integrated in WinUAE at least, sure it would be more code invloved than on a API compliant or -like system, but nevertheless, what would be the obstacle ?
I see, if one breaks backwards compatibilty at soure/binary level then it's "anything but amiga-like" (quoting you from above), yet, somehow magically, a different *premade* OS *is* !
If somebody wrote Windows clone which is not binary or source compatible with Windows, is it Windows at all? ;-)
[/quote]
If you had a blind cousin and if he got his vision back but suddennly and unfortunately became deaf would you not still regard him your cousin ? you see, you would (learn to) communicate differently with him now, in an "incompatible" way.
-
bloodline wrote:
now is a good time to decide what we want from AROS... the floor is open...
I have to disagree. 10 years ago would have been a good time to decide. 8 years ago maybe. But now? It's been left far too late.
AROS has been badly managed, and heading in various wonky-arsed directions since the start. The position it is in today is possibly the worst it could be. Unable to run any of the software that the platform is loved for, while at the same time hamstrung by the same 1980's limitations. Comparisons to a chocolate teapot would not be completely unfair.
I mean no disrespect to Rob, but I don't think he quite gets the whole Amiga thing, and although I'd welcome a modern Amiga-like OS, I don't think he will be able to deliver. He admits himself that he is at heart a *nix hacker, and I think this is reflected in his ideas about a new breed AROS, which reads very much like yet another *nix system.
To be fair there seems to be a similar movement from within the Amiga community itself, usually presenting itself as 'porting' syndrome, often in the form of "why don't you port X, so we can have ability Y". All that will lead to is a {bleep} Ami-nix mess that will satisfy no-one.
If someone could create a system where at user level (and by that I mean everything down to the File structure) was as close to AmigaOS 3+ as possible even though it was using existing open source code underneath. By this I mean something where all the commands in C: that I'd expect are there and behave as their 3.x counterparts, where Graphics.library is really Cairo, but I wouldn't know, where CUPS is used, but I only see printer.device, and I can install drivers by dragging .printer files to devs:printers. As soon as you start looking at etc folders, cryptic commands, editing bizarre configuration files, and XWindows, you might as well be using linux.
IMO AROS would be best placed to dump the x86 side altogether and re-position itself on 68k. That might sound backwards, but I think being able to provide an open OS for emulation and classic hardware is much more useful, and more likely to enjoy success in the long run.
Sorry if the above seems mean-spirited. I honestly respect the amount of work that has been put into AROS, but I must talk honestly about how bad the situation is.
-
I kind of agree with you. One of the biggest problems with the Amiga community right now is Amiga Inc.. They own Workbench and Kickstart. We have new Amiga compatible hardware. That problem has been taken care of. We just have now way of running our old software. If AROS were made to run on the 68k and be fully binary compatible with AmigaOS, we would have a solid place to start, and the term 'Amiga like' could be replaced with 'Aros like'. This would allow the community to cut the line to the anchor that is Amiga Inc.
From there, upgrades and rewrites could happen in a more useful fashion. The biggest thing about any future incompatible version of AROS is the ability for the OS to identify the version of an application that is required to run the code.
As far as I know, to date every platform leaves it to the application to make sure that it is compatible with the OS it runs on. This means that when the application is abandoned, (as most Amiga software is) it quickly becomes unusable on new versions of the OS.
If the OS asks the application what version it runs on, it can sandbox anything that is no longer compatible, and seamlessly run it in a compatible environment.
-
Belial6 wrote:
I kind of agree with you. One of the biggest problems with the Amiga community right now is Amiga Inc.. They own Workbench and Kickstart. We have new Amiga compatible hardware. That problem has been taken care of. We just have now way of running our old software. If AROS were made to run on the 68k and be fully binary compatible with AmigaOS, we would have a solid place to start, and the term 'Amiga like' could be replaced with 'Aros like'. This would allow the community to cut the line to the anchor that is Amiga Inc.
From there, upgrades and rewrites could happen in a more useful fashion. The biggest thing about any future incompatible version of AROS is the ability for the OS to identify the version of an application that is required to run the code.
As far as I know, to date every platform leaves it to the application to make sure that it is compatible with the OS it runs on. This means that when the application is abandoned, (as most Amiga software is) it quickly becomes unusable on new versions of the OS.
If the OS asks the application what version it runs on, it can sandbox anything that is no longer compatible, and seamlessly run it in a compatible environment.
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...
-
Can you open WinUAE/AmigaOS windows as host (Windows) windows ? screens ? not even these ? how does it compare then ?
I dont know. But AROS2 with EUAE integration can not, because none of those two yet exist.
Depends what your definition of "integration" is, for me it's files, windows, screens. So, why could this not be on top of an API incompatible OS ? files are already integrated in WinUAE at least, sure it would be more code invloved than on a API compliant or -like system, but nevertheless, what would be the obstacle ?
So, what is actually this EUAE integration? If one can integrate EUAE into AROS2 which is neither API or source compatible, why one can not integrate EUAE into Linux in the same fashion?
What is so special in EUAE integration that it could not be done in other systems? And how one can guarantee it works in the system which does not yet exist.
If you had a blind cousin and if he got his vision back but suddennly and unfortunately became deaf would you not still regard him your cousin ? you see, you would (learn to) communicate differently with him now, in an "incompatible" way.
It is more like that blind cousin would be both blind and deaf.
There is nothing wrong in AROS2 idea and it is very good one. I just hope Amiga (community) does not ruin it. AROS is already sidetracked to PPC and UAE integration ideas.
Welcome to the ship, AROS. Together we stand, and together we sink.
-
itix wrote:
Can you open WinUAE/AmigaOS windows as host (Windows) windows ? screens ? not even these ? how does it compare then ?
I dont know. But AROS2 with EUAE integration can not, because none of those two yet exist.
That's not an answer to my question.
So, what is actually this EUAE integration? If one can integrate EUAE into AROS2 which is neither API or source compatible, why one can not integrate EUAE into Linux in the same fashion?
What is so special in EUAE integration that it could not be done in other systems? And how one can guarantee it works in the system which does not yet exist.
I already wrote it *could*, but you should have read my comments above perhaps ?
Guarantee ? I guess we'll have to see.
If you had a blind cousin and if he got his vision back but suddennly and unfortunately became deaf would you not still regard him your cousin ? you see, you would (learn to) communicate differently with him now, in an "incompatible" way.
It is more like that blind cousin would be both blind and deaf.
Should I interpret that "AROS 2" would not have an API, no communication with anything, at all ? :-?
There is nothing wrong in AROS2 idea and it is very good one. I just hope Amiga (community) does not ruin it. AROS is already sidetracked to PPC and UAE integration ideas.
PPC I have nothing to say about. E-UAE integration however, I don't understand, explain ?
*EDIT*
Ok you refer to 68k binary compatible OS replacement.
*/EDIT*
Welcome to the ship, AROS. Together we stand, and together we sink.
*Others* may comment on that :)
-
I wonder if he has taken a look at DragonFly BSD (http://www.informit.com/articles/article.aspx?p=766375)?
-
@All
I have quite a different vision for AROS than most here, as I don't see the split between AROS1 and AROS2 being necessary. My vision of AROS is AROS Ultimate, i.e. all the benefits of both AROS1 and AROS2.
What I'd like you to tell me is what are the 'sacred cows' of AROS1 and AROS2, i.e. the features that cannot be sacrificed. I'll start...
AROS1:
AmigaOS 3.1 API source compatibility
AROS2:
Full memory protection
Both of those can be achieved in AROS Ultimate. I'll explain how if you're interested. Find me more 'sacred cows'! :-D
-
HenryCase wrote:
I'll explain how if you're interested. Find me more 'sacred cows'! :-D
I don't know about sacred cows, but there's a "sacred" bacon hiding somewhere around here, you've encountered it :-D
-
3.1 compatibility should be at the UAE level. Too much needs to be tossed out to bring the OS to 2008 standards.
-
@Einstein
AROS does *not have* binary compaibility
AROS m68k should have it.
but when it does (E-UAE)
...or when it does (AROS m68k) :-)
Please don't start with your usual "integrated (E-)UAE will suck because it's nothing like the emulation layers of MOS/OS4 etc etc", pesonally I don't need anything that integrated, besides I will not use any potential new OS on anything but x86 in the next decade, and if so it might not be big-endian anyway.
Imagine that I drag an Icon from the host OS desktop to an opus5 window... will it copy the file? I doubt it :-)
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.
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.
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?
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).
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.
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.
Changing the kernel to keep a directory structure similar to AmigaOS wouldn't be difficult.
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.
What is amiga like ?
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.
Actually in case Rob forks it, he will not include anything "amiga" in it's name, he made that clear. And btw, you contradict your self here, look below (look for "LOOK HERE").
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.
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.
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?
There's MOS, OS4, and AROS.. but wait, AROS is not "amiga" according to many amiga zealots anyway.
For me AROS/OS4/OS3/MOS are "amiga" :-) I may like some solutions more than the others but I like them all.
Users don't care crap about the internals, programmers might, *intelligent* programmers will not.
Intelligent programmers that want to write an OS without the limitations of OS3.1 won't base his code on OS3.1 compatible code.
Users don't care about internals and that's the reason they shouldn't discuss internals of OSes.
if one breaks backwards compatibilty at soure/binary level then it's "anything but amiga-like"
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.
if you happen to *know* that *nothing* in the old API *implementation* can be reused (simetimes with modification) than why don't you just point it to him with *detail*, you seem to care alot i mean
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)
-change the OS to use a similar structure to amigaos
-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)
-
What I think everyone is missing here is not suggesting throwing away AROS and the associated systems and structures... What I think we are suggesting is where we need to modernize something and it will break compatibility then we should go for it... At the moment the default is to maintain compatibility even if that means ugly hacks to include new features.
-
Rather than fork why not split?
See, the whole EUAE for legacy bit suffers from one big shortfall: No legal ROM/Workbench
So, focus one branch of the split to being this ROM/Workbench, focusing all efforts on delivering maximum compatibility.
Now your new branch can progress forwards, breaking compat where needed, without worries.
-
Crumb wrote:
@Einstein
AROS does *not have* binary compaibility
AROS m68k should have it.
Does it even exist ?
but when it does (E-UAE)
...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 ;-)
There's MOS, OS4, and AROS.. but wait, AROS is not "amiga" according to many amiga zealots anyway.
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.
Users don't care crap about the internals, programmers might, *intelligent* programmers will not.
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.
if one breaks backwards compatibilty at soure/binary level then it's "anything but amiga-like"
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.
if you happen to *know* that *nothing* in the old API *implementation* can be reused (simetimes with modification) than why don't you just point it to him with *detail*, you seem to care alot i mean
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 ?
-
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.
-
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
-
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.
-
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. :whack: 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.
-
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
-
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
-
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.