20-Apr-2024 02:31 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 71 items in your selection [1 - 50] [51 - 71]
[Web] New CAM article on ExecSGANN.lu
Posted on 10-Sep-2003 09:36 GMT by SimplePPC71 comments
View flat
View list
New CAM article released on OS 4's ExecSG. http://os.amiga.com/cam/index.php?i=7&p=7 Excellent introduction by Thomas Frieden of Hyperion to the new memory subsystem of ExecSG.
New CAM article on ExecSG : Comment 1 of 71ANN.lu
Posted by Amon_Re on 10-Sep-2003 08:03 GMT
Finally a post that's not flamebait :)

Cheers
New CAM article on ExecSG : Comment 2 of 71ANN.lu
Posted by Matt Parsons on 10-Sep-2003 08:10 GMT
In reply to Comment 1 (Amon_Re):
I agree an interesting article and it explains rather simply (ie nice to understand for the non technical) how Virtualised address spaces work.
New CAM article on ExecSG : Comment 3 of 71ANN.lu
Posted by Amon_Re on 10-Sep-2003 08:16 GMT
In reply to Comment 2 (Matt Parsons):
Yep, i agree, i'm looking forward to the next instalments ;)

Cheers
New CAM article on ExecSG : Comment 4 of 71ANN.lu
Posted by Crumb // AAT on 10-Sep-2003 08:27 GMT
It's quite interesting... the new OS4 API sounds quite well to me, let's hope it will work fast :-)

@Matt:
if I have understand correctly each app could have its own way of allocating memory, so once it's implemented, you may select which apps you want without memory protection to keep compatibility...
In theory, with the resource tracking the OS may know which tasks have been launched by an app and which memory chunks have been allocated too, allowing these tasks to write in each other memory, and keeping all these tasks in the same virtual memory space, and other tasks would have its space too...
Is it right? I don't know very well the inner working of AmigaOS and would be interested to know if it would be possible...
New CAM article on ExecSG : Comment 5 of 71ANN.lu
Posted by Richi on 10-Sep-2003 08:36 GMT
Cool! Os4 rules!

It says: "Memory protection: This is the next big step forward. One of the next versions of AmigaOS 4 will have per-application memory objects"
So what will be implemented in Os4.0?

Thanks
New CAM article on ExecSG : Comment 6 of 71ANN.lu
Posted by T_Bone on 10-Sep-2003 08:37 GMT
They forgot to mention that ExecSG is named after Steve Giovanella :D
New CAM article on ExecSG : Comment 7 of 71ANN.lu
Posted by Matt Parsons on 10-Sep-2003 08:38 GMT
In reply to Comment 4 (Crumb // AAT):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
if I have understand correctly each app could have its own way of allocating memory, so once it's implemented, you may select which apps you want without memory protection to keep compatibility...
In theory, with the resource tracking the OS may know which tasks have been launched by an app and which memory chunks have been allocated too, allowing these tasks to write in each other memory, and keeping all these tasks in the same virtual memory space, and other tasks would have its space too...
Is it right? I don't know very well the inner working of AmigaOS and would be interested to know if it would be possible...

<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Certainly if you are prepared to have two kernels, on for the MP tasks and one for the Non-MP tasks... since the non-mp takes would be able to take down the system you don't want them running int he same context as the MP ones.

MP and nonMP can't work on the same Amigaoid OS system, since NonMP taks can not run with any kind of MP.

Memory enforcement and resource tracking (as indeed has been implemented) is possible though.
New CAM article on ExecSG : Comment 8 of 71ANN.lu
Posted by catohagen on 10-Sep-2003 08:41 GMT
exellent cam ...very,very good news indeed !
New CAM article on ExecSG : Comment 9 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 08:47 GMT
Remove "eptember" from September CAM
New CAM article on ExecSG : Comment 10 of 71ANN.lu
Posted by Amon_Re on 10-Sep-2003 09:07 GMT
In reply to Comment 6 (T_Bone):
NOOOOOOOOO!!!!!!!!

Cheers ;)
New CAM article on ExecSG : Comment 11 of 71ANN.lu
Posted by Joe "Floid" Kanowitz on 10-Sep-2003 09:41 GMT
In reply to Comment 7 (Matt Parsons):
Matt Parsons said,
> Certainly if you are prepared to have two kernels, on for the MP tasks
> and one for the Non-MP tasks... since the non-mp takes would be able to
> take down the system you don't want them running int he same context as
> the MP ones.

