Opie And Qtopia - A New Hope ?

[guylhem]

Hello

My latest editorial is on http://externe.net/zaurus/modules.php?op=m...order=0&thold=0

It won't make me a lot of friends, but I think it's important to say that after what I've read and posted recently in Guylhem Rom forum.

Here is the introduction :

Opie and Qtopia are Qt based PDA user interfaces. Each use its own
distribution, respectively OpenEmbedded and
Embedix/Lineo/Montavista/whatever the flavour of the day is.

TrollTech release of Qtopia 2.1 and Qtopia 2.1 based Roms changed the game, and made the
duplication of functions more apparent. It becomes more and more clear that one of Opie or
Qtopia should be stopped. The big question is - which one ?

Let's give a quick answer and add details later on : Opie should be
dropped, and Embedix/Montavista/Lineo/whatever deserves the same fate.

Yet, as a free-software zealot which even once was on the FSF payroll, I'm
asking everyone to stop working on Opie and join the Qtopia bandwagon.

Am I going slightly mad?

[ryouga]

I'm new and all, and have no opinion either way (and won't comment on the "moral" aspects of Free software) , but I took a glance at this:

1.3
Gigs+5.8 Gigs=7.1 Gigs totals are required if you want to code with
OpenEmbedded,

and something didn't seem right, so I looked at your link.

7.1GB is the *entire* OE tree including all apps in it.   As he said it's ~200mb to get bitbake and use it which is much closer to your other estimate.

