OESF Portables Forum
General Forums => General Discussion => Topic started by: guylhem on May 16, 2005, 06:57:39 pm
-
Hello
My latest editorial is on http://externe.net/zaurus/modules.php?op=m...order=0&thold=0 (http://externe.net/zaurus/modules.php?op=modload&name=News&file=article&sid=57&mode=thread&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?
-
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...
-
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.
-
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?
-
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.
-
Hello
My latest editorial is on http://externe.net/zaurus/modules.php?op=m...order=0&thold=0 (http://externe.net/zaurus/modules.php?op=modload&name=News&file=article&sid=57&mode=thread&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.
-
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
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:
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.
-
@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."
-
* 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 (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.
-
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)
-
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 (http://www.externe.net/zaurus/sdk/Embedix.tgz)
VERSION=2.17
cd /tmp
wget http://bluez.sourceforge.net/download/blue...;VERSION.tar.gz (http://bluez.sourceforge.net/download/bluez-libs-$VERSION.tar.gz)
wget http://bluez.sourceforge.net/download/blue...;VERSION.tar.gz (http://bluez.sourceforge.net/download/bluez-utils-$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.
-
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
-
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.
-
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....
-
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.
-
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.
But Opie's design is completely open - if you want to change something you can, Qtopia design is lead by Trolltech afaik - yes, you could just patch Qtopia, but if what you want is in already Opie, this is a lot of work for one person to do.
That said, why not add Qtopia to OE - then you could build Qtopia based flash images - I'm sure a lot of people would be more than happy to use Qtopia 2.xx ontop of the stable (and advanced) openzaurus base system.
Go for softfloat - but then it also means qtopia 2.1 !
One doesn't lead to the other - I'm a bit confused about your understanding here - Qtopia can be compiled without softfloat, and Opie can (and in fact is) compiled with softfloat.
Want compatibility? I'm sorry but it means gcc 2.95 and qtopia 1.5 or opie :-)
Again, some confusion - opie is built with GCC 3.x, uses softfloat and libc 2.3 - the very reasons people complain about a lack of compatibility. If you wanted to you could (afaiu - I see no major issues) drop back to GCC 2.95, libc 2.2 and no soft-float, compile Opie and then be reasonably compatible with the Sharp based flash images.
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 !
I understand your comment about Opie being based on Qtopia 1.7 (and Qtopia 2.x now being available) - however just because the number is bigger doesn't necessarily make one so much better than the other (especially as you're comparing something which forked, and has therefore changed and progressed, not the original source it was based on) the rest doesn't make a lot of sense.
There are doubtless some things which both Opie and Qtopia could learn from one another and in terms of duplication of effort a single project would possibly be better (though depending on the direction of each project, less features may evolve in this case) - however it depends how much influence developers could have with the direction of Qtopia - a lack of feeling some degree of control means that people loose interest.
For people who enjoy designing and hacking at GUIs, the knowledge that you are driving the direction of development because you find something interesting, rather than because a company will need features to sell the GUI to make some money, is a nice feeling (I'm not having a go here - obviously the two sides intersect, but imo are still driven by differing goals).
Cheers,
Si
-
As pointed out by various people here, the 7GB "requirement" of OE guylhem is talking about
is nonsense.
These ~7GB include a full grown distribution from INIT to Opie, a hole sh*tload of Opie applications (almost all, except games) and the complete source.
Sheesh, thank god I didn't tell him about the required space of a world build (2000+ packages, all packages in the official OZ / fam feeds). It can easily grow beyond 20GB w/o trying very hard
-
I suppose if we wanted to make the comparison realistic and fair, we could just rm the source and most of the build directories after the packages have been built and staged and then compare the size of the system you need to use to build a single app.
This could be performed by OE if you so desired (would require adding an extra stage - do_cleanup() or somesuch), but there's no reason why you couldn't do it if you so desired.
Si
-
lardman - regarding compilation, of course you can compile any gui with the gcc you want. I was only linking one gui with one gcc to match the most recent ones (in this case qtopia and softfloat - but eabi looks even better)
I will try to get qtopia 2.1 into OE. Not sure how I'll succeed, but I'll try.
-
lardman:
INHERIT +="rm_work"
can clean builddir after build - but it has problems sometimes.
-
back to the weight issue. As I've said, I don't particularly mind (the orange lines bug me more, for example). But as coredump points out getting OE up to a handful of gigs takes a bunch o apps (space needed, not space left after a cleanup) I would bet that because it builds dependencies by default, there are single apps that will bring it to 3-4 gigs with dependencies. further... since the repositories are a moving target, to build a current app, one might very well be in the position of having to build an entire image to match the versions of the app and its dependencies. This might very well take 5-7 gigs of drive space before ..say..a working web browser appears. This doesn't bother me in the least, and I can see it as a more or less logical outgrowth of a complete build system, exacerbated by the fact that both the system and the things built with it are evolving. Though it would be nice to know how much space is needed to make pdaXrom, by way of a comparison.
The fact some of more visible and important of the OE folks seem unwilling to acknowledge this does them very little credit. I can understand that OE has been a lot of work, and then some..and that it is not nearly finished... and that the developers probably have to listen to a lot of crap about some of their released oses--like ths 6k yellow line mystery--and even more crap about breaking compatbility with sharp. On the other hand, there is a definite aspect of rounding up the wagons to fend off the heathen when any aspect of OE is seriously questioned. To go with this is a seeming unshakeable orthodoxy..a sense that anything done with by or todo with OE is inherently, naturally and imperatively right and best. No doubt this is an effect of the frequent criticism the project is subjected to, and the defensiveness appartaining to such criticism. Still... it ends up reminiscent of the "hebrew liberation front" in Monty Pythion's life of brian -- a handful of dissidents calling everyone else "Fu*##ing splitters."
The idea there is much by way of politics regarding oses for a device owned by so few is, in itself, pretty damned funny.
-
The idea there is much by way of politics regarding oses for a device owned by so few is, in itself, pretty damned funny.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80305\"][{POST_SNAPBACK}][/a][/div]
I must add that OE isn't zaurus centric, as all these topics tend to be.
If you want a distro for your device freshly compiled from source, use an OE-derivate or gentoo, if you really need that qt crap use pdaxrom or one off the cloned distros, or if you are happy with it, use the stock sharp image. It's all about *you* having fun with your (way too) expensive gadgets. So stop with the "I use project Z, so project X must die". If I have fun porting 2.0.28 to my favourite device I can do without pedantic idiots saying "2.6 is da bomb, your project must die, you wanX0R". Freedom and choice, remember?
-
The fact some of more visible and important of the OE folks seem unwilling to acknowledge this does them very little credit.
That was the point of my earlier post - currently, OE does keep all of the source and build directories after building everything, however it could be altered very simply to remove these - which would mean that the size would drop down to the same as a standard cross-toolchain (inc dependant libs as these would be needed anyway) + sizeof(bitbake & oe files) - so not significantly larger than a pure binary toolchain. There is still be a one-off requirement to build the toolchain, which would add a time penalty, but for me this is not an issue as I know exactly what the toolchain is doing, what patches it contains, etc.
I'm not contesting the fact that currently you need a fair bit of disk space to run OE, just the fact that the majority of this disk space is not actually used, it's just sat there containing already built files, much the same as would happen if you used plain configure, make & make install to build and install the cross-toolchain and libs by hand - and therefore OE is not nearly as terrible as it's made out to be by guylhem.
I, for one, would want to keep the source available locally (though in this day and age of fast, always on internet, that's not such a major issue), but it might well be worth while removing the build directories to cut down the disk space requirement after each package has been built, staged and packaged.
It's a valid point, but equally as most people have very large hard disks these days my understanding is that it probably wasn't a major priority. The major priority is to speed up BB/OE and cut memory useage, and I understand this has now been achieved. For those with disk size constraints, then looking into the additional 'inherit' flag as shown in hrw's post may be worthwhile.
further... since the repositories are a moving target, to build a current app, one might very well be in the position of having to build an entire image to match the versions of the app and its dependencies.
Yes and no, if the app in question depends on a CVS components then it will be downloaded and compiled again (unless you set a specific CVS date, for the app or globally), and if you update the package repository (the .bb files), any which have changed will be rebuilt (I think), but this is not normally a major thing, and if you want to stay with the files for a given release/date, then you just use the repository from that day with the appropriate CVS date set.
To go with this is a seeming unshakeable orthodoxy..a sense that anything done with by or todo with OE is inherently, naturally and imperatively right and best.
It's just that it really is rather a useful tool, which makes life vastly easier that cross-compiling the old way with a binary toolchain - I've done both, OE is easier and significantly cleaner IMHO. All that that aside, I understand that going on about something often has the opposite effect to that intended - it annoys people and drives them away, however this thread was partly having a go at the way BB/OE operates, so I think it's fair to go over it once more
The idea there is much by way of politics regarding oses for a device owned by so few is, in itself, pretty damned funny.
Not funny, a bit of a shame really, we ought to cooperate more, no matter which GUI/buildsystem we are using, rather than constantly bickering. In fact this general bickering has started to annoy me quite severely - I can see now how people could easily drift away.
Regards,
Si
-
Why all this talk about OPIE vs. Qtopia?
OPIE is an embedded Linux project. Qtopia is a Linux GUI project. Completely different beasts.
Will Trolltech be supporting the WRT54G, ASUS WLAN500G, Linksys NSLU2 or other embedded devices that have *NO* *FRAMEBUFFER*????
Of course they won't. Because Trolltech builds GUIs and GUI environments and GUI-Linux packages for portable devices. They support everything from desktops through mobile phones.
On the other hand, OPIE is an offshoot of OpenEmbedded which is an embedded Linux system for small devices with limited hardware. Some of them have a GUI and some of them don't. And soon, some of the devices with no framebuffer may actually have a GUI by using a USB-VGA adapter if the people working on PEPLINK MANGA manage to reverse engineer a certain Linux driver.
-
wavetossed: thx for free laugh
-
I think you are a bit confused. Opie is a Linux GUI, OpenZaurus is a Linux distribution.
-
I think you are a bit confused. Opie is a Linux GUI, OpenZaurus is a Linux distribution.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80516\"][{POST_SNAPBACK}][/a][/div]
Any specific reason to limit Opie to linux?
-
Any specific reason to limit Opie to linux?
In theory not, in practice we use/plan to use quite a few linux specific features (input subsystem, pcmcia subsystem, inotify kernel interface, etc.).
-
all the talk about opie vs. qtopia is basically about effort and effect... are there enough skilled people working on this stuff to build and maintain 2 qt based guis.--and are 2 flavors of qt gui good or necessary. I think that is the question, yes?
-
That is a constant question around here - why split the effort across multiple projects instead of combining them on one super-rom to replace all the others.
This question has been answered a bunch of times already - people do what they are inspired to do.
I would ask a different question - Why try to kill off valuable inspired work every time something new comes along?
There are a lot of exciting things that are happening with Debian, pdaXrom, QTopia, and OZ/Opie. That is a good thing. All of this work, when it is open, is good for the community.
I know it is counterintuitive, but in this case the parts are greater than the sum of the whole.
-
all the talk about opie vs. qtopia is basically about effort and effect... are there enough skilled people working on this stuff to build and maintain 2 qt based guis.--and are 2 flavors of qt gui good or necessary. I think that is the question, yes?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80544\"][{POST_SNAPBACK}][/a][/div]
Where one GUI is being developed by a company who pays people to work on it. Given the fact TT was so 'open' and 'involved' people had to fork it, I put my money on Opie. Personally I don't like the look and feel of all the QT enviroments, so I'll shut up now in this topic
-
all the talk about opie vs. qtopia is basically about effort and effect... are there enough skilled people working on this stuff to build and maintain 2 qt based guis.--and are 2 flavors of qt gui good or necessary. I think that is the question, yes?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80544\"][{POST_SNAPBACK}][/a][/div]
Where one GUI is being developed by a company who pays people to work on it. Given the fact TT was so 'open' and 'involved' people had to fork it, I put my money on Opie. Personally I don't like the look and feel of all the QT enviroments, so I'll shut up now in this topic
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80558\"][{POST_SNAPBACK}][/a][/div]
errmmm.. the only way Opie "forked" Qtopia is by Trolltech actually giving a ratsass about things, and releasing Qtopia under the GPL. I don't know what version of GPL you are thinking of thats not open.
-
I'll give you a few thoughts from a user's perspective. I have ambitions of learning python and qt and doing a few things, but I am a looong way off.
BTW, if this were the desktop linux world, we wouldn't be having this conversation.
As a user, what do I care about:
Applications - I need to do what I need/want to do. On the desktop side, it doesn't matter what distro or window manager I choose, in general I have access to the same applications. And if I choose carefully, I can use the same applications on linux and windows.
In general, as a user in the desktop world, gnome versus kde versus something else; rpm versus deb; apt versus yum versus something else is moot. In general, I can do the same things or get the same functions lots of different ways . . . again it's taste.
So, on the zaurus, if I have all the applications (or reasonable alternatives) that I need and work on all the distros, then it comes down to a matter of taste. I don't think we are there yet. Although, among the applications I use are KOPI, KAPI, Portabase, Opie Reader, and Bedic -- all of which are available on OZ/Opie, PdaXrom, and Cacko.
I still like some Sharp ROM based apps that seem harder to get usable on Opie, or require closed libraries. Similarly, I quite like some Opie apps (e.g., Dagger) that don't seem available on Sharp ROMS.
The System Doesn't Get in My Way - Different people are more comfortable using different systems, so again there is an element of personal taste.
As a user, the keyboard repeat rate with the OZ 2.6 kernel got a bit frustrating. And as a user, I don't know how to fix it to suit my tastes. Typing faster as the kernel notes stated didn't make the annoyance go away.
The System Works with My Stuff - This is actually my key criteria in selecting a desktop distro. Does it recognize my hardware and peripherals or is it relatively easy to set up?
I have an ir keyboard. To be the most productive with my CL860, I would like to be able to use an external keyboard. PdaXrom (which I like) doesn't seem to support this. On Oz 3.5.3/Opie I couldn't figure out how to get it to work (IRK depends on lirc which didn't seem to be there for the 860 -- maybe I'm wrong).
It Should Be Fun to Use - For me this takes a backseat to being productive at the moment, but it is an important criteria.
Conclusions -- I personally think that OZ is the future in that it is device, vendor, and x-server/framebuffer agnostic. It will also support more devices.
Rather than Qtopia updates -- maybe we need to focus on QT/E updates.
PdaXrom also has a special place in my heart. If I could get the PdaXrom experience on top of an OZ base that would be cool.
But the "ROM" I find myself using the most is Cacko -- even though my view is it isn't the way forward. The reason I use it is because it just works . It has broad compatibility with existing apps -- many of which don't seem to like OZ/Opie. And for what I do, I tend to be the most productive in it. For X-based apps, I can use Debian/X-Qt.
Commercial and closed source programs without good free alternatives may continue to exist -- but if somebody can get them to compile for OZ/Opie too, than we can move closer to the best of both worlds.
-
Hi
I think Opie and Qtopia is great, but would things be better if development was focused on one of them? Supposingly PDA's are dead, smartphones are the way. Yet there appears likely to be limited, if any developer access, SDK's etc, for developing apps on Qtopia Phones, so difficult to see how the future will pan out. I understand Trolltech's position with phone companies and security, but I wonder if Trolltech regreted GPLing Qtopia (Opie forking) in the early days and this is another reason why Qtopia Phone is closed at this time. I suspect Trolltech would prefer developers focused on apps for Qtopia rather than a competing gui.
At the end of the day without Trolltech none of this would exist and understandably Trolltech need to run a business and I think prefer to keep some control of Qtopia. If for example Opie succeed in to phones due to a fork from a GPL Qtopia Phone it could hurt Trolltech. But for me, I personally think it is more important to have a Linux based device with access for developing and running third party apps, whether the gui base is Opie or Qtopia doesn't matter so much.
Richie
-
Hi
I think Opie and Qtopia is great, but would things be better if development was focused on one of them? Supposingly PDA's are dead, smartphones are the way. Yet there appears likely to be limited, if any developer access, SDK's etc, for developing apps on Qtopia Phones, so difficult to see how the future will pan out. I understand Trolltech's position with phone companies and security, but I wonder if Trolltech regreted GPLing Qtopia (Opie forking) in the early days and this is another reason why Qtopia Phone is closed at this time. I suspect Trolltech would prefer developers focused on apps for Qtopia rather than a competing gui.
At the end of the day without Trolltech none of this would exist and understandably Trolltech need to run a business and I think prefer to keep some control of Qtopia. If for example Opie succeed in to phones due to a fork from a GPL Qtopia Phone it could hurt Trolltech. But for me, I personally think it is more important to have a Linux based device with access for developing and running third party apps, whether the gui base is Opie or Qtopia doesn't matter so much.
Richie
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80584\"][{POST_SNAPBACK}][/a][/div]
Trolltech does not regret GPL'ing Qtopia. If we did, then we wouldn't still be releasing new versions under the GPL. Opie has not hurt Qtopia sales at all. Otherwise, I probably wouldn't be allowed to work on Opie. Most companies want to know absolutely that they can get help when they need it.
-
It does seem that opie has benefitted Qtopia. and of course exists because of qtopia. more interoperability might be something of a goal? maybe qtopia 2.1 soft float a la guylhem w/ oz and maube we could get a current opie built w/ sharprom compatablilty ..mayb e using the build system lpotter uses for Qtopia? migh make for better cross pollination.
( waiting to see who explains why it shouldn't/couldn't be done LMAO)
-
Compatibility? compatibility with what? abiword does not run inside qtopia. if we want maximum compatibility (ie opera running) let's just use the stock sharp software what's so wrong with it anyway? I think most Z users are using it and are pretty happy with it.
You want the biggest number of application? debian with X provides that.
Qtopia 2.1 is the way? I don't want qtopia, I don't want synchronization.
There is an open source browser running on the Z: firefox and an effort to develop an open source lightweight browser is allready on the way: minimo. Surely gpe is the way. Why waist time trying to port another engine?
Opie should die.
What will be the benefits? All the great opie developers would suddenly go and write applications for qtopia? submit patches for qtopia? They could have choose to do this in the first place, I don't think that they will change their mind now that they have put so much efforts in their baby.
New Z owners will stop to be fooled into this opie business and start to make qtopia applications? I think that people starting development for opie know pretty well what they are doing as developing for qtopia is the most evident choice.
There is no chance that opie will die as long as some people find the urge to do it or something in this project that they don't find elsewhere.
I don't think there is a ultimate solution, I don't think there is a way to focus developers giving their free time on one great vision.
(damned I've been waisting my time again writing a 2 cents rant)
-
Compatibility? compatibility with what? abiword does not run inside qtopia. if we want maximum compatibility (ie opera running) let's just use the stock sharp software what's so wrong with it anyway? I think most Z users are using it and are pretty happy with it.
You want the biggest number of application? debian with X provides that.
Qtopia 2.1 is the way? I don't want qtopia, I don't want synchronization.
There is an open source browser running on the Z: firefox and an effort to develop an open source lightweight browser is allready on the way: minimo. Surely gpe is the way. Why waist time trying to port another engine?
Opie should die.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80629\"][{POST_SNAPBACK}][/a][/div]
While I do think X is the way for most pda's (I've run X on my 486 which was far less powerfull), I don't think Opie should die. Opie and qtopia provide great pda functionality, which is their first and formost goal. I like GPE more because it doesn't let this pda paradigma get in my way, but it's less suited for the pure PIM people. Because of this slightly different directions both Opie and GPE can coexist happily. Opie/X11 looks very promising, and I would be surprised if TT isn't testing qtopia on X.
-
Hi Lorn
Trolltech does not regret GPL'ing Qtopia. If we did, then we wouldn't still be releasing new versions under the GPL.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80590\"][{POST_SNAPBACK}][/a][/div]
Perhaps regreted was the wrong word, I was meaning that the early version of Qtopia PDA, led to a fork. And suggesting Trolltech may want to control Qtopia phone edition by keeping it closed source, for the time being whilst it is maturing, to prevent that happening again. I'm not criticising Trolltech, I think you and they do a good job and like I said before without Trolltech none of this would likely be possible.
Opie has not hurt Qtopia sales at all. Otherwise, I probably wouldn't be allowed to work on Opie. Most companies want to know absolutely that they can get help when they need it.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80590\"][{POST_SNAPBACK}][/a][/div]
I was suggesting Opie could hurt Trolltech if it had a phone edition, not that it has with its current PDA releases. As has been mentioned before PDA’s are dead, the future is smartphones. Opie is for PDA’s. Therefore a PDA version has less impact on the future. If the future is smartphones, then the only option is Qtopia Phone.
If we agree the future is phones, I think what is more important than Opie or Qtopia gui's is what the user can do with Qtopia Phone. What the telcos will allow to run on them and what developers can do and this is speculation until the the phones appear. The hope is that a Qtopia Phone can be as fun to use as the Zaurus has been as PDA.
Cheers
Rich
-
pgas. debian stuff (everything k for example) uses qt libs. Not the same as Qtopia, of course, but not straight x either--and straight x doesn't necessarlity mean x/gtk, does it??. are you bringing back the great QT/GTK schism? (forking heretics )
If this were about what is the best approach to a zui... well I think pdaXrom got it right (x w/ qt).
the discussion was opie/qtopia... does thant necessarily mean gcc and kernel version limits? oz compat vs. sharp compat? surely the guis could be compiled to run either way. opie used to be compiled to run sharp compat... taking the kernel/gcc version debate away would help clarify quite a lot (if it is even possible anymore)
-
@koen, my point was not that opie should die but in response to that
@adf: I don't understand what you mean. debian does not requires qt...nor gtk if you don't want. Just use non-qt or non-gtk applications. pdaxrom is not really based qt, the wm used openbox uses gtk IIRC...
-
@koen, my point was not that opie should die but in response to that
@adf: I don't understand what you mean. debian does not requires qt...nor gtk if you don't want. Just use non-qt or non-gtk applications. pdaxrom is not really based qt, the wm used openbox uses gtk IIRC...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80688\"][{POST_SNAPBACK}][/a][/div]
matchbox uses plain xlib, although it will be gtk based when gtk+ 2.8 hits the streets.
-
Compatibility? compatibility with what? abiword does not run inside qtopia. if we want maximum compatibility (ie opera running) let's just use the stock sharp software what's so wrong with it anyway? I think most Z users are using it and are pretty happy with it.
Abiword sure can. So can kde, or even gnome, if you really wanted. Obviously you aren't into linux pda's enough to know about X/qt (should really be named X/Qtopia), which is an x server running in a Qtopia application.
http://xqt.sourceforge.jp/download.html (http://xqt.sourceforge.jp/download.html)
You want the biggest number of application? debian with X provides that.
some people tend forget its a _pda_
Qtopia 2.1 is the way? I don't want qtopia, I don't want synchronization.
Good for you. Most users do.
There is an open source browser running on the Z: firefox and an effort to develop an open source lightweight browser is allready on the way: minimo. Surely gpe is the way. Why waist time trying to port another engine?
Because "minimo" is still a memory hog.
There is also konqueror, if you happen to be stuck on using only open source.
Opie should die.
heh.
What will be the benefits? All the great opie developers would suddenly go and write applications for qtopia? submit patches for qtopia? They could have choose to do this in the first place, I don't think that they will change their mind now that they have put so much efforts in their baby.
some of these Opie developers also work for Trolltech.
New Z owners will stop to be fooled into this opie business and start to make qtopia applications? I think that people starting development for opie know pretty well what they are doing as developing for qtopia is the most evident choice.
There is no chance that opie will die as long as some people find the urge to do it or something in this project that they don't find elsewhere.
I don't think there is a ultimate solution, I don't think there is a way to focus developers giving their free time on one great vision.
(damned I've been waisting my time again writing a 2 cents rant)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=80629\"][{POST_SNAPBACK}][/a][/div]
-
in fact debian does not require a gui. not even curses. Same with the Z. But that is hardly a meaningful objection to an end user (of the pda/desktop variety). can you imagine the popularity of a no gui os?
as to "debian with x provides the biggest number of apps" a lot of those apps use Qt.
my point was that Qt of some kind seems to be here to stay..and that it is extensively used-- and that it seems to be a GOOD THING (and is gpl'd)
true, you can use debian or pdaxrom without any qt stuff. I bet most people (end and desktop users, NOT running servers) don't.
Part of what makes pdaX so nice is the qt stuff, same w/ kde. sure, I sometimes use xfce4, atm I'm on gnome. But I wouldn't really be inclined to get rid of Qt stuff, or in any sense limit my use to xlib or x/gtk. there is no point. I realize you can have macthbox w/out any QT...and that there is no Qt going on in gpe. I've used gpe. I even liked what of it that worked on my Z. I would have liked to have qt apps too, if I could.. just as i like having xqt if I am running Qtopia. UI is about ease and 'richness" of the interface.... not so much about ideology. I bet a "puritan hedghog mouse" with needles sticking out wouldn't sell much. Why strip down, limit, and detract from uis on an ideological basis? ( I argue within my tolerance here, btw--assuming all is gpl).
what were we talking about again?
-
hmm. my point was that there are different people wanting different things and doing different things and that it won't change and that there is no point to seek a common ground for everybody.....
It seems I didn't make that clear enough....I tried to show what I feel is wrong with guhilem's rom (ie that the sharp distribution is not that bad, that compatibility with sharp roms doesn't necesseraly means the biggest number of running applications, that opie can't die....)
I apologize if some people felt bad because of my post.
lpotter: I did start my post writing that most people uses sharp rom hence qtopia , I know about x/qt I tried it more than a year ago (>400posts since dec-2003), I have nothing against qtopia...I have even compiled the yopy/qtopia for pdaxrom...and sometimes when I use it I do forget that my z is a pda
-
right.
there is some fear of excessive divergence, however.
(I know I'm gonna get flamed for this) the fate of Beos or os2 come to mind as being simultaneously insuficiently independant, and insufficiently compatable. Some common ground is needed, though it might range widely (ewwww... please excuse the messy metaphor)