> MP and nonMP can't work on the same Amigaoid OS system, since NonMP
> taks can not run with any kind of MP.

Hrrrm. First of all, this sort of begs the question why you'd want non-MP tasks in the first place, though Petunia - and thus the wealth of 68k legacyware - does make things interesting. But second... am I missing something? The kernel or emulation layer would have to provide a different VM context - you'd have to dedicate/present what looks like a linear block of address space to the 'virtual Amiga' somehow - but that doesn't make it *impossible,* though it could make it *something nobody wants to do.*

So if I'm thinking about this right, the VM and emulation layer(s) would have some extra-long code paths for handling and tracking whether apps are running 'shared,' which apps they're sharing with, and so forth (and you'd end up with something that looks like a mini-Exec, maybe, to determine where processes open up in that shared context)... but you could still schedule everything through the 'normal' kernel, which seems to be what everyone's shooting for here.

I'm braindead right now, so I'm not going to pretend that I'm 100% technically accurate, or risk using any more 'real terms' (like "Exec," "VM layer," etc.). But... impossible? (I'm not thinking of supporting 'hardware-hitting' or anything here, just software that used it as an IPC mechanism...)

> Memory enforcement and resource tracking (as indeed has been implemented)
> is possible though.

Given the current approach, where nobody's trying too hard, because 99% of everything is still written assuming it...

The question seems to be whether it's worth going through all the trouble and virtualization to keep things scheduled as individual tasks, when you can just wrap them all in one process - UAE - and still have it run pretty darn fast. While it sounds like we'd be better off scrapping it all for "AG2" (or anything 'modern'), I bet this'll still be an issue for some people on through 4.1/4.2.. Especially if we want to believe the timetable and expect either in the next two years.
New CAM article on ExecSG : Comment 12 of 71ANN.lu
Posted by IamCleverToo on 10-Sep-2003 09:58 GMT
In reply to Comment 1 (Amon_Re):
"Finally a post that's not flamebait :)"

Not for long...




Hello everyone, I decided to come back to the Amiga market, again. I missed all the flame wars. The PC market is so boring cause most people don't care about trademarks or who or what companies manufacture their motherboards. Far to many prejudice people here. And I have to put up with the Red & Blue trolls.... I think I'll leave again!
New CAM article on ExecSG : Comment 13 of 71ANN.lu
Posted by Matt Parsons on 10-Sep-2003 10:01 GMT
In reply to Comment 11 (Joe "Floid" Kanowitz):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Hrrrm. First of all, this sort of begs the question why you'd want non-MP tasks in the first place, though Petunia - and thus the wealth of 68k legacyware - does make things interesting. But second... am I missing something? The kernel or emulation layer would have to provide a different VM context - you'd have to dedicate/present what looks like a linear block of address space to the 'virtual Amiga' somehow - but that doesn't make it *impossible,* though it could make it *something nobody wants to do.*

