The situation

[wawa]

no i wasnt implying that you should, just that the mutual advantage of having abiv0 and v1 simultaneously side by side might have expired.

[magorium]

There's been plenty going on with AROS.   As for how to talk about AROS's future I've seen a ton of these threads by people who don't commit code throughout the years.

That's what you get when you believe contributing consist solely of comitting.

Even when you commit or offer your commits for review they are being ignored.

Here's how non-developers can contribute.   Test, Financial support or, get others involved.   

Been there, done that. It is not considered contributing and as a consequence not being taken serious at all.

We as AROS users are one of the biggest issues with AROS.  We sit here and whine about what we want.  Then once it's contributed we never bother to test and give feedback.

I've wasted years 'not contributing' to this project and the evidence is still there for those that wish to see it. Not seeing it is putting up your blindfolds.

As long as people are ignoring the truth about these things nothing will ever change.

It would be better to start acknowleding things so that things can be put in motion.

And to give you a starter: whatever happened to the paperclips that were mentioned but not being addressed ?

[magorium]

@deadwood

im fully aware of the differences and that you are not dedicated to abi v1. but right now i think the code might have moved too far apart to back port stuff from v1.

Wholly f*ck.

Have you ever seen what deadw00d did to get 'his project' going. He's mantaining a complete list of changes between v0 and v1 and he spend at least 2 years on getting this shite into motion so that we could enjoy some of the fixes and/or new features that were added to v1.

deadw00d has always been very informative, helpful and open for suggestion on how things could become better for us as users (and 3th party developers).

If it wasn't for his 'backport' i would have quitted many moons ago (i know you most people prefer to don't see me at al anymore, but please keep spreading fud and i keep coming back :-) )

[terminills]

That's what you get when you believe contributing consist solely of comitting.

Even when you commit or offer your commits for review they are being ignored.

Been there, done that. It is not considered contributing and as a consequence not being taken serious at all.

  I can't say that I've not been taken serious and I'm mainly a financial contributor.

And to give you a starter: whatever happened to the paperclips that were mentioned but not being addressed ?

I'll stick to my financial contributions as I have no time for anything else currently.

P.S.

  Many developers have stated they got sick of wasting their time trying to appease users due to lack of feedback.

[wawa]

i think im not diminishing krzysztofs contributions, he also was babysitting me for a while when i started trying to compile odyssey, so i value him alright. just im not sure what fud am i spreading.

[miker1264]

Wow! What a lively discussion!

I had no idea there were so many people interested in AROS. ;-)

It is important to keep interest in AROS going and to introduce people to it by whatever means.

Yes. Testing and reporting problems is part of the process. But we should not discourage anyone from contributing wherever and whenever they feel most comfortable.

[magorium]

... just im not sure what fud am i spreading.

If you understood the consequences of your words:

im fully aware of the differences and that you are not dedicated to abi v1. but right now i think the code might have moved too far apart to back port stuff from v1.

That would imply that the work deadw00d put into his list of changes between the abi's (and how to fix certain hickups when you backport) has no meaning at all (at least not to you anymore, as you imply).

fwiw: icaros is based upon this works for many moons now. That also means that if it wasn't for the backport that icaros would have been on hold for several years now. (if you count back from today).

I'm not implying it is still possible to maintain the backport(although deadw00d himself made his comments about that so you can decide for yourself) but taken another remark from your hands:

actually im not in a position to comment on this, but from my private pov abi v0 is "feature complete" and can be used "as is" completely fine. its also fine when people are fixing it up or contributing to it, if they wish, and they do. personally, i was involved with v1 from the start since m68k is my main area of interest.

of course you are entitled to your own pov, but imo it is wrong. As a devloper of 3th party application i can tell/proof your wrong on many occasions. The situation woul;d have been much worse if the backport wouldn't exist.

To make sure i write it again: current icaros is based on this work and new versions of icaros (whether you consider it a good or bad things that new v0 AROS distro versions are distributed or not) can only exist because of that.

[miker1264]

It's good to discuss important matters. But discussing the merits of ABIv0 or ABIv1 won't change much. AROS 64bit needs software. So start building and making and compiling! That will change things.

AROS has many things going for it that are very attractive. It can run on many different platforms as native or hosted. AROS Hosted on Linux works REALLY WELL. The only other OS hosted on Linux Is Mac OS X. That works well too. Darwin is Linux.

[nikos]

There are things broken in AROS64. Maybe Deadwood will fix it. I guess he don't want to spend all his time to fix others bugs. I think he is kind of finished with that. Just like Neil seams to be. That is maybe why he got his stable branch. He is the only of the main Devs. that show up here.

[wawa]