You just took numbers and threw them out there. Also your situation is not common (I think most people have a little more than 100mb free if they're developing software) so I don't think that argument stands well.

But hey, whatever you want to say...

[adf]

though to be fair..after building an image and an few apps you get pretty close to the whole tree via dependencies.  The weight of the thing is not my biggest concern, but I think this isn't a really unfair picture of what your basic curious hobbyist is going to get when checking out OE.

[amrein]

Hi,

* Do you feel that Trolltech is fighting to promote Qtopia?
* Do you see Qtopia/Linux as the next PDA desktop, replacing PocketPC and PalmOS?
* Do you see Trolltech as a PDA defender? A Linux PDA defender?
* Do you trust L.Potter, the Trolltech community interface when he tells you "Soon, keep waiting, stay turned"?
* You see a real interest in Qtopia developpement at present? You see a lot of compagnies jumping in the wagon and porting their software? You see a lot of people lost in OE forums, searching for developpement tools.
* The SDK is easy to use? Has a standard RAD tool promoted by TT? Is available on Linux+Windows+MacOS without hacking? Has easy and documented debug feature in-build?
* The number of open source projects arround Qtopia are increasing? Old ones are still evolving?
* A lot of device are choosing Qtopia/Linux for their next PDA interface?
* Do you see Trolltech fighting in PDA and in smartphone market or are they just waiting for PDA market to die out?
* Perfect compatibility between all Qtopia solutions? Easy upgrade process available? Easy package management? Easy package exchange between devices? Easy and smart buildsystem? Easy Qtopia translation? Great exchange between developpers? Software build for a device will run on another one without issue?
* Beautiful open source synchronisation tools? Easy connection and exchange between desktop?
...

The answers depends on how you see the wall Qtopia Trolltech market. If you see Qtopia as a great thing or a bad thing, this list with have different meanings. This will be your personal opinion. If you think you have to fight against those sentense, well...

Btw, are you sure that we should work on Qtopia 2.1? If so, what is your own positive points to convince us?

[eji]

I come to this discussion with absolutely no authority on the subject, as I've never developed an app in my life (except for a math program on my Commodore 128); but I find myself agreeing with guylhem's assertion that there appears to be a small pool of developers working on way too many large-scale ROM efforts, and as a consequence, small-scale application development is suffering. Exactly which ROM should take precedence is something that the developers should decide -- but one (as has been discussed many a time in these forums) should really be selected and app development concentrated on that.

This surfeit of ROMs and dearth of fully functional applications was and is my main beef with owning a Zaurus. Linux desktop environments are one thing because the pool of available developers is so much greater; Linux handhelds should really focus on one environment for now until the user base grows to a point where branching out won't harm it.

[lpotter]

Hello

My latest editorial is on http://externe.net/zaurus/modules.php?op=m...order=0&thold=0

It won't make me a lot of friends, but I think it's important to say that after what I've read and posted recently in Guylhem Rom forum.

Here is the introduction :

Opie and Qtopia are Qt based PDA user interfaces. Each use its own
distribution, respectively OpenEmbedded and
Embedix/Lineo/Montavista/whatever the flavour of the day is.

TrollTech release of Qtopia 2.1 and Qtopia 2.1 based Roms changed the game, and made the
duplication of functions more apparent. It becomes more and more clear that one of Opie or
Qtopia should be stopped. The big question is - which one ?

Let's give a quick answer and add details later on : Opie should be
dropped, and Embedix/Montavista/Lineo/whatever deserves the same fate.

Yet, as a free-software zealot which even once was on the FSF payroll, I'm
asking everyone to stop working on Opie and join the Qtopia bandwagon.

Am I going slightly mad?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80093\"][{POST_SNAPBACK}][/a][/div]

Nice commentary. A few things...

It's spelled "Trolltech", not TrollTech.

I don't think our 2.1 demo roms change anything. There is still room for Opie, and Qtopia, and any other Zaurus roms. Choice is good.

Montevista is _the_ standard distribution for Linux embedded devices. It isn't going away anytime soon.

We have many reasons why Qtopia Phone was not GPL'd, some of which are reasons I have said before.
Having a GSM card on your computer is very different from a mobile phone. For one, it is still a computer, NOT a highly regulated communication device. Phone operators are extremely secretive. As I have also said before, some of them do not even want 3rd party installable applications on their handsets. This is the way it is. Trolltech is not in the position to change this.
There is more to a phone besides AT commands and a dialer. Did you know most countries have a law where a mobile phone MUST be able to dial the emergency numbers at ANY time? If you would like to understand all this, please read the regulations in your area regarding mobile phone devices. I am sure they are extensive.

[Mickeyl]

Overall, it's a nice review. I even agree to a couple of points

Unfortunately, regarding OpenEmbedded it suffers from a major misconception - and I'm not yet sure if you do this on purpose to backup your reasoning or if you just didn't understand it yet.

I will explain it to you. The first line is important so read slowly and possibly write down somewhere:

OpenEmbedded is NOT an SDK.

This may be shocking for you, but it's the truth. OpenEmbedded is a metadata repository to build complete Linux distributions from scratch.

With this in mind, let's take another look at the size of OpenEmbedded, which happens to be

Code: [Select]

mickey@r2d2:/local/pkg/oe/packages$ du -h -s .
234M    .
So where do the 7 GigaBytes you always like to claim come from? They come from the build process. You have to understand how building
a Linux distribution works. I'm not going to tell you the details here, please refer to some good sites, i.e. Linux from scratch, or so.
All you need to know now is that it is fundamentally different from just building an application based on some libraries. For building a complete
distribution from source (like we do with OpenZaurus), you need you to have

 * the packed sources in your download directory,
 * the unpacked sources in your build directory,
 * the intermediate files created by the build process in your build directory,
 * the resulting host tools, libraries and header files in your staging area (necessary for building subsequent applications and libraries),
 * the resulting binaries prepared for the packaging process,
 * the packages in your deploy directory.

Guys, this is where the GigaBytes come from and OpenEmbedded as a build tool shared this inherent properties with all other tools in the same league on this planet. Note also that all the SharpROM cloners who work by moving binaries forth and back don't need such a tool because they build little - if anything - from source.

Now what you seemingly fail to understand is that this is a tool for people who build distributions, not for people who build applications. An application developer just needs an SDK which contains libraries and header files. This is a tiny fraction of the space needed by a distribution development environment. When I released OpenZaurus 3.5.3 I created an ad-hoc GPE and Opie SDK for people wanting to write applications. Lets  take a look at the size of it:

Code: [Select]

mickey@gandalf:/var/www/vanille.de/html/tools$ ls -l oz-3.5.3-adhoc-sdk.tar.bz2
-rw-r--r--  1 mickey abvs 73138074 Apr 12 12:18 oz-3.5.3-adhoc-sdk.tar.bz2
Oh look at that! It's tiny, yet containing all the things necessary for a software development kit (as opposed to a distribution development kit).

Hope this helps.

[Hrw]

@mickeyl:

I will explain it to you. The first line is important so read slowly and possibly write down somewhere:

OpenEmbedded is NOT an SDK.

This may be shocking for you, but it's the truth. OpenEmbedded is a metadata repository to build complete Linux distributions from scratch.

Good said.

@guylhem:

I read whole article on your site and will write what I think.

When you started work on your distro (I hate when people talk ROM about distros, ADF disk images etc) it was looking like something new. But it ended in YASC (Yet Another Sharp Clone).

If I need some functionality on my SL 6000 kernel, I'll do a quick and dirty fix, while waiting for a stable 2.6 kernel from OpenEmbeddex crew.

I sometimes wonder how Sharp 2.4 based kernel manages to compile - not even work altogether. It's so messy. But
at least, it works. I'm eagerly waiting for a 2.6 kernel, but when I decide I'll move to that kernel, you can guess I will have some weekends and a backup plan to make sure everything work as expected.

for me that sentence means "I wont help them - will wait for ready to use, tested version."

[lpotter]

* Do you feel that Trolltech is fighting to promote Qtopia?

Yes. Most of this is done behind the scenes, in corporate offices.

* Do you see Qtopia/Linux as the next PDA desktop, replacing PocketPC and PalmOS?

Yes.

* Do you see Trolltech as a PDA defender? A Linux PDA defender?

Of course. But PDA's are not the way of the future.

* Do you trust L.Potter, the Trolltech community interface when he tells you "Soon, keep waiting, stay
turned"?

And you think this was entirely _MY_ fault?

* You see a real interest in Qtopia developpement at present? You see a lot of compagnies jumping in the wagon and porting their software? You see a lot of people lost in OE forums, searching for developpement tools.

Try http://www.qtopia.net

* The SDK is easy to use? Has a standard RAD tool promoted by TT? Is available on Linux+Windows+MacOS without hacking? Has easy and documented debug feature in-build?

Yes, it takes some intelligence to set up a cross compiler on Linux.

* The number of open source projects arround Qtopia are increasing? Old ones are still evolving?

umm. ya.

* A lot of device are choosing Qtopia/Linux for their next PDA interface?

Nope. But lot's of companies are using Qtopia Phone. Of course, you wouldn't know anything about that, because these companies are secretive about there plans!

* Do you see Trolltech fighting in PDA and in smartphone market or are they just waiting for PDA market to die out?

Pda's are dying out. Smartphones are increasing. I don't make it that way, that's just the way reality is.

* Perfect compatibility between all Qtopia solutions? Easy upgrade process available? Easy package management? Easy package exchange between devices? Easy and smart buildsystem? Easy Qtopia translation? Great exchange between developpers? Software build for a device will run on another one without issue?

* Beautiful open source synchronisation tools? Easy connection and exchange between desktop?


...

The answers depends on how you see the wall Qtopia Trolltech market. If you see Qtopia as a great thing or a bad thing, this list with have different meanings. This will be your personal opinion. If you think you have to fight against those sentense, well...

Btw, are you sure that we should work on Qtopia 2.1? If so, what is your own positive points to convince us?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80134\"][{POST_SNAPBACK}][/a][/div]

Trolltech's customers are given the Qtopia sources, and they can change it to suit their needs.


Work on what inspires you.

[Mickeyl]

Work on what inspires you.

Amen to that. It's pretty disturbing to me that a lot of people look at the open source community as some kind of musical request programme.

Folks, grow up - it isn't like that. Open source is meant to be fun, hence developers work on what they like to. Remember -- it's the efforts of things done in our precious spare time which we share with our users. Many open source developers also code for a living and one part of your life where you have to obey orders on what to hack on is surely enough.

(Sorry, getting a bit offtopic)

[guylhem]

Mickeyl - that's fine, I totally agree with most of your points. However I must mention I personlly rebuilt everything I really need (mostly dropbear and usefull stuff - I won't care with more/less etc unless there's a new feature I really need) and I understand the problems with building a distributions. An ungly suite of configure.sh scripts running configure, make and everything is more that enough for my needs.

Here's what I use with bluez for example : (along with a minimal etc/ directory)

#!/bin/sh
# Copyright © 2005, Guylhem Aznar <zaurus-ipk@externe.net> : GPL
# Requires the toolchain from:
# http://www.externe.net/zaurus/sdk/Embedix.tgz

VERSION=2.17

cd /tmp
wget http://bluez.sourceforge.net/download/blue...;VERSION.tar.gz
wget http://bluez.sourceforge.net/download/blue...;VERSION.tar.gz
tar zxvf bluez-libs-$VERSION.tar.gz
tar zxvf bluez-utils-$VERSION.tar.gz

export CPPFLAGS=-I/opt/Embedix/tools/arm-linux/include/
export LDFLAGS=-L/opt/Embedix/tools/arm-linux/lib/
export PATH=/opt/Embedix/tools/bin/:$PATH
cd bluez-libs-$VERSION
./configure --prefix=/ --host=arm-linux
make
mkdir /tmp/bluez-zaurus
mkdir /tmp/bluez-zaurus/usr
mkdir /tmp/bluez-zaurus/usr/lib
mv src/.libs/libbluetooth.* /tmp/bluez-zaurus/usr/lib
cp -adr include/ /tmp/bluez-zaurus/usr/
rm /tmp/bluez-zaurus/usr/include/Makefil*
cd ../bluez-utils-$VERSION
mkdir /tmp/bluez-zaurus/usr/bin
mkdir /tmp/bluez-zaurus/usr/sbin
./configure --host=arm-linux --prefix=/ --with-bluez=/tmp/bluez-zaurus/usr/
make
cd tools
cp ciptool hcisecfilter hcitool l2ping ppporc sdptool /tmp/bluez-zaurus/usr/bin
cp hciattach hciconfig pskey /tmp/bluez-zaurus/usr/sbin
cd ..
cp dund/dund /tmp/bluez-zaurus/usr/bin
cp hcid/hcid /tmp/bluez-zaurus/usr/bin
cp hidd/hidd /tmp/bluez-zaurus/usr/bin
cp pand/pand /tmp/bluez-zaurus/usr/bin
cp rfcomm/rfcomm /tmp/bluez-zaurus/usr/bin
cp sdpd/sdpd /tmp/bluez-zaurus/usr/bin
cp test/hsplay test/hsmicro /tmp/bluez-zaurus/usr/bin
cd /tmp/bluez-zaurus
tar zcvf ../data.tar.gz ./
mkdir ../control
echo "Package: bluez-zaurus
Priority: optional
Version: $VERSION
Architecture: arm
Maintainer: Guylhem Aznar <zaurus-ipk@externe.net>
Depends: libc6
Description: BlueZ $VERSION bluetooth software for the Zaurus
Section: kernel" > control
echo "#!/bin/sh

rm /dev/rfcomm*

/etc/rc.d/init.d/pcmcia restart

/sbin/rmmod l2cap
/sbin/rmmod rfcomm
/sbin/rmmod bluez

exit 0" > postrm
echo "#!/bin/sh

/sbin/cardctl eject

/etc/rc.d/init.d/bluetooth stop

exit 0" > prerm
echo "#!/bin/sh

if [ -f /etc/modules.conf ]; then
   if [ \"`grep net-pf-31 /etc/modules.conf`\" = \"\"  ]; then
      echo \"alias net-pf-31    bluez\" >> /etc/modules.conf
   fi
   if [ \"`grep bt-proto-0 /etc/modules.conf`\" = \"\"  ]; then
      echo \"alias bt-proto-0   l2cap\" >> /etc/modules.conf
   fi
   if [ \"`grep bt-proto-2 /etc/modules.conf`\" = \"\"  ]; then
      echo \"alias bt-proto-2   sco\" >> /etc/modules.conf
   fi
   if [ \"`grep bt-proto-3 /etc/modules.conf`\" = \"\"  ]; then
      echo \"alias bt-proto-3   rfcomm\" >> /etc/modules.conf
   fi
   if [ \"`grep bt-proto-4 /etc/modules.conf`\" = \"\"  ]; then
      echo \"alias bt-proto-4   bnep\" >> /etc/modules.conf
   fi
   if [ \"`grep tty-ldisc-15 /etc/modules.conf`\" = \"\"  ]; then
      echo \"alias tty-ldisc-15 hci_uart\" >> /etc/modules.conf
   fi
   if [ \"`grep char-major-10-250 /etc/modules.conf`\" = \"\"  ]; then
      echo \"alias char-major-10-250 hci_vhci\" >> /etc/modules.conf
   fi
else
   echo \"alias net-pf-31    bluez\" > /etc/modules.conf
   echo \"alias bt-proto-0   l2cap\" >> /etc/modules.conf
   echo \"alias bt-proto-2   sco\" >> /etc/modules.conf
   echo \"alias bt-proto-3   rfcomm\" >> /etc/modules.conf
   echo \"alias bt-proto-4   bnep\" >> /etc/modules.conf
   echo \"alias tty-ldisc-15 hci_uart\" >> /etc/modules.conf
   echo \"alias char-major-10-250 hci_vhci\" >> /etc/modules.conf
fi

/usr/bin/make_dev.bluez.sh

/sbin/depmod -a

/etc/rc.d/init.d/bluetooth start

/etc/rc.d/init.d/pcmcia restart

/sbin/cardctl eject
/sbin/cardctl insert

exit 0">postinst

tar zcvf ../control.tar.gz ./

cd ..
echo 2.0 > debian-binary
tar zcvf bluez-$VERSION-zaurus.ipk ./debian-binary ./data.tar.gz ./control.tar.gz

There's only 1 thing I didn't know : oz-3.5.3-adhoc-sdk.tar.bz2. It should be more proheminently displayed and linked, it could save people lot of time and effort. That changes several points, but not the main conclusion :  OpenEmbedded (for building distros) should include qtopia 2.1 and gcc 2.95 support. Qtopia 2.1 should be the target of our efforts. Gcc 2.95 would make it easy for Trolltech (with a lowercase t :-) to build their Roms and may even prompt them to do good stuff. It would also encourage them to contribute back to OpenEmbedded what they did to get working Roms.

lpotter - Your rom does change a lot of things. Choice is good, except when it's just duplication. Gnome vs KDE is good and motivating. GPE vs Opie/Qtopia is good to, it motivates even if it's a bit wasteful. Qtopia vs Opie is not any of that - it's just wasteful. But thanks for the explaination about GSM. Yes dialing 112 or 211 even with the screensaver etc is part of the regulations.

Does it means Trolltech will release the dialer/sms/etc. and email application for folks like us who have compact flash cards?  Ooops.

Hrw - A distribution is about choices. I dediced to go for compatibility before everything else. One can't do everything at once. Trust me, a lot of work goes into this compatibility thingy. I will try to get Qtopia 2.1 working soon, and I expect many interesting and fun challenges. It's a shame if I'll be alone going in that direction, but I will anyway.

[lardman]

OpenEmbedded (for building distros) should include qtopia 2.1 and gcc 2.95 support.

Quite. If anyone reading this is interested to add this support then please do so - I'd be interested to use some of the apps from Qtopia 2.1 myself. GCC 2.95 has little appeal for me - I don't use any apps which aren't in OE, so am not limited in that respect - I also use a C750 most of the time, and the entire image and kernel are built with GCC 3.x so it's not important for me.

It would be useful though for some people, as then Sharp ROM users could also benefit from the apps and easy building afforded by using OE.

Gcc 2.95 would make it easy for Trolltech (with a lowercase t :-) to build their Roms and may even prompt them to do good stuff.

The only reason to stay with this old version is compatibility afaik. I think that the advantages of moving to GCC 3.x (and soft-float) out-weigh the compatibility advantages.

Hrw - A distribution is about choices. I dediced to go for compatibility before everything else. One can't do everything at once. Trust me, a lot of work goes into this compatibility thingy. I will try to get Qtopia 2.1 working soon, and I expect many interesting and fun challenges. It's a shame if I'll be alone going in that direction, but I will anyway.

I think this comes down to what I said above - compatibility is not something I'm bothered about - as long as there are the apps available in OE, why bother (of course some apps are not available - but that's just a reason to develop them imho).

I want a 'ROM'/distro/whatever which is moving forward, not stuck in the old days of GCC 2.95. I want (and indeed have) the 2.6 kernel, and I want things to get better.

For me, OE is the way to develop these things, and continue moving forward.

Qtopia vs Opie is not any of that - it's just wasteful.

This is a difficult one, which has been discussed before - I don't think there's an issue
in truth, I think there's room for both.



Si

[guylhem]

Opie/Qtopia It has been discussed before but still no decision has been taken. Maybe it should be time to take a courageous decision ?

OpenEmbedded + Qtopia 2.1 is the way to go. There's no way around. Anything else is just a temporary solution. I'm not against temporary solutions (gcc 2.95 for compatibility) but that's just what they are - temporary.

Isn't it bothering for anyone to push Opie (a glorified qtopia 1.7) along with gcc in softfloat and claiming that's the best solution? Technically, such people are not consistent with themselves. Want the best, without compromises? Go for softfloat - but then it also means qtopia 2.1 !

Want compatibility? I'm sorry but it means gcc 2.95 and qtopia 1.5 or opie :-)

The "inbetween" approach is just illogical.

[koen]

Isn't it bothering for anyone to push Opie (a glorified qtopia 1.7) along with gcc in softfloat and claiming that's the best solution? Technically, such people are not consistent with themselves. Want the best, without compromises? Go for softfloat - but then it also means qtopia 2.1 !
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80190\"][{POST_SNAPBACK}][/a][/div]

Don't use softfloat, use the new arm eabi. Debian will switch to that soon, so you would have your distro (no, not ROM, it's a writable image) with gcc3/gcc4 + the vast debian-arm repository. That's what I call compatibility.

And for opie vs qtopia: People work on what they want, that's the downside off all that 'choice' in the opensource world. Better have 4 nonworking apps than 1 working....

[adf]

Ah... another looney screaming in the wilderness for debian compatability.  

It sounds like a very good idea... in fact it IS a very good idea.  And given the size of storage available for the Z, and the availability of tools like Klaus Weidner's debshrink script, it is a practical idea. one based on a solid distro with known and tested development and distrbution, and a ton of working apps.  This is certainly a good way to go (with the exception or really small optimzed distros for internal memory and cell phones and stuff like that).  

for some reason there seems to be little interest in this approach, aside from the seemingly large number of end users who use pocketworkstation.