So if I'm thinking about this right, the VM and emulation layer(s) would have some extra-long code paths for handling and tracking whether apps are running 'shared,' which apps they're sharing with, and so forth (and you'd end up with something that looks like a mini-Exec, maybe, to determine where processes open up in that shared context)... but you could still schedule everything through the 'normal' kernel, which seems to be what everyone's shooting for here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

ok, the big problem is that AmigaOS works using a messages passing system that allows anything to be passed in the message. This means that when a task wants to access a data structure often only a pointer to that structure is passed (rather than the data itself) so the task can then treat that data like it's own. This is VERY VERY efficient, and works fine if the program is good, but for this system to work every task has to have access to any memory area... remove the ability to access any memory area and passing pointers no longer works and all software (including most of the OS) has to be rewritten.

With the cool JIT's that have been released with MOS and are included with AOS4, the 68k code is turned into PPC code... thus it is treated much as it it is PPC native... that code can not work on an MP system.

The solution? Have a "box" for the nonMP tasks with their own OS (or layer to the main OS) and let the non MP taks fight it out in a safe envirnment.
New CAM article on ExecSG : Comment 14 of 71ANN.lu
Posted by Matt Parsons on 10-Sep-2003 10:04 GMT
In reply to Comment 13 (Matt Parsons):
sorry for my horrible spelling :-(

new keyboard ;-)
New CAM article on ExecSG : Comment 15 of 71ANN.lu
Posted by DruggedBunny on 10-Sep-2003 10:07 GMT
Excellent article, very well written to explain a complex subject clearly and concisely!
New CAM article on ExecSG : Comment 16 of 71ANN.lu
Posted by Johan Rönnblom on 10-Sep-2003 10:24 GMT
You want non-MP tasks as long as you're not willing to throw away all
existing Amiga software.
New CAM article on ExecSG : Comment 17 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 10:42 GMT
In reply to Comment 15 (DruggedBunny):
Long live the King!
New CAM article on ExecSG : Comment 18 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 10:52 GMT
This design is still some way from even Windows 95, let alone a modern OS.

It suffers badly from _address_ fragmentation, which means that large allocations become harder and harder, eventually only page-sized lumps can be allocated. This problem will be more acute the more RAM you use (if you buy and use the 1GB Hyperion claims will be supported you can expect a lot of fragmentation trouble)

It's also very wasteful of RAM. A minimal 'hello world' process will most likely need over 200 kbytes of allocated RAM (not just address space, actual RAM) compared to a few hundred bytes in AOS 3 or 16 kbytes in Linux.

As an aside, it's quite _possible_ to make OS 3.x apps run comfortably alongside OS 4.x apps and give both the operating system itself AND all OS 4.x apps full memory protection, all automatically. It seems unlikely that Thomas has the knowledge and ability to do that though.
New CAM article on ExecSG : Comment 19 of 71ANN.lu
Posted by tonya on 10-Sep-2003 10:58 GMT
In reply to Comment 18 (Anonymous):
yes lol we belive you and you are so right , thats why u posted it in anon mode.

lame...we know who u are..

anyway you are wrong :)


best cam YET! ...love it.
New CAM article on ExecSG : Comment 20 of 71ANN.lu
Posted by Mario on 10-Sep-2003 11:00 GMT
In reply to Comment 19 (tonya):
It's not that you haven't posted anonymous, tonya. Everyone knows tonya anyway.
New CAM article on ExecSG : Comment 21 of 71ANN.lu
Posted by Joe "Floid" Kanowitz on 10-Sep-2003 11:01 GMT
In reply to Comment 13 (Matt Parsons):
Matt Parsons said,
> ok, the big problem is that AmigaOS works using a messages passing
> system that allows anything to be passed in the message.

Yep, in the legacy system, anyway. I need to reread that bit about what's been done (if anything) for the native/"evolved" 4.0 API.

> remove the ability to access any memory area and passing pointers no
> longer works and all software (including most of the OS) has to be
> rewritten.

But you only need this for 'kernel' calls, and IPC. And for every library call. So yeah, you have a point. But even if you had to load libraries 'twice' (or from another angle, you'd just have to stop using 'legacy' libs in the MP side of the system, and only keep them around for the shared mem support)... that doesn't seem too awful, from a "user" perspective. I'm sure it's hell from a developer's standpoint. (And yes, I need to reread that article on the library mechanisms before I make another post in this thread.)

I think I'm just reacting to that vague use of 'kernel context.' Or something.

> With the cool JIT's that have been released with MOS and are included
> with AOS4, the 68k code is turned into PPC code... thus it is treated
> much as it it is PPC native... that code can not work on an MP system.

Yep, unless the MP system is built to handle/emulate/virtualize as necessary for the special case. Now, as far as I can tell, we've suddenly 'wrapped around'* to having MorphOS holding off on memory protection in favor of message-passing speed, and "AG2" promising it... but I do forget whatever came up about MOS 2.0 (something did, didn't it?), and/or whether this sort of MP-native/legacy-Amiga split might be doable somehow already with Quark (though I imagine it'd require reducing the memory allocated to the "A/Box," at boot time, maybe... I'm not clear on what Quark has or is ever supposed to have in terms of VM, let alone this sort of complexity).

