Current pace of AROS' development can be perceived on www.ohloh.net/p/aros. Though as can be seen here, the Russian developer Pavel "Sonic" Fedin is alone responsible for more than 3400 commits in eleven years, while the other four most important AROS contributors are inactive or almost since five years (apart of Georg Steger who was still active one year ago)... One can then see how much Pavel is important in current AROS evolution.
Can you tell us about you? Family? Non-computers hobbies? Work? What is the place of AROS in all that?
I'm 32 and I have a wife. I like everything technical. My first interest from the early childhood was electrics and electronics. I have engineer degree (it's complete russian 5-years high education, between bachelor and master), in electronics design. However I work as a software developer, because there's actually no hardware design in Russia.
Could you tell us about your motivations when you bought your first Amiga? And why such a machine in 1999: wasn't it more out-of-date than "alternative"? And why to search for "alternative" in the first place?
I always liked alternative things. Don't know why. Perhaps because i like knowledge, and I like investigating. It's neither interesting nor exciting to deal with Windows PCs, because they are dedicated to trivial tasks like office word processing and Internet browsing.
And what led you to the Pegasos II and MorphOS?
Wish to upgrade.
I guess some MorphOS users would like to know if your BootX project of a bootstrap for Mac OS X on Pegasos reached an usable state?
And have you had the opportunity to improve your Fireworks stack (FireWire)?
No. Since PowerPC architecture actually ceased development, I lost interest. I still keep my Pegasos just because I feel sorry to drop it. FireWire is also dead by itself, superseded by USB. And I have no hardware. I had DV camera donated for the project, but it failed, and I was never able to repair it.
And AROS: how did it got your interest?
When I first leaned about AROS, I liked the idea. First, I had a possibility to run Amiga-compatible OS on both machines (I had a Pentium I PC built from srap parts back then, to run MS Office). Second, I had m68k Mac laptop, and it seemed a nice idea to have a portable Amiga system.
We owe you the ability to drag overlapping screens, like allowed on original Amiga. Can you describe how you implemented it?
Of course. I added ShowViewPorts method to graphics driver, which gets a singly-linked list of bitmaps. This list reprsents z-ordered bitmaps to display.
A bitmap also has XOffset and YOffset attributes, which a driver-side representation of ViewPort offsets. It's up to the driver to handle all this.
A software implementation is a graphics.library plug-in. It intercepts three points:
Do you plan to continue to improve the graphics/intuition parts in the future?
Yes. No time for now, but there are plans. For example I want to implement a framework for building a mirrored display driver.
If I understood correctly, the dragging ability is allowed by the use of a sort of a "master" bitmap in front of all...
It's not in front. It's just the only bitmap. Display drivers that don't support hardware composition, have only one bitmap on display.
...in which real screen bitmaps are composited at the position the user want them to be. If so, could this "master" bitmap be used to render some sort of "super-windows" that would have a similar behaviour like DashBoard widgets on Mac OS X: they would always be in front of whatever screen is currently shown?
It could, but:
Yes, there could. One can try to expand the composition plug-in into subsystem allowing different representations.
Could the screens be rendered in real time?
They are rendered in real time.
Have you though about the requirements of implementing real transparency abilities on windows-level (layers?), like what MorphOS and AmigaOS 4 both already allow?
I thought about this. However I lack time and knowledge. I have never been an artist, so graphics (including programming it) is completely alien to me. I very poorly understand GL.
You have done an huge work on merging various i386 kernel codes and they are now almost on par (and in fact improving) with Sam's kernel, which is state-of-the-art of Michal Schulz's works. What will be the benefits of this work?
The main of benefits is reduced difference between kernels, and high percent of code reuse. This means that every change is well tested, since it's emerged into all platforms. Like new alerts and stack backtrace.
You have proposed for the ACPI-phase 1 bounty. What are the expected benefits for AROS on supported platforms?
Phase 1 is a small step towards all this, however, ACPI lets to:
Yes it could. First of all it could be extended with exec-alike library which would allow to run dedicated tasks on secondary CPU cores (PowerUP-alike approach). This is much easier to implement than full SMP (because the new library is legacy-free), but still useful (for example video players and coders could support this).
I know you have thought about memory protection too... Can you talk about it?
Yes, I can.
Exec pools are already MP-ready. They are rewritten to use chunks of fixed size. There's no more 'thresh size', and puddle size is always a multiple of CPU page size. If some large block is allocated (larger than puddle size), an enlarged puddle is allocated. This is still a puddle, so its tail is reused for small allocations. This allows to use pools to break up memory pages (obtained from kernel's allocator) into variable-length blocks.
AllocMem() with memory protection active is supposed to be just AllocPooled() from system default pool.
Kernel's allocator exists in draft version and is not used yet. I have no time to test it well. Additionally, with current default pool implementation AllocMem() would be slow, because the pool would be mixed. The same pool would contain chunks with different flags. Pool manager supports this, but it will be slow. I am thinking on how to improve it.
What did I forget? ;-)
What would you like to add?
Don't know, really. I lack time and phantasy...
You have often improved AROS with parts closely inspired from MorphOS inners. What are your relations with MorphOS devs? What parts of its code have you seen, and if so how come you have seen it?
I have no relations with MorphOS devteam. And have seen only public (or leaked) code. If you remember, there was some code leak as a result of internal conflict in MorphOS team. I released some unofficial MorphOS updates back then, based on leaked sources.
Mingw32-hosted is a lot more usable than it was in early times, but it still often swallows some characters typed on the keyboard, and it still (very rarely though) hangs randomly. Will you be able to come back to it?
Yes, I will. Don't know when, but I want to. In fact I am using this version myself, to install newly built files to my laptop's native AROS partitions.
I already know what to do with keypresses. I also sometimes experience freezes, but haven't found origin yet.
Could you briefly explain how one can build AROS on Windows?
The same as on any other platform. "configure" then "make". MinGW is needed.
Now that AROS runs on ARM portable devices thanks to your (and Michal's) amazing work, is it easy for devs to port applications on those systems? Is there one single sort of ARM executables, as there is a single sort of i386 executables running on all flavours?
Yes, there is a single sort of ARM executables.:) ARMv6 CPU, VFP FPU, softfloat ABI. Other flavors are proposed (like ARMv7 + Neon hardfloat), but currently this is not in production.
Android port seems to be close to a very usable stage. What about IOS port?
iOS is a very restrictive system. For example it's impossible to allocate a memory with read-write-execute access. It can be either read-execute or read-write. This way, memory protection support is mandatory for AROS to work on iOS.
I came back to this port now, and implementation of display driver is in progress. I test it on simulator, which uses i386 architecture and is free from memory restrictions. When I'm done with this, i'll complete memory protection.