ok. afair, at some point the developers consensus has decided that there is going to be abi v1 in particular in order to close tha gap of the source compatibility with the genuine amiga os, that abi v0 has left open. work has been put into this, introducing new platforms such as m68k along the way, which was actually part of the pursuit, because it allowed cross testing behaviour of the binaries with the platform of reference.

i think, this has not only influenced low level parts of the system but also userland such as mui/zune. i remember a lot of issues with that back in the day when for instance afaos was designed and differences in behaviour of mui and zune have made special zune versions necessary at times. many apps are dont work right on zune to this day, but it has definitely improved.

now, i understand that part of improvements gone into that effort, because of its duration, have been, for the time being, interim so to say, made available for the public of a stable while obsolete declared abi platform.

i also understand that some developers have become weary of the slow progress and tend to re-declare the obsolete abi v0 valid target and rather try to gather an application pool around it.

but then, why to introduce a binary incompatible platform as a base for that. where is the advantage?

[magorium]

@wawa
Finally a more constructive post from your hand. Thank you for that, although there seem to be some misconception. fwiw: a misconception that was explained on the old aros-exec forums many times.

let me start by writing that
1. this is as far as my recollection goes. It might be wrong, in which case feel free to correct me.
2. i'm generalizing which does not imply i'm addressing individuals.

ok. afair, at some point the developers consensus has decided that there is going to be abi v1 in particular in order to close tha gap of the source compatibility with the genuine amiga os, that abi v0 has left open. work has been put into this, introducing new platforms such as m68k along the way, which was actually part of the pursuit, because it allowed cross testing behaviour of the binaries with the platform of reference.

There once was a project named AROS which aimed to be(come) a reimplementation of the amiga OS. Progress was made, milestones reached and the project grew (and had a lot of discussions of what would be the correct way to continue).

At a certain point in time it was decided to make it as api compatible as possible, so that old sources could simply be recompiled and run on AROS

In that period it was the believe that whatever AROS tried it would become (almost) impossible to ever make it binary compatible with amiga 68k. One of the main restrictions being the kickstart (how to ever fit AROS kernel in there).

So development went on and api compatibility was not so strict back then (why bother factor). Whenever there was a better way to implement things it was implemented that way (neverminding the api compatibility let alone abi compatibility).

Of course this causes problems being source-compatible so api compatibility was becoming a more serious issue. Things were fixed to overcome that.

Winding forward fast there was one certain individual who said: shite on that, i want AROS to be binary compatible as well. And so he did.