[*Okay, I still remember when MOS sounded like a Be- or OS/2-style, 'full-fledged,' MP, stable-object-oriented-OS-of-the-month sort of effort. Whether that was ever anyone's *intention,* vs. my misinterpretation, I dunno.]

It's all about tradeoffs in terms of how you want to introduce MP, *if* you want to introduce MP, how much you want to complicate/simplify the design(s)... You can handle the problem a number of ways, so it's good there's diversity in the market. (One of the ways is to *not* handle it, and continue with shared memory forever, which... certainly has its niche, but can't help but bore me in comparison.)

> The solution? Have a "box" for the nonMP tasks with their own OS (or
> layer to the main OS) and let the non MP taks fight it out in a safe
> envirnment.

Exactly, and that takes us back to the "do 'we' do all this virtualization work all over again to keep all tasks, shared mem or MP, working under the main scheduler, or do we do it all in an emulation process... Where, as UAE shows, it's already been done, so we can get on with life?"

The advantage of doing it the hard (ridiculously hard?) way is that, of course, there's less argument over "Is it an Amiga?"

(Let it be said that I've got no legacyware myself, and so personally care more about a stable, MP OS with all the 'simplicity'/'usability'/'modularity' trimmings I've been missing than one that has the dubious utility of running existing software really, really fast. But hey, if those three things are there, I'll trade off a *little* stability until such time as it can be put into place, and if that's what it takes to give me a browser and IRC client out of the box... well, then maybe I do have to care about 'legacyware.')
New CAM article on ExecSG : Comment 22 of 71ANN.lu
Posted by Kjetil on 10-Sep-2003 11:07 GMT
In reply to Comment 7 (Matt Parsons):
I never ever herd about old software to aware of new software, clearly your statement is wrong, you can have MP aware apps and none MP aware apps same system., how ever you can not enforce MP on some thing not aware of MP, so you can only protect part of system where the none MP apps will not access by the old way.

68k programs be allowed pas argument throw 68k throw registers even modify memory inside other programs of the 68k type, recompiling means that you all sow need to modify all the part where that type of behaviour is not allowed, porting the system to PPC means that 68k programs that are allowed to write to memory areas of system resources can not operate, unless the system rescores provides safe areas of memory where 68k task can write (shard memory), if Hyperion find it to be to troublesome to rewrite every thing to more strict approach on the first point realise it most understand that way. If they do not, they can not swap out memory pages ether, so then there is no swap space ether.

As for PPC apps and other apps can not expect to write to addresses of other programs as they may be pages on tow the swap page or they may be rearranged by the MMU, memory need to shaded to stay in the system, 68k task are shard memory, 68k task are not allocated as program space nor as execution they are allocated as data, once the JIT detects program counters in side 68k memory the program JIT will kick in revere memory in side executables, area and translate the code, when done it will set program pointer in side the executable area.

This document state that even PPC programs can crash the system by overwriting memory of other PPC tasks, it should not be done when having different memory maps for individual tasks, if/when they reargue the memory maps under the tasks, they well need to go throw all the structures under all individual task to check if memory is in use or not.
((Number task) * (swap pointer time)) + ((number of memory blocks reserved) * (scan memory block information time))

This is all sow the maximum time you can expect when an enforced memory hit, the system will be a bit slower not some thing you normally will detect I think.
New CAM article on ExecSG : Comment 23 of 71ANN.lu
Posted by Matt Parsons on 10-Sep-2003 11:08 GMT
In reply to Comment 21 (Joe "Floid" Kanowitz):
for me the concern is not legacy, but simply speed :-)

