Oz Needs To Get Better...

[ironstorm]

With little fanfare, last night I somewhat grudgingly flashed over my Zaurus' OZ 3.5.3 w/ the new Qtopia ROM.

I've used OZ since version 3.2 was released. And while it has always seemed better then the Sharp ROM, it has also always seemingly been plagued by release quality problems from an end user perspective (perhaps evidenced by the lack of “stable” release for approaching 2 yrs). More recently with the crippling APM problem, OZ has become almost unbearable as PDA OS.

Perhaps some of the issues surrounding OZ can attributed to a lack articulated requirements for what a PDA should be able to do...   Here, as a single user, is my opinion of what is needed in a PDA OS...

A PDA OS should:

• Include a notepad
• Include a calculator
• Include a clock and be able to keep time (there are something like 25 major time zones in the world, those 25 should be included)
• Have working power management, so the PDA sleeps when it should and wakes for alarms and can advise users when it needs to be charged
• Include an address book
• Include a todo list
• Include a calendar/appointment book (obliviously this depends on time keeping and power management)
• The ability to sync PIM data to desktop or back it up to removal media or both

All of the things listed above should work as soon as the device is finished being flashed.  If they don't the OS should not be released; stable, unstable, or otherwise until the offending software is rolled back to a working state again.

The gravy stuff that would be nice to have available either on the ROM or as upgrades (but not necessary for a release) includes:

• An audio player for MP3s and OGGs
• An email client
• A web browser
• A movie / video player

Typically, the response I've seen in the past is that more developers are needed to make this stuff happen... And they most certainly are needed, but the bar for entry has been and still remains too high in my opinion.

I myself have made a few attempts to lower this bar for both myself and others in the community wishing to have a go at building OZ by cobbling together preconfigured OZ build environments (both in the days of the OpieSDK and more recently w/ BitBake under QEMU) and though I still feel this (or something like a Knoppix CD based build env) would be the best ways to introduce and catalyze interest in the OZ development process, I’m beginning to wane on whether they are doable in a practical sense.

I want to use OZ, I really do…  But it needs to get better…  I welcome comments...

Cheers,

-Ironstorm

[adf]

I have a 6000. be fore I had a 5600.niether were OZ "stars" like the 5500 seems to be.  I've setup and used OE a few times, flashed every version (hardware appropriate) of every release and never kept it on more than afew days.  I see  it as something to tinker with, and possibly something with a real future ( a largely device agnostic common handheld os could be pretty impressive--and very useful). But you are right... 3.5.3 had some improvements, worthwhile new features (and some steps backward), but it wasn't really what I had hoped it would be.  In their defence, they did say "unstable"--and they apparently meant it.  tinkering a little here and there with is proabably worthwhile, though. What you said about contributing goes for most of us... I think we should continue to tinker every now and then

[Mickeyl]

Full ACK to ironstorm. OZ needs to get better, but - without every sense of pun, really - it looks like the majority of people is doing what seems to be unfortunately natural to mankind - which is going the way of least resistance.

That means instead of perhaps painfully trying to really dive into a problem to come up with a concise reason of why there is a problem and lateron with a clear fix, most people seem to be more interested in shifting arbitrary binaries around in jffs2 image file systems

I admit that it's harder to improve OZ than to improve e.g. a SharpROM clone, because there's more general knowledge needed. However, the reward you get is also much much more high - you learn new things and you fix a problem in a structured way that is based on thinking and solving problems - is that cool or what?

I know that for many people this also is a time problem - but then again, how much time do people waste by blindly trying out certain workarounds and stuff?

Ok, that said, a major problem of OZ is that since it now really supports many devices - all being kind of similar, but the devil lays in the details - we really need many more people helping us, so I welcome every effort to attract more developers. For instance on C7x0, we changed a whole kernel and that has many effects to all subsystems, so it's clear that this needs time to work things out. More people can reduce that time.

One last word of "warning" though (just kidding here, but not completely), the OpenZaurus team has this old-fashioned kind of sense to solve things "the right way", that is we are not always looking for the quick solutions, but instead of the technically "right" solution, because we believe that we only have a chance to make this a system for the present and for the future, if we don't botch things together. With over 4000 packages you need to do that or you are in maintenance hell. We already are in maintenance hell because we have just about 10 people taking care of those 4000 packages.

Ok, enough soapbox. OZ needs to get better, BitBake and OpenEmbedded makes improving OZ so simple it never was before. We even cut BitBake's memory requirements from 1.5 GigaBytes to 128MB lately - is that a word?

Now join us, crack wicked problems like apm, polish our multimedia and networking apps, ..., and let's improve the system we believe in - OpenZaurus.

[koen]

