|
Roderick Klein (Mensys) рассказал в группе
eComStation yahoo groups
Коротко:
- Были упреки от некоторых пользователей, что проект в плохом
состоянии из-за неправильного менеджмента. На самом деле имеют место технические
проблемы.
- В какой-то момент Flash 10 был совсем недоступен,
т.к. были проблемы с лицензией. Теперь Flash 10 можно использовать в eCS.
- Разработчик, который занимался портированием предпринял все усилия.
Для запуска плейера используется библиотека Odin (производная от WINE для Linux).
Основная проблема Odin - нестабильная работа на многопроцессорных SMP компьютерах.
- Были вложены огромные усилия в изучение и отладку Odin.
- Текущий план: Сначала отладить библиотеку Odin
при портировании Java 6. Дальше опять вернуться к портированию Flash.
A lot of stuff is happening for eCS, we are working on. Stuff that
needs to be done to keep moving eCS forward!
As for Flash 10. Some people have commented the project got stranded
duo to bad project management.
I would like to point out why thats not the case. Its rather a
technical problem...
Working on Flash 10 was not possible first of all because at the time
Adobe had a very difficult license policy.
Getting a distribution license is now very easy.
When the Flash 10 project was started it was a stab in the dark how
long it would take. Simply because of the two following reasons.
- 1. Its certainly a benefit to have somebody that knows both Windows and
OS/2 as an operating system. Vladest who also worked
on UNIAUD audio driver started on the Flash 10.
- 2. ODIN code had not been worked at the time for over 4 years. The
source code comes for a large deal from WINE.
The Linux version of the ODIN project...
I can also say that Vladest at the time made a flying start in updating
ODIN to support Flash 10. He worked real hard to get it to work.
Thats where the estimate was made it would happen.
But what was already slightly known with ODIN, its stability on SMP
systems is lacking.
Thats what about 4 to 6 months ago kept the delay of getting a version
out the door from happening.
At the time internal builds where switched to the API kernel in the
kernel called "setthreadaffinity".
It basicly tells the CPU to run all code on ONE cpu core.
With Flash 10 it was also observed it was much more stable on a single
core CPU system.
This was again confirmed by Gerrit Schoenmaker who also works at
Mensys. The current build of Flash 10
works very well on his T42 (which has one CPU). He could use youtube
for over half an hour without crashing.
Debugging Flash 10 is more complicated then Java 6 that is currently
being worked on. Java 6 we have the source
code of as well. The Flash 10 plugin is a binary from Adobe.
The solution with setthreadaffinity was not used anymore. What
happened on my laptop is that my system would lock up solid with th
setthreadaffinity call used. Hours have been spent using the so called
kernel debugger. Steve Levine helped out a lot with this!
The Kernel debugger is a special version of the kernel that, used over
a serial cable, you can seem the assembly language
that the CPU is processing (oke a bit of a simple description).
With the normal kernel (none debug version) my laptop would lock up
solid. With the debug kernel if you just keep it run for 10 seconds
after the moment the debugger kicks in the system will reboot. This is
certainly not a daily scenario to happen.
A lot has een tried to back trace why the kernel comes into this
situation.
The defect is not related to UNIAUD, panorama, or ACPI. It seems to be
a defect in the SMP kernel that the ODIN code
can not be executed with tha API call setthreadaffinity. The hang also
occurs with OS2ACPI.PSD loaded.
Currently there is still being worked on Java 6 and SMP support:
http://svn.netlabs.org/java/ticket/44
Java 6 is near being completed, as far as I understand.
The same code will then be used to get Flash 10 working better.
| 