an MP system will be slower (not noticable with modern CPU's like the PPC and x86), but still... ;-)
New CAM article on ExecSG : Comment 24 of 71ANN.lu
Posted by Joe "Floid" Kanowitz on 10-Sep-2003 11:17 GMT
In reply to Comment 16 (Johan Rönnblom):
Johan Rönnblom said,
> You want non-MP tasks as long as you're not willing to throw away
> all existing Amiga software.

I hate to just blather on in this thread, but... Yeah, I'm not really as dumb as I sound. I just want to assume that we'll have to transition to MP *somehow* and *someday,* because that's where all the "interesting" is.

So don't take it *too* seriously, I guess. At some point, machines will probably be so disgustingly fast that we'll be able to say, "Wow, we can run emulation in a process and get reasonable speed *and* timing guarantees." At least, assuming the emulation host is a RTOS with a femtosecond guarantee. ;)
New CAM article on ExecSG : Comment 25 of 71ANN.lu
Posted by Amon_Re on 10-Sep-2003 11:29 GMT
In reply to Comment 18 (Anonymous):
Could you prove your point?

...

Tought so

Cheers
New CAM article on ExecSG : Comment 26 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 11:53 GMT
In reply to Comment 25 (Amon_Re):
Which point specifically?

The VM performance problems are (duh) a consequence of OS4's VM design as described in the article. The single memory space means page-level address fragmentation is inevitable, pure and simple.

Work out for yourself how much RAM an OS4 process will occupy. A page for each of the basic types of memory (program text, initial data, stack and heap) makes 256 kbytes before any OS overhead is taken into account. Ouch. Some of that can be clawed back in the single memory space by horrible tricks, but I think the cure is even worse than the affliction.

The only way to _prove_ that it's possible to do the "memory protection" hack for OS 4 while OS 3.x apps continue to co-exist would be to implement it. I don't intend to do that, so you'll have to "trust me" on that one, or wait for confirmation from other smart people that you do trust, perhaps Bernie Meyer?
New CAM article on ExecSG : Comment 27 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 12:42 GMT
In reply to Comment 18 (Anonymous):
Here's $50 go buy 512MB of RAM
New CAM article on ExecSG : Comment 28 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 12:45 GMT
In reply to Comment 27 (Anonymous):
Uh, max for CSPPC is 128MB.
New CAM article on ExecSG : Comment 29 of 71ANN.lu
Posted by themoose on 10-Sep-2003 12:49 GMT
Did anyone else notice the Mediator Support mentioned at the bottom of the article? Good news I think, though the 64k page size sounds way big, I think Windows granularity is 4Kb. I do hope this doesn't mean every time you do a malloc() you get 64Kb when you only ask for 1Kb.

I would love to know what Hype are doing that would create a massive overhead if they had bigger pages. I trust its done in such a way that it can be changed later. If things are in objects and assuming Exec isnt going to try and reorganise RAM pages from one object to another one, why can't the pages be any sensible size?

If something asks for 109Kb does it really matter if it gets 2 64Kb pages of object A or 7 16Kb from object B?
New CAM article on ExecSG : Comment 30 of 71ANN.lu
Posted by Ben Hermans/Hyperion on 10-Sep-2003 12:52 GMT
In reply to Comment 26 (Anonymous):
>The VM performance problems are (duh) a consequence of OS4's VM design as >described in the article.

It is rather hilarious that you already complaining about performance problems when you have never actually used the product.

You strike me as one of those "experts" that also claimed our emulation concept could not work etc.

The word dilletant comes to mind.
New CAM article on ExecSG : Comment 31 of 71ANN.lu
Posted by Matt Parsons on 10-Sep-2003 13:00 GMT
In reply to Comment 30 (Ben Hermans/Hyperion):
>>>>>>>>>>>>>>>>>>>>>>>>>>>
It is rather hilarious that you already complaining about performance problems when you have never actually used the product.

You strike me as one of those "experts" that also claimed our emulation concept could not work etc.

The word dilletant comes to mind
<<<<<<<<<<<<<<<<<<<<<<<<<<<

