25-Apr-2024 10:35 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 8 items in your selection
[News] mozAmiga updateANN.lu
Posted on 14-May-2001 12:17 GMT by Christian Kemp8 comments
View flat
View list
Budda noticed that the mozAmiga (mozAmiga is an effort to port Mozzila source code to the AmigaDE platform) website has been updated with the latest info. He adds: The project seems to be a bit of a lost cause, with little in the way of actual development so far IMO.
mozAmiga update : Comment 1 of 8ANN.lu
Posted by Kent Seaton on 13-May-2001 22:00 GMT
The MozAmiga development has more backing than one might think. If you are a developer, join the mailing list discussion to find out more information. Or, you could always contact James about it. I mean, this isn't some TacoBell Beanboy act where you add water to powder and magically you have beans. The development is indeed true. Where some of the other moz developers left off was to create their own GUI and then start to import other components of the code. The problem with that is if you port Gecko, you've ported everything, including the GUI, and before you can have a semi-working product Gecko must be ported over. Also, the development is for the DE, not the current AmigaOS. By the time the current AmigaOS has the full capabilities of the DE, there should be a fully functional Mozilla port that can be used.
mozAmiga update : Comment 2 of 8ANN.lu
Posted by Anonymous on 14-May-2001 22:00 GMT
You seem to suggest that AmigaDE has more features than AmigaOS... which features are these then?
mozAmiga update : Comment 3 of 8ANN.lu
Posted by XDelusion on 14-May-2001 22:00 GMT
Kool, more software!
Now I wonder is there ever going to be a new Amiga NG, and Amiga PPC section on Aminet....
mozAmiga update : Comment 4 of 8ANN.lu
Posted by Anonymous on 14-May-2001 22:00 GMT
If AmigaDE is based on the SDK, then most of the sorce code is in C,
This will make it easy to port it AmigaOS4.0, and ther is a lott of
companies thinking to support SDK, even M$.
SDK can be a sucess, as Jave is slow.
mozAmiga update : Comment 5 of 8ANN.lu
Posted by Anonymous on 15-May-2001 22:00 GMT
In reply to Comment 4 (Anonymous):
>This will make it easy to port it AmigaOS4.0, and ther is a lott of
>companies thinking to support SDK, even M$
Microsoft are writing software for AmigaDE? Are they porting Office 2000? or Internet Explorer?!
mozAmiga update : Comment 6 of 8ANN.lu
Posted by Kent Seaton on 16-May-2001 22:00 GMT
In reply to Comment 4 (Anonymous):
> as Jave is slow
Jave as in Java is not slow. It all depends on how you compile it and what you have compiled it for. The speed difference for a native Java application and a C Application is marginal at best. When you use an interpreter for decoding the Java files (Java Virtual Machine) is when Java becomes "slow". So, Java by itself is not slow, only the Virtual Machine is slow.
mozAmiga update : Comment 7 of 8ANN.lu
Posted by Anonymous on 16-May-2001 22:00 GMT
In reply to Comment 6 (Kent Seaton):
>So, Java by itself is not slow, only the Virtual Machine is slow.
Considering what a JVM does (essentially load an entire translated operating system in under a second), it is VERY fast indeed!
mozAmiga update : Comment 8 of 8ANN.lu
Posted by Anonymous on 17-May-2001 22:00 GMT
In reply to Comment 7 (Anonymous):
UHHH beg to differ. The JVM does not run an entire transplanted OS in under a second it is simply
a process based execution environment with an access layer to the real "machine" ( read OS ).
Once in that process it translates the opcodes in the .class file(s) much the same
way as a stack, heap & register based processor does.
JITs do up front translation of a *window* over the code ( e.g. one method, one class ) and allows
caching of the compiled code - if it is reused heavily. This is hard to analyse if
you are always flushing the pipeline by using conditionals.
So, JVMs are NOT fast, they are memory hogs because each executed application runs in its own JVM, you can
run two applications inside one JVM if you know what you are doing BUT most JVMs are written not to be used
in this manner and are bugged to hell. Thats why IBM wrote the Shiraz JVM for s390 to resolve that very issue ( well
there were quite a few other issues but that was a key one ).
When JVMs appear to be fast they are JIT enabled, which comes close to native compiled code
because it *IS* near native compiled code. It is still slowed down by the chronically slow
memory referencing code and the need to access runtime classes also written in Java ( depends on what
you do ).
So, in conclusion, JVMs IMHO are a bad kludge, they allowed people to do some stuff that was
cool at the time ( run UI based applications on any system ) but thats it. They were designed to
address NC style user based office computing.
All the work since then has been to work around those serious design flaws that prevent the JVM
from scaling efficiently.
Anonymous, there are 8 items in your selection
Back to Top