One last word of "warning" though (just kidding here, but not completely), the OpenZaurus team has this old-fashioned kind of sense to solve things "the right way", that is we are not always looking for the quick solutions, but instead of the technically "right" solution, because we believe that we only have a chance to make this a system for the present and for the future, if we don't botch things together. With over 4000 packages you need to do that or you are in maintenance hell. We already are in maintenance hell because we have just about 10 people taking care of those 4000 packages.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Not to mention that same 10 people have to support  (N_machines * N_images) with all sorts of different kernels (2.4 + 2.6 on clamshells and ipaqs) for multiple distros.
At the moment we are doing a lot of buildsystem cleanups, which don't really affect the outcome, but help in keeping it clean and maintainable.
Long story short: Please document your problems, preferably using [a href=\"http://bugs.openembedded.org]http://bugs.openembedded.org[/url] and/or the appropriate mailinglists. Keep in mind that not all devs read forums, but do look at bugzilla.

As a side note: most developers (like me) aren't the typical user and are intimately familiar with the system and therefore overlook simple bugs when they solve (runtime) them without thinking.

[adf]

on the whole, you are quite right.
in particular--Qtopia2.1 and pdaXrom aren't really sharprom clones- repartitioning a stupid partition setup is probably worth the effort.

The path of least resistance is often the correct path. Ex: I would much rather drive my car than carry it. Coincidentally, this is the more effective of the two transportation options in the example. A more difficult solution requires a tangible payoff, and some indication of possibility for most people to be interested.  I think that there is a discouraged community of non-developer hackers tweakers and users worried about possibility and payoff in OZ.

Take me and my 6k for example.  As you know, I am not a developer. I have the 6k to play with system stuff a little, and to actually use as a handheld.  The device has a limited life and a limited time as my sole handheld. If at some point it seems to me that there won't be an OZ useable on my 6k during its effective lifetime, then I am likely to become more interested in other projects, regardless of my high opinion of the OE concept, and my expectation that the project will succeed.  For me to, for example, learn enough about displays to rewrite the drivers for the 6k so they don't produce orange lines ( an example of the kind of help the OZ for my device needs) might take years--essentially most of the expected effective life of the device. by the time I figured it out, I'd be looking a nokia's next   gadget, or something and not interested in by-then outdated Z 6k technology.  So.. help of the kind needed for this device is relegated to some expert developers who might have other stuff to do, after all. Not a high prospect of payoff or possiblility for me there, would you say?

So what then are the realistic options?
 Use a working rom and tinker with OZ with the expectation that at some point the maturity of oe and the development of new devices will converge sufficiently that I will have a useable oz working well on a device that i can in some small way contribute to.

 Use a pretty-non-useable OZ and hate my Z, and eventually hate OE, and have as little to do with either as possible because the system is unuseable, or at least very painful and limited.

 Use a working rom and forget about OZ entirely.

Do you see other reasonable choices?

[ironstorm]

We even cut BitBake's memory requirements from 1.5 GigaBytes to 128MB lately - is that a word?

How recently?  Last Thursday when I last tried to do a build of OZ using the latest Bitbake, Bitbake ate through around 400MB of ram and 300MB of swap and 2GB of disk space before the kernel compile bombed (where DISTRO="openzaurus")...   (I'm sure the Disk I/O of swapping contributes to what is an already painful compile time under QEMU on Win32)

If this has changed in the past week, I should refresh the toolchain again and have another go...

[Mickeyl]

Do you see other reasonable choices?

Not really - and I understand the frustration, because I even share it.

The orange line bug on the 6K is unfortunately one of those rare but symptomatic bugs where someone with much time and/or motivation on his hands is necessary to fix this.

Me personally, I'm already devoting dozens of hours per week to open source - already too much - I can't do even more.

Things would be different if we had full or part time paid people working on bugs. OZ really would deserve it.

[dansawyer]

The glass is more then half full and filling more then it is leaking. However it still has a good bit to go. That said OZ/Opie is a volunteer project. My advice is to remember that.

This is a development system; it is 'unstable'. That means it is development quality. All comunications are best sent and best received with that view point.

Many thanks to all those who have helped make this possible.

Dan

[ironstorm]

The glass is more then half full and filling more then it is leaking. However it still has a good bit to go. That said OZ/Opie is a volunteer project. My advice is to remember that.

This is a development system; it is 'unstable'. That means it is development quality. All comunications are best sent and best received with that view point.

I think one of the reasons that the devs slave away at this is to produce a usable product, if not for end users, for themselves as users.

I was hoping we could get to the point where we could all agree on some baseline for what meets the critia for a successful release in the eyes of everyone.

Of the list of 8 things I outlined a PDA OS should do/have, the latest unstable OZ 3.5.3 has 2 or 3 of them straight away after being flashed (notepad, addressbook and maybe backup data/sync)... of the other 5-6 things having a calculator, calendar and time keeping can be made to work with some effort, but overall I don't regard it as a successful release.

As Mickyl would prefer to see, I'd rather spend my time fixing it in the build system (and if I can get a successful build of something to start with, that will help me start getting deeper on that) then watch every non-dev in the community duplicate their efforts struggling to try to fix those 5 or 6 things, or worse give up in frustration...

The Qtopia ROM I'm currently using (or even the original Sharp ROM), while being based on older (some would say obsolete) technologies and build tools actually nail all 8 on the list and some of the gravy list too, but show their age in other various ways (i.e. gcc2 based, shitty video playback performance) which make me think they are evoultionary dead ends...  But on the practical side they will have to do for now... (can live without alarms working only so long)

Anyway I think the comments from your post have been stated many times before, and mine likewise.

Cheers,

-Ironstorm

[offroadgeek]

As soon as I heard about the beta 3.5.3 for the 1000 I flashed to it.  I was so impressed with how oz has grown and improved over the years.  Even with the known bugs of 3.5.3 on a 1000 I was still completely happy with OZ/Opie overall.  My biggest complaint was the lack of bug-free browser.  Heck, I would easily settle for a browser that doesn't crash nearly every time I use it.  And it wasn't just konq/e, as I got opera 7.55 installed and working somewhat better than konq/e.  Still, I couldn't do my daily tasks to manage the oe forums, nor could I log onto simple sites like dice or monster to try and find a job (as much as I love being unemployed, I had to start looking  ).

That said, I know full well that konq/e and opera are not part of OZ/Opie.  But to me, what is a operating system, either for my zaurus, desktop, whatever without a functional browser?

To me it's not just OZ that needs working on, but we also need to solidify the functionality of some of the core apps offered.

[lpotter]

The Qtopia ROM I'm currently using (or even the original Sharp ROM), while being based on older (some would say obsolete) technologies and build tools actually nail all 8 on the list and some of the gravy list too, but show their age in other various ways (i.e. gcc2 based, shitty video playback performance) which make me think they are evoultionary dead ends...  But on the practical side they will have to do for now... (can live without alarms working only so long)

-Ironstorm
[div align=\"right\"][a href=\"index.php?act=findpost&pid=81708\"][{POST_SNAPBACK}][/a][/div]

I think people use the term "obsolete" too easily these days. Buildroot is not obsolete because it still works perfectly fine. Neither is gcc2.
We use gcc 2 for compatibility with all the applications built for Sharp.

The Video playback performance has practically nothing to do with these things.

Using buildroot instead of bitbake/oe does not make necessarily make a better rootfs.


and about your alarms not working.. which device are you using?

[ironstorm]

We use gcc 2 for compatibility with all the applications built for Sharp.
The Video playback performance has practically nothing to do with these things.

There is nothing wrong with using GCC2 in itself, I thought the reason OE/OZ moved to GCC3 was to get better performance out of Arm processor...  My experince has been very limited with Video, but the 1 file I played on OZ3.3.6, OZ3.5 [both GCC3] and Qtopia [GCC2] was the IBM linux commercial (~9MB), it was quite watchable on OZ and choppy/skippy on Qtopia...  

The main thing that makes me think GCC2 is going to become limiting is most libary files I expect will eventually move towards GCC4 (in Debian Arm or whichever distro we derive source from)...  that could eventually lead to either a lot of work to maintain GCC2 support or leave us with old libraries that don't support new formats, or new optimizations...  might not happen though.

and about your alarms not working.. which device are you using?

Sorry I meant that as the reason I switched to Qtopia, to get my alarms/apm working again...  It's a nice ROM btw...
 
-Ironstorm

[adf]

So, really what OE needs is serious sponsorshp w/ the $$$ to buy some talent here and there.
I would tend to think Novell would be your best bet for a dev grant...after them, redhat.    We can try to raise money here, but it won't be enough, I'm afraid.  I am impressed with what has been done so far...but mostly in a "holy crap that's alot of stuff to keep track of" theoretical sense

on a lighter note, when are you swtching to git?

[lpotter]

There is nothing wrong with using GCC2 in itself, I thought the reason OE/OZ moved to GCC3 was to get better performance out of Arm processor...  My experince has been very limited with Video, but the 1 file I played on OZ3.3.6, OZ3.5 [both GCC3] and Qtopia [GCC2] was the IBM linux commercial (~9MB), it was quite watchable on OZ and choppy/skippy on Qtopia... 
-Ironstorm
[div align=\"right\"][a href=\"index.php?act=findpost&pid=81721\"][{POST_SNAPBACK}][/a][/div]

These use different backends.
Mediaplayer from qtopia 1.7 works just fine. There have been problems with the one from 2.1 unfortunetly.

WIll see about adding the old mediaplayer to the feed over there.

[Zismylaptop]

Thank you for your thread, Ironman.

I, too, gave up on 3.5.3 last night, and felt the need for a "Dear John" letter. This thoughtful thread is perfect.

As you can tell from my member name, I have a slightly different take on my Z than most people. I am a train commuter, so Zaurus provides a perfect opportunity to carry significant computer power in a far less oppressive package than a laptop provides. I have actually traveled overseas with only my Z even though I was there as a trouble-shooting developer for Win32 software!

I will see what I can do to help the crunch of developers that Mickey laments, I will make sure that the things I found are somehow in Bugzilla, and I will wait hopefully for 3.5.3's successor.

Zismylaptop