My My, you are jumpy today Ben!!! Noone is saying that your OS4 is going to be a slow performer, but there is going to be an overhead (regarless of magnitude) with any VM system.
New CAM article on ExecSG : Comment 32 of 71ANN.lu
Posted by Fabio Alemagna on 10-Sep-2003 13:00 GMT
In reply to Comment 30 (Ben Hermans/Hyperion):
> It is rather hilarious that you already complaining about performance problems
> when you have never actually used the product.

One is supposed to be able to draw conclusions from the details you are delivering to us, isn't she? Or else, why bothering about delivering details at all?

I bet you'd not use the word "hilarious" if someone applauded the AOS4 design (as many followers indeed do), you'd instead be pleased, and indeed you are.

You may say his conclusions are wrong, you certainly can't define his comments "hilarious".

If you have anything techical to say to contraddict the guy, say it, otherwise you better stay silent.
New CAM article on ExecSG : Comment 33 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 13:08 GMT
In reply to Comment 29 (themoose):
No, when you allocate you do not get 64k, you get what you ask for plus the old packing fraction ;-) the Memory Objects are used to manage
"pools" of allocated and unallocated memory. Applications can have memory allocated
from any of these "pools". The MMU takes care of the table for virtual address/real address
and whilst it is true some of this may end up getting stored in normal memory itself
( or rather more likely cache ) it is still several magnitudes more efficient in
INTERNAL design ( on how it lays out and manages memory within the pools and accross
the pools ) than AOS3.x and a magnitude more efficient than not dividing the memory up
into said pools owned by memory objects.

I used "pool" instead of "page" to try and avoid people thinking about archaic
use of the term.

Even so, it is transitionary, and takes us forward as an OS.
New CAM article on ExecSG : Comment 34 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 13:08 GMT
In reply to Comment 30 (Ben Hermans/Hyperion):
I have used your product while you were touring, and to be honest - and I am really sorry about this - it was slow and sluggish.
New CAM article on ExecSG : Comment 35 of 71ANN.lu
Posted by Fabio Alemagna on 10-Sep-2003 13:37 GMT
In reply to Comment 33 (Anonymous):
> Even so, it is transitionary, and takes us forward as an OS.

Let's see something... Mix-Rennes312-3-116.w80-9.abo.wanadoo.fr.

You are the same guy who's been making bold comments about AROS in the other thread, now making these statements about AOS4 making it sound as if you knew anything more than we do about the AOS4 internals.

Now, if you DO know anything more than us, then you must either be one of the Hyperion guys or someone who works for them.

If you don't know anything more than us, then don't pretend you are.

Care to finally tell us who you are, Mr. Anonymous? I'd be interested to put a name on top of those "hilarious" posts about AROS and its legal status.
New CAM article on ExecSG : Comment 36 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 13:48 GMT
In reply to Comment 35 (Fabio Alemagna):
LOL

Pray do tell what the "bold claims" about AROS were? I need a laugh. :-)

AOS4? I base what I "know" on what I read from that article, on follow ups by the Friedens to comments
on forums etc.

Pleased you have learned how to use nslookup, dig and the like - traceroute is next.

What my name is, is my business not yours.

You are a one man comedy act Fabio, never change :-)
New CAM article on ExecSG : Comment 37 of 71ANN.lu
Posted by Fabio Alemagna on 10-Sep-2003 14:02 GMT
In reply to Comment 36 (Anonymous):
> LOL
>
> Pray do tell what the "bold claims" about AROS were? I need a laugh. :-)

Memory shortage or what?


> AOS4? I base what I "know" on what I read from that article, on follow ups by
> the Friedens to comments on forums etc.

So does everyone else, and your claims are not backed up by anything written there. Is it transitional? So why bother with it at all in the first place, for instance?

> Pleased you have learned how to use nslookup, dig and the like - traceroute is
> next.

I just wanted to make sure you were the one I thought you were. The numbers don't tell me much, words are much better to remember.

> What my name is, is my business not yours.

