And sorry for disappointing many of You during this year. Some of you hoped this year I will do something nice for them. And I failed many times. I would really like to tell you that I’m really sorry about that. I feel really bad about it.

Stephen, I feel really sorry that I failed and didn’t gave you the promised enchantments to AROS. I do know you were really disappointed with (lacking) results of my work even if you never said that. Thanks for everything you did to AROS.

ACube, I feel really sorry that I cannot give you any good news about progress I made. There is no progress. I’m sorry but work and real life are eating all the spare time I could have for you.

Nikos, I feel awfully that I cannot give you the X-mas gift – overlay for intel GMA. I really wanted to but, once again, I failed. I failed. Forgive me. Keep good work on supporting AROS.

sorry guys…

AROS on ARM cpu’s gives the user really good experience of small, fast and lightweight operating system. It’s so much different from regular linux distributions! All programs start within a second or less, the graphical user interface is very responsive. If only we had more apps…

This is exactly the place, where BroadwayX (I would prefer it to be Broadway MX ) helps. Here, with help of tiny lx command, it is possible to launch linux-side applications directly from AROS environment. Because of that, you can use AROS on EfikaMX all the time. If you lack any application, just launch linux one. I must admit I haven’t tested that distribution personally yet, but I will do that as soon as possible

Another exciting news related to AROS on EfikaMX, is the OpenGL for AROS hosted bounty. Once finished, AROS hosted distribution will get hardware accelerated 3D support. Another milestone towards better AROS!

Cube 2 on AROS hosted

There was a great piece of software developed many many years ago. I remember using it with Debian linux somewhere around 10 years ago. The software was available for free, but the source code was closed and maintained only by the company itself. Of course it changes. Some day the sources were freed and we all welcomed a great piece of office software for everyone. Free, of course, both as a beer and as a freedom. Years later the software got better and better and, some day, it forked. The new product was born, named LibreOffice. It was supposed to be better, well developed and ah oh, all the bells and whistles onboard. Many news portals, including one in Polish language which I read frequently, did spread some disinformation. The one I disliked mostly was naming a great improvement of LibreOffice Impress – the Presenter Console. Sure, it comes with LibreOffice for free. Of course, it’s great and using it makes really fun. The only problem is, it’s not an improvement of LibreOffice itself, rather a “PresenterConsole” extension from Oracle.

I don’t care forking that much, really. What I hate though is lack of freedom. Freedom of a choice. Most distribution maintainers were so excited by the new office suite fork, that they decided to obsolete original openoffice and removed it from repositories. Now, that’s bad.

I had to make an A0 sized poster for the next conference I’m attending in 10 days. LibreOffice Draw was my choice of suitable software, since I did posters with OpenOffice Draw previously. It was pretty unstable as I was working on the document. I mean it crashed every 10-15 minutes. Sometimes I was triggering the crash just by trying to change the bullet symbol, sometimes by trying to change the font size. I’m absolutely sure the problem is not hardware related, since that one was intensively tested already. What really shocked me though, was it’s inability to print into postscript file. All it happened was memory usage growing up drastically. LibreOffice never printed the document, since kenel’s OOM killer was in action. Every time. A day at work, a nightmare with free software…

Sure, I investigated the issue a bit. It turned out, LibreOffice attempted to convert the A0 page at 1200dpi resolution to bitmap first, before converting it to postscript and sending to the printer. Why? I dunno. Really. I had to redo the entire work on my poster in new document, which (oh, miracle!) was printed as a postscript without any issue. That reminded me old IT jokes about one huge company, saying

“Maybe if we turned the car off and on again, it would fix itself.”

I’ve never thought it would fit so perfectly to free software…

I want to have the freedom of choice. I want my OpenOffice back on openSUSE 11.4…

Two weeks ago Raquel and Bill announced price drop for EfikaMX nettop and smartbook. The prices in the store have been updated already, and the Genesi store for EU citizens is open. A nice gift for all of us living on this side of The Pond. These nice machines attract interest of many people of our small community and so, some of You asked me about the status of AROS for ARM machines, especially AROS for EfikaMX. So, here it is:

AROS hosted on linux

Here, the nightly build of core package is available on AROS website for download. This linux-arm-system build is done automatically every night. Therefore, there is no guarantee that it will work out of the box, nor that it will give you all the bells and whistles you know from the very great Icaros distribution. If the binary doesn’t work, try to download it again in one or few days. Nevertheless, most of the builds are working. Even better — this build benefits from the improvements of other AROS ports, like the AROS m68k one, so it “improves” each day. In some near future I will add to this build some of our contrib packaged. OWB, maybe?

AROS native for EfikaMX

The native port of AROS for EfikaMX is still on the schedule. I will take care of it as soon as I find the time. Right now I’m involved in few other projects and, therefore, native AROS for this ARM has to wait. Don’t worry — it will be available.

Future of AROS for ARM

What the future of AROS for ARM will be? Well, it’s not only in my hands — it depends on all of you. AROS never was a one-man project, and was always dependent on the community. Many years ago the community was very weak and AROS was hardly noticeable outside our development mailing list. Nowadays, the community grew and so grows AROS. We had x86 nightly builds only, now we have two great distributions and some commercial software. The same applies for ARM target — whether it will grow or not, is up to You.