But right before that point (regular) AROS was both abi and api incompatible to 68k amiga. The only way to solve was to create a new abi and 'break' things. Better clean up things (add incompatibilities between abi's) and so it went.

One problem remained and that was that in those days there was a distro and software base for the existing api/abi rendering it incompatible with whatever changes where necessary for Jason to reach his goal.

So things began to split (further) between abi's.

On one hand you need your userbase to have proper feedback/advertisement and on the other hand you want to move on as quickly as possible in order to reach certain goals.

i think, this has not only influenced low level parts of the system but also userland such as mui/zune. i remember a lot of issues with that back in the day when for instance afaos was designed and differences in behaviour of mui and zune have made special zune versions necessary at times. many apps are dont work right on zune to this day, but it has definitely improved.

It has improved but it is still not compatible. never mind the newer versions, which opens another can of worms.

now, i understand that part of improvements gone into that effort, because of its duration, have been, for the time being, interim so to say, made available for the public of a stable while obsolete declared abi platform.

Only certain individuals declared it obsolete. If you truly use AROS as your daily driver and develop for it then you can see the incompatibilities and inconsistencies. They are still there.

i also understand that some developers have become weary of the slow progress and tend to re-declare the obsolete abi v0 valid target and rather try to gather an application pool around it.

Also here only certain individiuals have made it as such.

Picture a whole userbase who enjoy AROS (using old abi) and people using software, running into bugs and reporting them. They are the users that enable a developer to receive (meaningful) feedback about their progress (at least in case a developer is interrested in receiving such feedback).

but then, why to introduce a binary incompatible platform as a base for that. where is the advantage?

Exactly. Why would you introduce a new abi and add all kind of (new) features that weren't part of the original definition of the OS to begin with ?

Because it is fun, and it is the R in AROS.

And to contrary believe i do support going v1 and 64 bit asap. Unfortunately for me, that ship has sailed many moons ago (*).

The practice is that it is unstable (abi/api changes) so not interresting for me as 3th party developer, many (old) flaws that (still) also exist in v0 that aren't addressed and new features are introduced that are buggy (comes with the territory) and we are still talking about the same missing features.

what i would have expected (ignorant me) is a (proper) round-up for v0 and leave it at that. Fix things when reported and when possible and keep it stable. That leaves room for v1 and 64-bit to mature in its own space and time (and also learn from the reported issues of the old ABI and make things better).

imho better would be to swith to v1 abi (also for v0) and start a new branch for all new features like smp and whatever. That way you would have a 'stable' versions that is api/abi compatible to 68k and in case new features are required (for example because new hardware like vampire can only be supported by such support) could then be backported to the 'stable' branch.

It would allow for the existing software base to exists (without the need for recompilation) and be extended when necessary.

imo that is what deadw00d is/was trying to accomplish with his backport as much as possible, albeit using a different naming scheme and skipping a step/branch.

So, imo your post tells thing a bit in a topsy turvy manner 

(*) i used to use AROS in a 24/7 environment using my own custom build and own custom software. So i could not afford to recompile my entire software base over and over again and get blocked by (missing and/or changed) features. Since then i've migrated because it was becoming obvious to me that things were going into a dead end street.

Although i tend to agree with miker1264 that discussing the merits of v0 and v1 does not matter much. It is simple: if you do not care for your existing software to run anymore then it is pretty easy to be happy with using v1. Otherwise you are more or less condemned to use an old(er) abi.

Officially killing off the old abi (or preferring one over the other) isn't going to change that for a bit. What does matter though (and imho) is the way you handle that and how you treat your userbase. Keep in mind that my software has its own userbase for which i'm accountable.

I would say, travel back in time and become a MacOS user so you can experience that feeling fully at first hand.

[wawa]

from what i remember when m68k target was introduced and jason and toni picked up the task, which was when i got into aros, it was a general consensus that this task is approved and it should have been completed earlier, except there were no skilled developers to be found till then. in my eyes that means that abi v1 has been declared a valid target, but well, i have not red the dev ml prior to that.

nevertheless i dont remember that much of disagreement what concerns the way forward, but then i might be wrong. certainly though i didnt have an impression that it was just a single persons initiative.

[miker1264]

from what i remember when m68k target was introduced and jason and toni picked up the task, which was when i got into aros, it was a general consensus that this task is approved and it should have been completed earlier, except there were no skilled developers to be found till then. in my eyes that means that abi v1 has been declared a valid target, but well, i have not red the dev ml prior to that.

nevertheless i dont remember that much of disagreement what concerns the way forward, but then i might be wrong. certainly though i didnt have an impression that it was just a single persons initiative.

AROS 68k is a worthwhile effort and there will be a growing demand for that software as the userbase for 68k increases.

But AROS itself hasn't been a one-man project, as far as I know. When I got my build system to work and AROS compiled for the first time, not long ago, I remember watching the text scroll by on the screen. Yes, I'm easily amused by such things! ;-)

As I sat there watching it building I thought to myself how grateful I was at all the tremendous effort over the years that has become AROS. There is still much to be done. But I'm still very grateful for everyone who has contributed to AROS and for all those that continue to do so on a regular basis.

Thank you to everyone that has contributed to this wonderful thing called AROS.

[magorium]

from what i remember when m68k target was introduced and jason and toni picked up the task, which was when i got into aros,

You might be correct in that shortly prior to Jason's work the 68k target was been taken more serious and the abi split went shortly before that. It can be checked from the commit history (which i was too lazy to do).

it was a general consensus that this task is approved and it should have been completed earlier, except there were no skilled developers to be found till then. in my eyes that means that abi v1 has been declared a valid target, but well, i have not red the dev ml prior to that.

I seem to remember something similar in that a) there wasn't enough manpower even back then and b) especially the kickstart fitting magic would require someone with enough time and mindset to be able to accomplish the task. I vividly remember the drive that Jason had to be able to get AROS booting on his classic hw.

At that time Toni could also only do what he could (given his other projects)

nevertheless i dont remember that much of disagreement what concerns the way forward, but then i might be wrong. certainly though i didnt have an impression that it was just a single persons initiative.

The events after that show that there was not a general consensus. But that is from my point of view. After this hapened there was a little time of euforia, then ARIX... i seems to remember Anubis being mentioned again, the backport branch, much (heated) arguments both on forums and irc to finally end up at github.

Just check the commit history and prior arguments on the ml to see for yourself if there is concensus or not. Unless something changed there simply isn't any (or at least there isn't any proof of that). Oh, and i almost forgot the final insult being slack.

Again and unfortunately this does not change anything to the current situation and still presents us with the dilemma as mentioned before.

[terminills]

@wawa
Finally a more constructive post from your hand. Thank you for that, although there seem to be some misconception. fwiw: a misconception that was explained on the old aros-exec forums many times.

let me start by writing that
1. this is as far as my recollection goes. It might be wrong, in which case feel free to correct me.
2. i'm generalizing which does not imply i'm addressing individuals.

ok. afair, at some point the developers consensus has decided that there is going to be abi v1 in particular in order to close tha gap of the source compatibility with the genuine amiga os, that abi v0 has left open. work has been put into this, introducing new platforms such as m68k along the way, which was actually part of the pursuit, because it allowed cross testing behaviour of the binaries with the platform of reference.