Being coward is also your business, of course, and evidenlty you have no problems with it. Yours is the choice, as always.
New CAM article on ExecSG : Comment 38 of 71ANN.lu
Posted by Xisp on 10-Sep-2003 14:04 GMT
In reply to Comment 34 (Anonymous):
Posted by Anonymous (62.225.244.196) on 10-Sep-2003 15:08:44
In Reply to Comment 30:
I have used your product while you were touring, and to be honest - and I am really sorry about this - it was slow and sluggish.
---
This really bothers me a lot: They say "I'm sorry but..." when they
clearly are NOT sorry about it in any way.

I thought AOS4 tour version was PPC native in a minimal part and the rest
of it had to be emulated thru interpretive 68k emulation, hence the
slow performance.

But well, :) I suppose it doesn`t matter, it is too late to try to
convince people to have patience or being a little more objective, those
values were totally lost between the 2001-2002 era.
New CAM article on ExecSG : Comment 39 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 14:27 GMT
In reply to Comment 37 (Fabio Alemagna):
Memory loss? No. I just do not recognise "bold claims" as a description of them. If
I originated them without the context of Amiga Incs motives I might conceed that they were "bold".

I take that as an invitation to repeat them and drag it onto this thread.

I merely speculated on a motive for why Fabio gets in a tizzy over the
thought that Amiga Inc might pull through and therefore is not prepared to
countenance the remotest possibility that they would. One looks then at
his vested interests:

- Amiga Inc has not yet made a clear statement that AROS is free and clear from legal
action. This bothers Fabio considerably. Source: Total Amiga Magazine article.

- Amiga Inc clearly still believes that MorphOS infringes on its rights in some way allegedly because
of some links between key developers and AOS3.x source code. Direct link? Not really. See next
point.

- If Amiga Inc believes this about MorphOS, then it certainly is not going to be too keen
on the code submissions made back by MorphOS team members to AROS. Back to Fabio.

Finally, and I note that before you burst a blood vessel over this, it was mentioned
that MorphOS had scrubbed clean its code to avoid any resemblance with AOS3.1. How would one
do this without the AOS3.1 sources?

Do you think calling me a "coward" will bother me in the slightest?

No. But please carry on solidifying my view that your passion only exists on this issue because
of your threatened interests.

You are a one man comedy act, you certainly give me a laugh :-)
New CAM article on ExecSG : Comment 40 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 14:30 GMT
In reply to Comment 39 (Anonymous):
Heres the link that makes me ask about stuff being scrubbed clean:

http://www.ann.lu/comments2.cgi?show=1063179998&category=forum&number=40#comment
New CAM article on ExecSG : Comment 41 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 14:30 GMT
In reply to Comment 36 (Anonymous):
"What my name is, is my business not yours.
"

So you are Mr Covard who is hiding behind the Anonymous-nick ? :)
New CAM article on ExecSG : Comment 42 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 14:37 GMT
In reply to Comment 41 (Anonymous):
If you say so :-)
New CAM article on ExecSG : Comment 43 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 14:44 GMT
Fabio

Go read AmigaWorld.net for the source of "transitional"
New CAM article on ExecSG : Comment 44 of 71ANN.lu
Posted by Don Cox on 10-Sep-2003 14:44 GMT
In reply to Comment 21 (Joe "Floid" Kanowitz):
"(Let it be said that I've got no legacyware myself, and so personally care more about a stable, MP OS with all the 'simplicity'/'usability'/'modularity' trimmings I've been missing than one that has the dubious utility of running existing software really, really fast. But hey, if those three things are there, I'll trade off a *little* stability until such time as it can be put into place, and if that's what it takes to give me a browser and IRC client out of the box... well, then maybe I do have to care about 'legacyware.')"

Different viewpoints. Some of us really want a machine to run existing programs as fast as possible, with plenty of RAM (in other words, an A4000T on steroids), even if it crashes now and then.

Others want a computer with all the latest features, even if it has no software.

Maybe Hyperion can satisfy both parties. They do seem to be trying hard.
New CAM article on ExecSG : Comment 45 of 71ANN.lu
Posted by dammy on 10-Sep-2003 14:54 GMT
In reply to Comment 39 (Anonymous):
> Amiga Inc has not yet made a clear statement that AROS is free and clear from
> legalaction. This bothers Fabio considerably. Source: Total Amiga Magazine
> article.

Nice FUD. Unfortunetly for those of us who actually read on what's going on, would know that Amiga Inc has zero IP claims. How can I say that? Because if there was any (the only issue is now void with mouse click patent has now expired) IP violations it would be with Amiga LLC, and not Amiga Inc.

Now go back and code OS4, you apparently have a deadline to reach.

Dammy
New CAM article on ExecSG : Comment 46 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 15:01 GMT
In reply to Comment 45 (dammy):
No Damocles, it is the truth. They have made no such statement.

If you go and read the thread that Fabio is moaning about you would see that
I point out it is up to Amiga Inc to take anything to court and see if those
claims stand up.

Nice try and diversion tactics.

I have no deadlines - what are you talking about? Surely I am just an anonymizer proxy for Ray Akey?
New CAM article on ExecSG : Comment 47 of 71ANN.lu
Posted by Pete on 10-Sep-2003 16:13 GMT
In reply to Comment 39 (Anonymous):
-> Anonymous idiot #39

" Finally, and I note that before you burst a blood vessel over this, it was mentioned
that MorphOS had scrubbed clean its code to avoid any resemblance with AOS3.1. How would one
do this without the AOS3.1 sources? "

Use your brain for one sec. It's easy to avoid any resemblance with AOS 3.1 for an AmigishOS. You just replace any trademark name by new ones: example: replace Amiga by something else (ex: Amogi), Workbench by Powerdesk...etc This remove all the resemblance as they are the only ones that can be considering they don't have the AOS 3.1 sources :)
New CAM article on ExecSG : Comment 48 of 71ANN.lu
Posted by Anonymous on 10-Sep-2003 16:30 GMT
In reply to Comment 34 (Anonymous):
this'll be the recent on tour stuff...where the systems had only just P ExecSG kernel booting..and all the other stuff was still in 68k and only using the interprestive (read slow) 68k emulation?

thought so.

you should try the newer stuff.
New CAM article on ExecSG : Comment 49 of 71ANN.lu
Posted by dammy on 10-Sep-2003 16:35 GMT
In reply to Comment 46 (Anonymous):
> No Damocles, it is the truth. They have made no such statement.

No statements are needed, do a patent search and you will it goes to Amiga LLC and not Amiga Inc.

> If you go and read the thread that Fabio is moaning about you would see that
> I point out it is up to Amiga Inc to take anything to court and see if those
> claims stand up.

It's not their IP. They may have licensed it from Amiga LLC, but they (Amiga Inc) do not own it. If anyone is going to take court, it would be GateWay/Amiga LLC since ownership would be in question and that is their vital interest to protect their rights reguarding all patents they currently own.

> Nice try and diversion tactics.

That's DaveP's job, not mine.

> I have no deadlines - what are you talking about? Surely I am just an
> anonymizer proxy for Ray Akey?

No, I wouldn't insult the man by thinking that. I orginally thought you were some OS4 Dev wanker, but I think I was wrong, your just a gutless FUDmeister.

Dammy
New CAM article on ExecSG : Comment 50 of 71ANN.lu
Posted by Nicolas Sallin on 10-Sep-2003 16:47 GMT
In reply to Comment 39 (Anonymous):
>- Amiga Inc clearly still believes that MorphOS infringes on its rights in some way allegedly because
>of some links between key developers and AOS3.x source code. Direct link? Not really. See next
>point.

AmigaInc also believe it's possible to add memory protection in Intent and to port MorphOS's ABox over WarpUP to make AmigaOS4.0
Right...

>Finally, and I note that before you burst a blood vessel over this, it was mentioned
>that MorphOS had scrubbed clean its code to avoid any resemblance with AOS3.1. How would one
>do this without the AOS3.1 sources?

And because it was mentioned by some stupid guy on ANN, you want to believe in it and continue spreading it several years later ?

Tu ne changera jamais :(
Anonymous, there are 71 items in your selection [1 - 50] [51 - 71]
Back to Top