Once upon a time I have promised to some of AROS enthusiasts improvements on the x86 kernel, among others support for modularized kernel. It seemed, we have got rid of the nice feature of Amiga-like operating systems — the strong separation of all essential components of the system in libraries, devices and resources. That’s how original kickstart was made, it was a bunch of different modules put together on one read only memory. Which components were there, that was unknown for AmigaOS unless it scanned entire ROM for resident modules. We did the same in AROS kernel, at least for native targets, but we also linked all modules together, into one single executable. How silly!

Sure, such approach has it’s own advantages. Some static libraries (like librom.a) could be reused by all modules and thus saved some space. However, we do link all of it into one big file — think about any potential licensing issues. Not only that, big statically linked kernel means, there was no way to replace one module with a new version, no way to add module of your own. Do you all need ability to boot from USB media? No? Pity you, all the necessary classes are there anyway. Does any of you ever thought about GUI-less core components of operating system, used for some imagined device? Well, compile and link all of it yourself, have trouble and solve it all alone. The modular kernel opens many opportunities, limited only by our imagination.

So, the promise was given, years passed and nothing happened. Until now. In some spare time between my real life, activities at the university and work on Aura, I’ve added the support for loadable modules to native x86 AROS target. There’s still the large kernel to see, but it’s a matter of writting new GRUB config file (which I didn’t had time). Feel free to test the nightly build, look at GRUB config file (to find a way how to add more modules) and be happy. And, of course, don’t forget visiting this site for some more news about Linux, Aura, AROS and others

Some of you might followed my old blog which died almost one year ago. As I was pretty busy with my private life, I lost motivation to update it. You know, it just happens

Now I seem to have energy and motivation again! There is a lot of to tell you about, quite many good and much less bad news. Let the new blogging powered by WordPress begin…

EDIT: I have successfuly imported all ancient posts and comments from blogspot. Now, the msaros.blogspot.com may rest in peace…

Yup, typical me I made some fuzz about things being currently done (or not done) and then disappeared for a while. No information, no updates. Nothing I’ve been asked several times about the status update of AROS for sam440. Well, there are few changes which have happened to the whole AROS recently. We do have a changeable mouse pointers and they do work on Sam440. Since there are few of them delivered on the ISO, you may change the red triangle to something more Amiga-like, if you want to. A red mouse pointer with alpha blending and shadow? No problem. Start preferences, select the correct image and voilà!

Markus Weiss managed to compile OWB for PPC target and, if it works as expected, you will find it on the next ISO. Neil Cafferkey made some important improvements to the installer. Now, it installation on sam440 shall be simpler. Keep in mind the installation will be incomplete, since the AROS’ slb (aka Parthenope) is not installed yet.

The changes local to Sam440 port include support for the onboard I²C bus. The RTC is used by the battclock.resource, so now you will see the correct time on AROS, provided your RTC is correctly set up. If not, you may use AROS’ time preferences to adjust it. Additionally, few fixes for the setjmp/longjmp are made, so that the functions do not crash in case of unaligned jmp_buf pointer. Anything else? Ah yes, I’m working on the EHCI Poseidon driver for Sam440 AROS. Stay tuned

Screenshot? Here you have it. Nothing special in it. Just AROS on Sam440 in a bit higher resolution
Greetings from the German Aerospace Center

Hi there!

Samantha is back! After long period of hibernation in the AROS repository Sam440 port of AROS is maintained again. Big thanks to Markus Weiss, who has restarted it and to ACube who gave me the kick in the butt

Since the kernel.resource in AROS did evolved a bit since last time I was writing it form Sam, it has been updated a tiny bit now. Most of the features from Efika’s kernel have been back-ported to Sam440 port, including:

• Loading and releasing of symbols from every ELF file loaded by AROS, including the kernel itself,
• System call for cold reboot (accessible only from kernel.resource and exec.library),
• Crash handler displays detailed information, including the byte offset of crash occurrence, relevant symbol name (if such name exists at all) and the executable name. The log includes also the backtrace (with offsets, symbol and module names) which tries to reach as far as possible.

Yes, I do know, it’s not much. But it is at least a good start (eerm…. rather a good re-birth?) .

The Sam440 port has been not only extended, but also fixed a bit. I have found there an ancient bug in the exception handler. It could have lead to random system crashes. The reason was the exception handler itself. There was a risk that an interrupt will occur during reconstruction of the CPU context.

Since the AMCC440EP CPU does not maintain cache coherency (no, it’s not a bug, it’s a feature fairly well documented in the manuals!), some portions of the code had to be fixed. Now, more AROS code uses CachePreDMA and CachePostDMA pair of functions. Because of that partitions on harddrive are recognised properly now. AROS on Sam440 boots nicely and coexists with OS4.1 on the same harddrive. Nice, isn’t it?

Now, the last but not least, after some sleepless nights the OHCI driver of Poseidon is fixed and operates properly on Sam440ep. Wanna proof? Watch the attached screenshot

Stay tuned for more news. I promise to write a bit more now