There once was a project named AROS which aimed to be(come) a reimplementation of the amiga OS. Progress was made, milestones reached and the project grew (and had a lot of discussions of what would be the correct way to continue).

At a certain point in time it was decided to make it as api compatible as possible, so that old sources could simply be recompiled and run on AROS

In that period it was the believe that whatever AROS tried it would become (almost) impossible to ever make it binary compatible with amiga 68k. One of the main restrictions being the kickstart (how to ever fit AROS kernel in there).

So development went on and api compatibility was not so strict back then (why bother factor). Whenever there was a better way to implement things it was implemented that way (neverminding the api compatibility let alone abi compatibility).

Of course this causes problems being source-compatible so api compatibility was becoming a more serious issue. Things were fixed to overcome that.

Winding forward fast there was one certain individual who said: shite on that, i want AROS to be binary compatible as well. And so he did.

But right before that point (regular) AROS was both abi and api incompatible to 68k amiga. The only way to solve was to create a new abi and 'break' things. Better clean up things (add incompatibilities between abi's) and so it went.

One problem remained and that was that in those days there was a distro and software base for the existing api/abi rendering it incompatible with whatever changes where necessary for Jason to reach his goal.

So things began to split (further) between abi's.

On one hand you need your userbase to have proper feedback/advertisement and on the other hand you want to move on as quickly as possible in order to reach certain goals.

i think, this has not only influenced low level parts of the system but also userland such as mui/zune. i remember a lot of issues with that back in the day when for instance afaos was designed and differences in behaviour of mui and zune have made special zune versions necessary at times. many apps are dont work right on zune to this day, but it has definitely improved.

It has improved but it is still not compatible. never mind the newer versions, which opens another can of worms.

now, i understand that part of improvements gone into that effort, because of its duration, have been, for the time being, interim so to say, made available for the public of a stable while obsolete declared abi platform.

Only certain individuals declared it obsolete. If you truly use AROS as your daily driver and develop for it then you can see the incompatibilities and inconsistencies. They are still there.

i also understand that some developers have become weary of the slow progress and tend to re-declare the obsolete abi v0 valid target and rather try to gather an application pool around it.

Also here only certain individiuals have made it as such.

Picture a whole userbase who enjoy AROS (using old abi) and people using software, running into bugs and reporting them. They are the users that enable a developer to receive (meaningful) feedback about their progress (at least in case a developer is interrested in receiving such feedback).

but then, why to introduce a binary incompatible platform as a base for that. where is the advantage?

Exactly. Why would you introduce a new abi and add all kind of (new) features that weren't part of the original definition of the OS to begin with ?

Because it is fun, and it is the R in AROS.

And to contrary believe i do support going v1 and 64 bit asap. Unfortunately for me, that ship has sailed many moons ago (*).

The practice is that it is unstable (abi/api changes) so not interresting for me as 3th party developer, many (old) flaws that (still) also exist in v0 that aren't addressed and new features are introduced that are buggy (comes with the territory) and we are still talking about the same missing features.

what i would have expected (ignorant me) is a (proper) round-up for v0 and leave it at that. Fix things when reported and when possible and keep it stable. That leaves room for v1 and 64-bit to mature in its own space and time (and also learn from the reported issues of the old ABI and make things better).

imho better would be to swith to v1 abi (also for v0) and start a new branch for all new features like smp and whatever. That way you would have a 'stable' versions that is api/abi compatible to 68k and in case new features are required (for example because new hardware like vampire can only be supported by such support) could then be backported to the 'stable' branch.

It would allow for the existing software base to exists (without the need for recompilation) and be extended when necessary.

imo that is what deadw00d is/was trying to accomplish with his backport as much as possible, albeit using a different naming scheme and skipping a step/branch.

So, imo your post tells thing a bit in a topsy turvy manner 

(*) i used to use AROS in a 24/7 environment using my own custom build and own custom software. So i could not afford to recompile my entire software base over and over again and get blocked by (missing and/or changed) features. Since then i've migrated because it was becoming obvious to me that things were going into a dead end street.

Although i tend to agree with miker1264 that discussing the merits of v0 and v1 does not matter much. It is simple: if you do not care for your existing software to run anymore then it is pretty easy to be happy with using v1. Otherwise you are more or less condemned to use an old(er) abi.

Officially killing off the old abi (or preferring one over the other) isn't going to change that for a bit. What does matter though (and imho) is the way you handle that and how you treat your userbase. Keep in mind that my software has its own userbase for which i'm accountable.

I would say, travel back in time and become a MacOS user so you can experience that feeling fully at first hand.

afair the 68K branch was a stale branch when the ABI split happened.