OESF Portables Forum
General Forums => General Discussion => Topic started by: amrein on April 03, 2004, 01:04:06 pm
-
First I introduce myself, I\'m the one that had organized the first Zaurus SL-C750 and SL-C760 group buy when they were released in June. I don\'t know if this intervention will be a flop and it doesn\'t matter if so. Perhaps I can influence the way our Zaurus is evolving (its OS, base system, PIM and other software). In any case, what I\'m sure is that it could completely change the face of Linux on PDA. :wink:
:idea: We need a strong reversal in the present PDA Community way of working. What is missing for all Sharp Zaurus, iPaq, Yopy, and other device running Linux is a well thought and organized effort. The goal that could be common to all of us is to build the next generation powerful and complete operating system for our beloved device. You should certainly already know that there\'s a lot of software, build systems, operating systems, rom/kernel images, cross-compilers... out there. All those solutions are growing slowly and in many different projects (with one developer to five). It\'s now time to propose a solution that could resolve this. And to go quickly to something very useful for everyone, the fusion of pdaXrom or OE with Debian ARM distribution is needed.
What do I mean with fusion? Here is an explanation:
PdaXrom team for example has define an emerging operating system. They already has proved with cacko rom and pdaXrom that they know how to deal with user needs and communication with the community is done easily and in both way. What should the community do now? We need:
* to completely fusion pdaXrom libraries with those of Debian.
* to leave only useful tools from Debian and replace most of them with busybox (as it is already in pdaXrom).
* to add all dependencies in the base system packages (.ipk) to replace Debian ones (so apt-get or ipkg won\'t try to install something else when an .ipk is available). To split them if necessary.
* to finish the package manager ipkg so it becomes completely stable and could manage correctly .deb files without needing apt-get and other tools.
* Tell to all user whinning for a package: \"it\'s in Debian repository. If you want something smaller, just build an ipk and upload the source and the binary in our incoming directory\".
* It could also be interesting to take the control of http://www.emdebian.org (http://www.emdebian.org) so Debian could begin to have a real voice in embedded market (other than \'extract deb files and do it manually\').
The selected building system team will need to:
_ refuse to open CVS write access to the base system for anyone other than those whose have proved their value (contribution, submitted patches...).
_ do things like they think they should do it (like any PC distro today) and use and include software built by other people from the net (I mean include for example Portabase without having to manage the construction but only to verify its easy compilation).
_ They need only to work on the base system and not on the wall thing (that shouldn\'t prevent them from building good tools).
_ listen to users but with a very strong reflection because most of them are simple Trolls here.
There\'s also some work for own great sites ZaurusUserGroup.org and www.killefiz.de/zaurus/ :
_ list tasks that need works and ask for package maintainers like on Debian. I\'m talking about the wall purged application ipkg set and not the base system. (ZaurusUserGroup.org)
_manage the default applications construction (PIM, ...) in the present community.zaurus mirror. (ZaurusUserGroup.org)
Note: Those default applications need to be defined.
_ manage, if they want to and if it\'s possible, some more open source projects (separated from default one).
_ list all available software, have screenshots, ... (www.killefiz.de/zaurus/)
_ zaurus forum, zaurus faq (to revamp), ... (ZaurusUserGroup.org).
That\'s it! Someone agree or disagree? ZaurusUserGroup.org or www.killefiz.de web master?
Please, OE or pdaXrom team members, don\'t reply at one. I\'m sure that you like what you have done so far (as most of us).
-
Hi,
what I find a little confusing at the moment is that we have
* about 10 ROMs
* for 6 Zaurus models (+ YOPY + iPAQ + Royal + Chinese Linux PDAs + more to come)
* 2 different compiler versions (2.95.3 and later)
* and 4 different .ipk formats to choose from...
Variety to choose can be nice - but if things don\'t fit together in a toy kit, it gets moved into the corner
As a developer, I currently have to choose which Zaurus model and ROM I want to support for my customers.
What I also would help IMHO is an improved version of Killefiz which adds some more VersionTracker features (although we should not imitate all the banners etc.). The ZSI2 development seems to mirror killefiz but there are some flaws in the interface (e.g. sort alphabetically and there is no scrollbar to go down). And throwing in some SourceForge/FreshMeat would make it the second (the first is ZUG!) central resource for LinuxPDA development.
-- hns
-
I\'d be willing to help code a brand new killefiz with their webmaster. I\'ve done websites for almost 10 years. Pick a language and I can do it; his choice.
Something with a Freshmeat type of interface I think would be nice. Since DevNet is down, I think we should maybe put together a full site just for programming on the Zaurus.
-
@dhns:
* and 4 different .ipk formats to choose from...
I\'ve only seen two myself, though I suppose the requirement in later versions of ipkg (OZ of late for example) to use the \'arch\' line may be what you\'re talking about. IMO this should default to arm or warn you and ask if it can\'t find \'arch\'.
Again we go back to the discussion we had on the devnet about people naming their ipk files better to allow end users to work out what\'s inside without having to install it (e.g. originally it was a question of OZ or sharp ROM, but now we have to take into account which version of GCC, which version of libc, etc.).
* about 10 ROMs
There are really only 4 ROMs though -
OZ mk.I (GCC 2.95: v<=3.3.5 for collie)
OZ mk.II (GCC 3.x: v>=3.3.6 for collie, all versions - I think - for other machines)
ROMs based on the old Sharp ROMs (crow, etc.)
ROMs based on the new Sharp ROMs (proto\'s, etc.)
and in truth the base system on the two Sharp ROMs is pretty much the same anyway (afaicr).
This is just Qtopia style ROMs, if we include non-qtopia/opie ROMs then there\'s also pdaXrom, debian and GPE (but they are different enough to not be confusing IMO).
@dz:
I think that revamping the killefiz site would be good - have more info about which ROMs certain programs will and won\'t run on, etc., but this is better discussed as I don\'t really know what I\'m talking about (though it would be nice if people could post tips about how to get programs running on ROMs other than those for which they have been designed for - I for one don\'t have half a dozen Zs on which to install every possible ROM to test compatibility - nor could I be bothered even if I did).
Si
-
* and 4 different .ipk formats to choose from...
* about 10 ROMs
Well, my way of counting what I have seen:
* ipks made with tar and ar -] 2 variants
* ipks gzipped or not gzipped -] 2 variants
The strangest thing I have seen yet was an .ipk made with \'ar\' having the component file names debian-binary/ control.tar.gz/ data.tar.gz/ I was not able to extract anything on a Zaurus (which does not come with ar) or a MacOS X machine (until I used an editor to replace the / by a blank in the raw file). The Sharp ROM just understands the ccombination tar&gz.
For the ROMs I counted (well, not only restricted on Zaurus models):
* Sharp ROMs 1.x
* Sharp ROMs 2.x
* Sharp ROMs 3.x (e.g. differing in the PIM)
* OZ versions
* pdaXROM
* Cacko
* theKompany
* Familiar for iPAQ, Dell, ...
* YOPY
* Unitech
* the newly announced Royal LineaLX
* others (China, India, ...)
All are basically Linux but one can\'t assume any tool, library, device driver, compiler etc. to be in any two sytems available at the same location or version. That is something I would expect a common distribution, bundling all these activities could take care of. This would greatly enlarge the user base for us developers. Therefore I like this idea.
-- hns
-
All those incompatibilities, the need for an open source drived base system and the need for user/developper friendly applications for everyday use is the heart of the message. Debian has got the arm package repository, all needed tools for cross compilation and is completely driven by the open source community.
Could we begin the discussion about it? Dhns has the same feeling. Dz has showed us what we should all do: be ready to get involved. :!:
What say you? The debate is as important as the goal to reach. There\'s a lot of people that think a lot here but there\'s only two reactions?
-
Isn\'t this what MickeyL has been asking for for months?
Seems to me that Sharp has no further interest in the original ideals behind the Zaurus. They aren\'t interested in this community.
So OZ/OE is the best option. Its already there and mature ... or are we all going to procrastinate ourselves to death discussing the million ways we *could* do things?
Lycoris has realised this. We should build on that momentum.
Mike.
-
latest pdaxrom builder have support for RiscStation and x86 target too.
Soon i will add support for Acorn RiscPC (Arm7/SA) computers and LH79520 embedded sharp boards too. For xscale devices we already have own feed.
-
Hi sashz.
Could OE and pdaXrom work for the same goal? OE (correct me if I\'m wrong) is mainly a build system and pdaXrom an OS + cross toolchains.
Does the build system of pdaXrom conflict with OE?
The pdaXrom used builder is working and is available in a raw form If I\'m not mistaken here: http://www.pengutronix.de/software/ptxdist_en.html (http://www.pengutronix.de/software/ptxdist_en.html).
All concerns: can the Debian fusion be though? Can OE has a place in this construction? Are you agree with the way of managing a new (more open) Linux distribution for PDA and hanbedded device in general? What could be added and what could be improved in the rough outline wrote on top of this thread?
-
am: I agree ...
dz: I\'d be willing to host that site, too.
I have a site with plenty of room, ram, bandwidth and disk space -- all it needs is projects/webmaster, etc.
but I agree, 100%, all the fragmentation/divergence is not helping one bit.
Scott
-
I disagree, I have had this arguement with amrein before about what the Z is, handheld computer or PDA. I think it unwise to put everyone in the same category, I know other Z users in the real world who like them because they are excellent handheld workstations, not a PDA.
No more than two weeks ago, I advocated convergence but now I don\'t. A Linux PDA on the market (and I mean that in the true sense of the term PDA) has no hope in hell of ever suceeding, Palm and Microsoft would obliterate it, that\'s why Sharp don\'t go head-to-head against the others, no point.
I\'ve only used OZ once on a 5500, I found the stable build to be very unstable and I just did not like it, but it could be developed further (as Lycoris is doing) to produce that kind of PDA platform the original poster wants.
But for heavens sake, we need some separation, for the different goals and desires that people have. I don\'t want a locked down PDA OS on my Z, no point, I could have just bought a Palm or PPC.
Cacko should get a makeover and integrate Qtopia and X together for those who want the most flexibility, make it more like Debian in philosophy, it\'s in so few hands, I don\'t feel comfortable making the switch from Qtopia.
Convergence means a consensus must be achieved, not possible, and to force the issue would just destroy this community from the inside out.
[span style=\'font-size:14pt;line-height:100%\']I used to have a Helio, which was destroyed by the community whinging and pulling in different directions long before Vtech pulled the plug on them.[/span]
-
Hi sashz.
Could OE and pdaXrom work for the same goal? OE (correct me if I\'m wrong) is mainly a build system and pdaXrom an OS + cross toolchains.
Does the build system of pdaXrom conflict with OE?
The pdaXrom used builder is working and is available in a raw form If I\'m not mistaken here: http://www.pengutronix.de/software/ptxdist_en.html (http://www.pengutronix.de/software/ptxdist_en.html).
All concerns: can the Debian fusion be though? Can OE has a place in this construction? Are you agree with the way of managing a new (more open) Linux distribution for PDA and hanbedded device in general? What could be added and what could be improved in the rough outline wrote on top of this thread?
well, pdaXrom based on PTXDist and have scripts which unlike OE.
Why i cant move pdaXrom to OE base? Easy - because that not ready, and if ill learn OE, rewrite all scripts from pdaXrom and debug new system that will take much time, i havent time because need working system for embedded project now, and pdaXrom have big progress in this way
for debian/familiar packages compatibity need add only list of preinstalled libs/apps, becaue builder produce core ROM as monolitic.
-
@dhns:
Well, my way of counting what I have seen:
* ipks made with tar and ar -] 2 variants
* ipks gzipped or not gzipped -] 2 variants
The strangest thing I have seen yet was an .ipk made with \'ar\' having the component file names debian-binary/ control.tar.gz/ data.tar.gz/ I was not able to extract anything on a Zaurus (which does not come with ar) or a MacOS X machine (until I used an editor to replace the / by a blank in the raw file). The Sharp ROM just understands the ccombination tar&gz.
I see. I presume some of this is caused by various browsers either gunzip\'ing or adding a tar extension.
An ipk file is either:
1. A tar.gz file containing 3 files - debian-binary, control.tar.gz & data.tar.gz
2. An ar file containing 3 files - debian-binary, control.tar.gz & data.tar.gz
As you say the Sharp ROMs only accept type 1., OZ will accept both (the ar type is more space and time efficient BTW).
I don\'t know about your funnily named internal files.
For the ROMs I counted (well, not only restricted on Zaurus models):
* Sharp ROMs 1.x
* Sharp ROMs 2.x
* Sharp ROMs 3.x (e.g. differing in the PIM)
* OZ versions
* pdaXROM
* Cacko
* theKompany
* Familiar for iPAQ, Dell, ...
* YOPY
* Unitech
* the newly announced Royal LineaLX
* others (China, India, ...)
All are basically Linux but one can\'t assume any tool, library, device driver, compiler etc. to be in any two sytems available at the same location or version. That is something I would expect a common distribution, bundling all these activities could take care of. This would greatly enlarge the user base for us developers. Therefore I like this idea.
True, it\'s difficult, but the underlying systems (libs and base tools) are omstly the same for a number of these ROMs.
e.g.
Sharp ROMs 1.x (whether for the 5000d or the 5600/Cxxx), Sharp ROMs 2.x, Sharp ROMs 3.x, theKompany, Cacko, all have the same basic libs (not necessarily the same Qtopia ones mind you).
For the others I agree, they are different, however for familiar and OZ (and pdaXrom) this is not an issue as it\'s easy enough to upgrade libs if need be (libncurses for example).
The larger issue as I said before is the verison of libc - familiar and later versions of OZ have moved to v2.3 while everyone else is still stuck in 2.2 land. And to some extent the version of GCC which is used to compile the distribution & apps - there are the obvious issues with name mangling on shared C++ libs.
Si
-
Here is an extract of a conversation on #arm-debian IRC. I have only one question: am I crazy asking for this group work? Is the Debian people contaminated by something?
<cam|cam> Hi everyone
<cam|cam> On which device are you running Debian-ARM at present (I mean your device)?
<Chocky> http://www.chocky.org/linux/systems.html (http://www.chocky.org/linux/systems.html)
<cam|cam> thanks. I have followed your link (reading .
<cam|cam> There\'s emdebian.org. There\'s intimate.familiar.org. Any other project for Debian ARM (clean-up version) for PDA and embedded device that I missed?
pb_ (~pb@2002:3e03:42cc:1:20b:6aff:fe19:f290) has joined channel #debian-arm
<Chocky> there\'s handhelds.org
<Chocky> and
<Chocky> http://www.pocketworkstation.org/ (http://www.pocketworkstation.org/)
<cam|cam> Ho yes. I forgot PocketWorkstation.
<cam|cam> So there\'s no project (other than familiar and emdebian) that want to provide a Debian shrinked official version with ipkg and deb support?
<cam|cam> I just ask to be sure that I won\'t lost my time.
<Chocky> what do you want to do?
<cam|cam> A very light version of Debian + ipkg modification to completely replace package tools + ipk packages to replace debian ones (ipk=deb but shrinked) + a package builder tool
<pb_> I\'m not sure I understand \"ipkg modification to completely replace package tools\".
<cam|cam> ipkg remplacement = Something that could be as powerfull as apt-get+rpm+dpkg
<cam|cam>
<Chocky> I\'m not sure what facilities aren\'t already provided by ipkg
<Chocky> +that you think you need
<cam|cam> ipkg is buggy and just install/remove package.
<Chocky> sounds like an old version
<pb_> cam|cam: eh, so fix the bugs.
<cam|cam> (it is just part of the plan... if I still found bugs in it)
<cam|cam> pb_: sqlite should be the light database manager of the new ipkg + other functionnalities
<Chocky> any kind of SQL implementation sounds awfully heavy handed for a package manager
<cam|cam> A software with a lot of bugs is a software that is not easy enough (in its source) to let people like me work on it
<pb_> so, what you\'re saying is that you are only prepared to debug software if it doesn\'t already have bugs?
<cam|cam> sqlite library is 200 ko
<cam|cam> pb_: yes ;D
JimButton (lukas@pm478-03.dialip.mich.net) has joined channel #debian-arm
<pb_> sigh
<cam|cam> pb_: do ipkg tools have a kind of easy way of building package? I mean something like : \'ikg --rebuild xxx.src.ipk\'
<cam|cam> pb_: I was thinking of completely revamp ipkg because Harlekin said that we should
<Chocky> this sounds like an ill-considered and ill-defined mission
<pb_> cam|cam: well, let Max waste his own time. I don\'t think there is any benefit at all in throwing out ipkg altogether just because he doesn\'t like it.
<Chocky> A lot of thought has already gone into ipkg and friends
<Chocky> There will always be someone who doesn\'t like a given bit of s/w
<Chocky> sigh
<Chocky> I wonder if the compiler version change is stopping the serial port working
<cam|cam> At present, software installation + uninstallation can be done with ipkg (ipk as deb). I didn\'t found any way to manage easily the software construction
<cam|cam> And there\'s always someone on the mailing-list complaining about ipkg bugs
<pb_> Yeah; ipkg and dpkg don\'t really have any direct equivalent to .src.rpm.
<pb_> cam|cam: well, yes, but there is always someone on the mailing list complaining about kernel bugs as well, and we are not proposing to throw away the kernel.
<pb_> The way to get these things fixed is to file coherent bug reports in bugzilla.
<cam|cam> In fact... yes... it could be good to throw away the kernel too.
<cam|cam> What I mean is that the 2.6.4 is interesting as it include all ARM patches and
<cam|cam> is waiting for specific familiar patches (and other drivers)
<Chocky> familiar is user land, why would it have kernel patches?
<pb_> I think he means iPAQ-specific patches.
<Chocky> guess so
<cam|cam> What I mean with patches is \'sending 2.6.4 kernel drivers to www.arm.linux.org\' so he could include them in 2.6.5
<pb_> Right. Unfortunately it\'s not quite that easy, because most of the necessary drivers just don\'t exist for 2.6.4 yet.
<cam|cam> Do you know if this is planned?
<pb_> If you build a 2.6 kernel for ipaq, even from handhelds.org CVS, it will be missing an awful lot of features compared to 2.4.
<cam|cam> (yes
<pb_> Yes, but as ever it\'s a matter of time. Maybe you would like to help.
<cam|cam> Yes too.
<cam|cam> Certainly for iPaq 3870, Yopy, and Zaurus SL-C760.
<Chocky> pb: have you had any problems with GCC 3.3 miscompiling kernels?
<cam|cam> I\'m reading a book about kernel developpement
<Chocky> problem with such books is that they tend to be out of date very quickly indeed
<pb_> Chocky: nope, certainly not recently.
<cam|cam> Chocky: yes. It\'s about 2.4 kernels (and some part on 2.5 )
<BlindMan> re
<cam|cam> So simply using ipkg and building an easy way to compile all familiar applications could fill my needs in your opinion?
<pb_> hi blindman
<Chocky> we don\'t know what your needs are
<pb_> cam|cam: yes, and openembedded might fulfil the building part of your needs.
<cam|cam> Needl definitively to browse their source.
<cam|cam> Chocky: Debian light but complete compatibility + easy package/build/repository management with 2 tools (ipkg, ipkg-build) + PIM
<cam|cam> Read here to read the full story:
<cam|cam> http://www.zaurususergroup.com/index.php?n...3040&highlight= (https://www.oesf.org/forums/index.php?showtopic=3040&highlight=)
<Chocky> yes, yes
<Chocky> it\'s all very well saying \"we should all focus in the same direction\"
<Chocky> but eveyone has different ideas on what that directin is, and how it should be done
<BlindMan> *gaehn*
<Chocky> the point of emdebian is to leverage the existing Debian stuff, but make it smaller. That\'s largely a social engineering excercise, not a technical problem
<BlindMan> oops
Signoff: pb_ (\"Client exiting\")
Chocky wonders how pdaxrom is relevant to RiscPCs
<cam|cam> As soon as all packages are there, that you could build your own rom and that there\'s no cut in freedom to use one package or the other (as long as dependancies are met) I don\'t see where is the problem.
<Chocky> the problem here is that I don\'t see any kind of cohesive focus.
<cam|cam> And if someone want to use something else, there\'s no problem.
<cam|cam> If I build a dependancy list and all distribution use it, the goal to have interoperability is winned
<cam|cam> s/winned/reached/
<Chocky> I\'m really not sure where this is going. There\'s already plenty of interoperability
<cam|cam> (I forgot about the toolchains version and libraries)
<cam|cam> What is good is to know that your software will always work whatever distro you want to install
<cam|cam> (and without recompilation)
<cam|cam> (or static build)
<Chocky> toolchains are mostly a distinct issue from Debian issues
<cam|cam> I was thinking about Debian just because it\'s a complete user drived distribution
Chocky tires of this. is there a point you wanted to make?
<cam|cam> Redhat Netwinder could also fill the gap
<Chocky> that makes no sense
<Chocky> RedHat ARM is a desktop distribtuion, and has nothing like the support or packges or up to dateness of Debian ARM
<cam|cam> Do you understand now why I prefer Debian?
Chocky didn\'t need to understand it
<Chocky> I just don\'t know what you\'re trying to achieve with this dicussion
<cam|cam> Just to say that I\'m asking for something that should see the light. Ok. Acknoledgment
<Chocky> whose light would it be?
<cam|cam> Linux on all PDA. Any user using it. Full Debian package paradize.
<Chocky> as I said, this conversation is going nowhere. you\'ll understand if I don\'t reply any further
<cam|cam> Easyness, powerful tools, open source,
<cam|cam> Ok. I\'m understanding.
<Chocky> I don\'t think you are
-
Here is an extract of a conversation on #arm-debian IRC. I have only one question: am I crazy asking for this group work? Is the Debian people contaminated by something?
Basicly, yes you are crazy, because this is what the community wants. Maybe this makes sense to you but not to me or obviously a few others. I like to have several options to chose from that vary greatly in form and function, thats what makes the Z appeal to me. If I get bored with one or the other has a app that I want to use I\'m free to switch.
If you want a static consistent platform to develope with go to Palm or Pocket PC.
-
What I still don\'t understand is why this kind of Linux distribution could prevent you from switching to other OS or ROM?
This thread is nothing more than a call for participation to a global project. It\'s a call for all people whose have the same dream and whose want to take part in it.
All other who don\'t like the idea already know that they can use every distro or rom they find out there to feed their zaurus.
Same strange idea for Sharp. Why should we care about how they would like the Zaurus OS to be or about their \'commercial strategy\'. They do what they want and you do what you want. As soon as this project will produce an OS that fill own common needs, I can\'t see what could be the problem ((feel free to not feel concerned if you don\'t like the community OS idea).
If the project is driven by a strong community, I can understand that it could scare you. It could be the case if you like for exemple a little rom that will perhaps die because of lacke of user support. Same problem for companies working in the embedded area that could see in it some kind of \"loose of control\". It\'s evident that for some of them It\'s better to freeze this initiative (note that I used plural for companies).
Who want a powerfull embedded operating system for their PDA?
I read padishah_emperor message saying that he wants a powerful tools and not a PDA. Again, where is the conflict with a community project that (1.) will build a powerful device operating system (2.) will build a powerfull applications for PIM management (3.) will let you do whatever you wants (as you will still be free, won\'t you?).
Ok, let\'s start talking with the ones whose are interested. Do zaurususergroup.com or www.killefiz.de/zaurus/ webmasters like the idea? What could be done? Someone else have ideas about what could be added to have something rock solid?
-
I actually think we already have a strong community.
-
Oh and if you want debian on a Z then look here: http://people.debian.org/~mdz/zaurus/ (http://people.debian.org/~mdz/zaurus/)
Needs some more work, but that seems to be the direction you\'re looking in. I think you\'d be better off with OZ (for Qtopia style ROMs) or pdaXrom (for X11 roms) though rather than trying to move debian over again (OZ is debian based after all). Just my opinion.
Some background on why ipkg is a \'lesser program\' than dpkg :-) http://www.handhelds.org/z/wiki/iPKG (http://www.handhelds.org/z/wiki/iPKG)
Simon
-
BTW are you a subscriber to the debian-handhelds list?
If not it might be worth your while.
Si
-
Ok, let\'s start talking with the ones whose are interested.
..and to hell with everyone who disagrees?
I actually think we already have a strong community.
I too think we have an excellent community, great people, a great choice of ROMs, apps, projects, programming frameworks, Amrein I really must take issue with you, we\'ve fought this battle in 3 or 4 threads now and I will keep fighting for the diversity and choice we have, you have a singular vision, one idea, one goal and that is to make my handheld Linux workstation as useless as a PPC or Palm.
I think pulling everyone together on one course, your course, would be the end of the Z, it will fragment the community right down the middle. If you want a strong PIM platform, you have it already, it\'s called PalmOS. If you want to locked into one man\'s idea of what a handheld should be, you have that too, it\'s called PocketPC or something.
We could probably use a bit of reformation, some projects could be merged, some abandoned, but keep the diversity, let people decide what they want on their Z.
-
lardman
Oh and if you want debian on a Z then look here: http://people.debian.org/~mdz/zaurus/ (http://people.debian.org/~mdz/zaurus/)
Needs some more work, but that seems to be the direction you\'re looking in. I think you\'d be better off with OZ (for Qtopia style ROMs) or pdaXrom (for X11 roms) though rather than trying to move debian over again (OZ is debian based after all). Just my opinion.
Debian fusion with pdaXrom or OZ. It\'s exactly what I was talking about.
Some background on why ipkg is a \'lesser program\' than dpkg http://www.handhelds.org/z/wiki/iPKG (http://www.handhelds.org/z/wiki/iPKG)
ipkg is a light fusion between apt-get and dpkg. Exactly the kind of tool that is necessary for this fusion.
padishah_emperor
Keep the diversity, let people decide what they want.
Of course people should have the choice. Building something is also a way to decide what we want. Thanks for your intervention dhns, w14, ScottYelich, (... and other people in other threads) I know that I\'m not alone.
Anyway, if no one want to defend this idea of Community OS for PDA it won\'t work. If you are desagree with lardman, tapjpa or padishah_emperor, just say it. And if possible, louder.
---------------------------------------
\"First they ignore you, then they laugh at you, then they fight you, then
you win. We should be near to win.\"
(Mahatma Gandhi)
-
There\'s also some work for own great sites ZaurusUserGroup.org and www.killefiz.de/zaurus/ :
_ list tasks that need works and ask for package maintainers like on Debian. I\'m talking about the wall purged application ipkg set and not the base system. (ZaurusUserGroup.org)
_manage the default applications construction (PIM, ...) in the present community.zaurus mirror. (ZaurusUserGroup.org)
Note: Those default applications need to be defined.
_ manage, if they want to and if it\'s possible, some more open source projects (separated from default one).
_ list all available software, have screenshots, ... (www.killefiz.de/zaurus/)
_ zaurus forum, zaurus faq (to revamp), ... (ZaurusUserGroup.org).
That\'s it! Someone agree or disagree? ZaurusUserGroup.org or www.killefiz.de web master?
We\'ll do whatever we need to with the ZUG to support this effort.
-
I think amrein has the right intentions. There are a limited number of active developers for the Z. If you think the community is healthy, then ask why OZ would need help and why they didn\'t get it. There just aren\'t enough active developers out there. Pooling resources and putting out a strong OS and strong apps would be the best thing. A proven mature ROM would bring more people into the community. Once the community is heathier, then variety would naturally follow.
I just think don\'t think the more active developers (cacko and OZ) would agree with amrein\'s proposed plan.
-
Couldn\'t agree more to bluedevils. We have a misratio of developers to users in Linux-PDA-land and consolidation (in one way or another) is in my opinion the only chance for a couple of important projects to survive.
-
Couldn\'t agree more to bluedevils. We have a misratio of developers to users in Linux-PDA-land and consolidation (in one way or another) is in my opinion the only chance for a couple of important projects to survive.
Great!
So we WILL be limited in choice, Amrein, I\'ve noticed your postings seem to be either to criticise, complain, point out different hardware or software than the Z, I do not believe your intentions are good for the Z. Are you working for Microsoft?
OK, let\'s have a survey as to who wants to downgrade to a locked down PIM PDA or keep the Z as a flexible workstation which can fit in the pocket, and if the majority wish to go with Amrein let them, I will start an alternative arena for those who disagree.
Instead of trying to damage the community by blind consolidation and inhibiting choice, why not focus your obviously abundant energies in trying to improve OZ or pdaXrom? Why not just write the kind of PIM apps you want and a platform independent sync? It\'s just a smack in the face for all the people who have put so much effort into not only producing but developing and moreover using OZ and the QT ROMs.
-
Padishah,
Please do not go ballistic as your posting implies. We are merely trying to discuss what we think we need to do for the community to thrive. As I stated before, variety of OS and apps will come with a thriving community. You cannot speak for the OZ team, because Mickeyl has also voiced his opinion.
-
Padishah,
Please do not go ballistic as your posting implies. We are merely trying to discuss what we think we need to do for the community to thrive. As I stated before, variety of OS and apps will come with a thriving community. You cannot speak for the OZ team, because Mickeyl has also voiced his opinion.
I honestly did not know Mickeyl spoke for the OZ team.
I\'m not going ballistic, ;-) I just don\'t want the choice and flexibility we currently enjoy being culled for good intentions or bad.
Maybe something gets lost in translation whenever I talk to Amrein on this issue (and we have been through this before) but I do not share his dream of a locked down Linux based PDA, i.e. a Palm type system heavily leaning towards PIM functionality. To me it\'s a severe downgrade and a restriction of choice. Why not fix what we have?
That\'s my view, but it would seem I am in a minority..
-
I\'m not going ballistic, ;-)
Then I apologize.
-
I do not share his dream of a locked down Linux based PDA, i.e. a Palm type system heavily leaning towards PIM functionality.
I really don\'t see why it would be \"locked down\" the source would be there to view, amend and contribute to. Why can\'t you have the best from all roms in one rom? Why does having good pims mean you can\'t run Apache webserver?
The reason why palm based systems are \"locked down\" is due to the o/s not being open source not because they have good pims.
Too much effort is being wasted by duplication as mickyl has pointed out countless times.
The words \"locked down\" and \"linux\" do not belong in the same sentence, it is an oxymoron.
Peter
(who\'s currently really happy as Leeds are 2-0 up on Leicester)
-
The words \"locked down\" and \"linux\" do not belong in the same sentence, it is an oxymoron.
It was intended to be
:-)
-
Before anyone else says it, I vote for KOPI (and KABC if it gets done) as the PIM for whatever platform it may be.
-
I just don\'t want the choice and flexibility we currently enjoy being culled for good intentions or bad.
Maybe to help further your argument, could you articulate what choices and flexibility we currently have?
IMO we do have several ROM choices, but OZ and PDAXROM are the only true ROM development efforts for the Z. The rest are simply hacks to the Sharp ROM.
...but I do not share his dream of a locked down Linux based PDA, i.e. a Palm type system heavily leaning towards PIM functionality. To me it\'s a severe downgrade and a restriction of choice. Why not fix what we have?
I can\'t see how consolidating development efforts translate into a \"locked down Linux based PDA\". Am I wrong in thinking that because both OZ and PDAXROM are both \"open\" that any combined effort would also be \"open\"?
Besides, I think we will always continue to have the Sharp dirivatives. There will always be people who want to hack/fix the Sharp ROMs. But IMO the development effort for hacking a Sharp ROM is much different than with developing for OZ or the PDAXROM.
-
I find this discussion a little scary, to be honest. I don\'t know about a \"typical\" user, but I want a mobile computer. I sometimes use the PIM stuff but it would never sway my buying decisions. I need to edit text (Word is nice but any text editor will do for me); a spreadsheet app of some kind is a must; and a platform of some kind (JEODE is fine) to load my own programs in some language. The more choices of connectivity (with and without wires), the better.
Now, what I don\'t like doing is changing ROMs every - well, ever! I upgraded to Sharp 3.1 because it seemed like I was being childish not to, but I held my breath the whole time. I want a stable OS that I don\'t have to upgrade more frequently than ?yearly?, and then with as little messing around as possible (the Sharp loader from the PC with the cradle suits me JUST FINE).
Am I odd man out?
-
Now, what I don\'t like doing is changing ROMs every - well, ever!
In that case, you might be interested in a side project I\'m working on. I\'ve put together a system for booting an alternate rom off an SD card. Therefore, you can keep a Sharp-style rom installed for maximum compatibility, but also boot something like OZ from your SD if you want to try it out. See my \"Dual Boot\" thread in the OpenZaurus forum. What I\'ve got currently posted is for the sl-5500 only, but some others were working on getting it ported over to the other models (5600, cxxx series, etc).
I\'m working on the final version of the scripts, but the initial version I posted in that thread seem to work ok. Just gotta make them a bit more user-friendly, and edit the docs down a bit.
-
See, I\'m pretty sure I\'m incapable of holding down the C and D keys simultaneously, not to mention pressing that tiny button under the battery at the same time.
-
I find this discussion a little scary, to be honest. I don\'t know about a \"typical\" user, but I want a mobile computer. I sometimes use the PIM stuff but it would never sway my buying decisions. I need to edit text (Word is nice but any text editor will do for me); a spreadsheet app of some kind is a must; and a platform of some kind (JEODE is fine) to load my own programs in some language. The more choices of connectivity (with and without wires), the better.
Now, what I don\'t like doing is changing ROMs every - well, ever! I upgraded to Sharp 3.1 because it seemed like I was being childish not to, but I held my breath the whole time. I want a stable OS that I don\'t have to upgrade more frequently than ?yearly?, and then with as little messing around as possible (the Sharp loader from the PC with the cradle suits me JUST FINE).
Am I odd man out?
You have probably described what I feel. PIM use really is a convenience for me, not a necessity, not to the point where we need a whole new project/ROM or whatever the case may be.
Besides, I think we will always continue to have the Sharp dirivatives. There will always be people who want to hack/fix the Sharp ROMs. But IMO the development effort for hacking a Sharp ROM is much different than with developing for OZ or the PDAXROM
Point conceeded, I worry that this project could pull people away from developing for Sharp/Qtopia.
-
I wasn\'t going to add to this thread as I do sit in both camps.
People develop apps/roms for different reasons. Some do it for the kudos, while others do it for themselves first and then release it to the community to save others the pain.
Competition can be good for development, but working together can be better. But this only works if people share common goals and ideas and are willing to share knowledge fully without fighting over petty things.
Could you imagine proto and sash working together on a kick ass qtopia rom? Although some may say they have been working on the same rom.
I don\'t mean to stir up bad topics and I certainly don\'t want this thread to turn into a \"my rom is better than yours\" debate as I feel that we do all need to work together, the user/developer base is too small to be fighting or redeveloping the same stuff over and over.
I totally applaud Mickyl\'s philosophy on this. He is willing to do this and for the right reasons.
Look what 2.5 people have produced! imagine what ten people could produce in the same amount of time.
I can see what you are afraid of, you don\'t want a \"jack of all trades master of none\" but it doesn\'t have to be this way if people work together effectively, even if you have to \"dual boot\" to achieve everything it would still be worthwhile, just having one build system would be a major start.
Imagine a rom which will run x apps seamlessly with qt apps. This is almost possible now but needs a lot of work to achieve and isn\'t really seamless, if you could get this with one rom then it would change a lot of things.
It would also cut down a lot of wasted effort in compilation, which in turn cuts down on user confusion. How many different versions of each application are floating around? how many times has a \"newbie\" installed the wrong version and had to reflash/restore his/her zaurus because they installed an incompatible version of an ipkg, I know I have and I don\'t consider myself a newbie.
Does this help in the amount of people buying a zaurus? There is a lot of confusion about at the moment, I see posts from people who think they can install either oz or the pdaxrom on an sl6000. Just because you know which ipks to install on which rom doesn\'t mean that joe public does.
We do need the new users, as they could be tomorrows developers.
This is also not a \"susie v mandrake v redhat\" thing either, these systems can survive while competeing as the number of pc users installing linux is massive compared to the number of zaurus users.
I noticed you added the smiley, and I am glad you did as I don\'t want to make enemies here
Peter
-
I\'m not sure why I\'m weighing in on this topic but here goes...
I haven\'t followed the other development projects closely, but I have stood back and watched OZ/OE for over a year now. They\'ve had their troubles but I see definite progress. Communication to the end users has improved. The Wiki\'s are letting the OZ/OE community help each other out. And I see a LOT of work being done by a few core developers.
In the last week, I loaded up a new Linux box (last one died horribly) and started playing around with OE. I don\'t understand all of it but I know potential when I see it. I\'m trying to learn OE and be a contributor to the OZ team. Why? Because these projects are complex. I may not agree with everything Mickeyl and Kergoth and company decide upon; However they have put a very precious thing on the table...developer time (and a LOT of it). And they need a lot more developer hours to deliver on the next-gen OZ image.
Amrein, I\'ve seen your commentaries on the OZ lists over the months. You are entitled to your opinion. You are certainly entitled to start yet another Zaurus ROM project (we are speaking of Linux after all). BUT I doubt you will get too far, or if you do you won\'t achieve your goals quickly. I have to agree with another poster on this thread: there aren\'t enough Zaurus developers to go around, especially kernel developers.
I was dabbling in apps for the Newton when Apple pulled the plug; It was heartbreaking to have zero tool support for a superior PDA (unmatched by anything, including Zaurus I\'m afraid). That was when I vowed never to buy an Apple product (ever). I made my mind up then that my next PDA needed to be Linux based since Windows CE was and still is a POS. Sharp has effectively pulled their developer support away from the community. We are lucky that there are some dedicated individuals keeping the Zaurus projects alive. Why not support what we have? Either support the OZ/OE developers or support one of the other existing projects. I seriously doubt that yet another Zaurus ROM project needs to be started.
Just my $0.02,
Kodiak25
-
I don\'t know by OZ/OE is not so atractive for new developers. But I agree with Kodiak25. I think tha OZ/OE is the BEST option (at last as start point for a new ROM). OZ/OE is the more open ROM in the zaurus field, so it is *our* ROM!! It is for the comunity and we are part of this comunity.
-
I\'m still not sure, we need to flesh out what we are talking about, a combined OZ/pdaXrom? Would sashz go along with that? Amrein does not want to discuss it off-thread, so I ask him again to be specific in what he wants here.
Amrein, are you proposing a \'fusion\' of OZ and pdaXrom? What hardware will you be looking to support, are we going to cut-off 5x00 users? Who gets the right to make that decision? What about the end-users, and some have voiced concerns as I have, will I be able to run Hancom Word and X simultaneously running GIMP for a bit of image editing while listening to a few albums on tkcPlayer?
I\'ve given this matter some further thought, I can now see **some** merits to the arguements proposed, but I still see problems and the worst outcome would be a ROM which is no better than OZ and pdaXrom now. But, since I prefer Qtopia ROMs/XQt anyway, I guess this project will not affect me, but I have the right to voice my concerns anyway, especially as this **could** divert precious developers away from Qtopia to this new thing.
-
What\'s wrong with the common distribution we already have, called OpenZaurus (openembedded)?
-
There is nothing wrong with the distros or projects themselves. It is the lack of resource to timely put out a mature/refined ROM that may be in question.
-
I\'m still not sure, we need to flesh out what we are talking about, a combined OZ/pdaXrom? Would sashz go along with that?
we have full functional ROM with stable base and good buildroot, we have own site, feed, for what we need in combination with OZ/OE? Maybe later we will add suport for running apps from our feed in Xqt.
-
Hi sashz, you do great work, thanks!
Are you in support of amreins proposal then, your reply seems to indicate you are happy with the current setup for pdaXrom? You say we have a fully functional ROM, base etc. But at the same time you mention combinination with OZ/OE?
I wish my programming skills were better, I\'d love to get really involved in this stuff.
-
I think sash is saying that pdaXrom is fine as is and there is no need to be involved with OE/OZ
-
What could be a big mistake is to think that I\'m the only one wanting something here. If those discussions fail, it\'s all people whose agree with the idea whose will be disappointed (and not only me). I don\'t have a miracle solution under my hat that will prevent discussion, conflicts or clashes. What this thread is all about is build a community linux for our pda and not about a new amrein rom (More than this, this name doesn\'t sound good :[
To be clear and to enter in the real discussion:
We don\'t need to reinvent what is already available. Most components are already there. What is needed is a thought of the community and more important of the ROM builders about how they could work on the same base system. The same way Gnome and Kde share X11 and some other desktop rules, the same way we could build ipks+dependencies that match and could be installed on any new wacky rom.
What do a system need to work and be compatible with another:
1 _ same gnu libraries and tool-chain (we should agree on the ones to use, be able to patch them on a centralized site for everyone, construct common tool-chain and sdk, share documentation for shared components)
2 _ need to use the same or a compatible package format (deb and ipk are completely compatible as the last one is based on the first. Ipkg program haven\'t reached version 1.0 at the time of writing and still have bugs)
3 _ matching dependencies in packages is mandatory (with Debian compatibility, this open the wall Debian repository without the need of manually unpack or rebuild anything).
4 _ compatible init script and low level tools for hardware management (example: you want to beam an entry or you need to connect to your bluetooth gsm or you connect a new wifi card).
It\'s exactly what could be done on a PC running one distro on which you want to install a new package. It\'s also why we could found some compatibilities between Qtopia roms and derivative. Other example: it\'s like installing GPE Opie or Qtopia on top of Familiar.
Familiar or OE/OZ are already based on Debian. Debian is the base system and have all Open Source package of earth today (300 000?). For people whose have already play with Familiar and are asking “So why don\'t we use Familiar?â€, they should have also noticed that its main problem is the build system: It\'s a mess. OE or pdaXrom build system have been the answer to this and have completely overtaken it.
To be able to use all components of Debian is very important because it\'s the best way to be able to install any existing open source software from its repository (as long as you have disk space). In this perspective, ipk packages are there to save space. They are some kind of \'deb light packages\' or \'pda specific packages\' built to fit in pda environment (320*240, 640*480, ram, flash, speed constraints...).
More than this, Debian give us build tools, cross-compilation, automated build and test tools, docs and rules:
Developer reference : http://www.debian.org/doc/developers-reference/ (http://www.debian.org/doc/developers-reference/)
Debian Policy Manual : http://www.debian.org/doc/debian-policy/ (http://www.debian.org/doc/debian-policy/)
Docs Index : http://www.debian.org/doc/ (http://www.debian.org/doc/)
It\'s time for rom builders to talk about what they should do to standardise the base system and to prepare what will come. The packages list and dependencies that should be build for Debian compatibility is based on debootrap packages. The base system should be built with packages split (for example i18n, locales, man pages, low used components...). If you are agree, I\'m sure that people (and I\'m in) will help you about this also.
What is missing at present in pdaXrom and OE/OZ:
_ the ipkg dependency structure.
_ the share of the tool-chain, libraries
_ the share of the same init scripts.
_ the menu + icons + themes structure (same as on PC).
Debian uses an unique tool to build menu item for all windows manager and this tool should be used. At present, pdaXrom can\'t use Qtopia packages and Qtopia can\'t use pdaXrom packages. In the future, pdaXrom will certainly have a working qte/x11 library and Qtopia will have a working x/qt in rootless mode ( as it is more like a hack at present and is not really usable or convenient for a newbie).
So at present, most components are there and need to be polished. If you are part of the ROM builders, following the base system rules will give you the opportunity to be able to build something completely compatible with anything that already exist. If you want to use Qtopia tools and libraries or X11/QT/GTK tools and libraries, it won\'t prevent you from been able to run it on any rom. It approximatively what Mickey has tried to say differently several times: those projects need help. This time, whatever you do for them, your work will always be useful. This community project with its tools (sdk, docs, ...) is the best way to open your imagination to any working and useful project.
Note: no need to use one build system as long as the base package are identical and respect Debian dependencies (and future Rom builders agreement). I\'m sure that \'the build system\' could have been a louder clash.
Note 2: as a kennel for your dog, it can\'t be built if you don\'t want it. As I say, this could be a flop if a system like this doesn\'t interest the community.
Note 3: people like me whose are not Linux guru are waiting for general plans from leaders. As any plan when you have the choice, we will be happy to follow what we feel could be in our interest. Rom builders and web masters, it\'s up to you.
-
A real OZ/OE developer (not a wannabe like me) would have to weigh in here as to whether pdaXrom and OZ/OE can coexist somehow in a ROM image. I would guess that X should be able to live on top of the Qt framework with a translation layer if OZ is the base. The bigger question is the size of the ROM image. 5500\'s are kinda cramped for space.
Kodiak25
-
Amrein, thankyou for being more precise. I\'m pretty ok with that, especially as a new Debian convert, yep, you\'ve persuaded me, as long as we don\'t shut out 5x00 users. If I can run Qtopia and X apps at once, I\'ll be happy, I\'m learning QT right now so I can pitch-in.
But can you persuade the developers?
-
Very good question. The big discussion is between pdaXrom, OE/OZ teams and other rom builders like tkROM team in fact.
The bigger problem is that every team could think that they are building THE rom that will completely grab user attention and forget about user needs. Rom builders need to think about the advantage and disadvantage of a common base system before accepting this \'effort fusion\'.
Exemple:
_ pdaXrom team could think that they only need to provide one big ipgk (or several little packages definition) with all debian dependencies and add qte/x11+qtopia compatibility so they could be the one.
_ OE/OZ team could think that they just need to change a few dependency names into their build system and add x11/qt in rootless mode.
But no distribution compatibility. A lot of work on different sdk, different docs, different feeds, different script...
pdaXrom 1.0.5 is out. This make them to lead today. Will they concider this plan and speak with OE team before OE/OZ overtake them someday... and so one? I can\'t answer to this.
pdaXrom team, OE/OZ team, tkROM team, ... have you make your mind?
-
pdaXrom 1.0.5 is out. This make them to lead today. Will they concider this plan and speak with OE team before OE/OZ overtake them someday... and so one? I can\'t answer to this.
I think this is unfair. PdaXrom is a better X system quite true as the X libs haven\'t been completely merged into OZ/OE yet (but the X and GTK etc libs are in OE and ready to be massaged along) and therefore don\'t work. This is something which I was planning to look at - to give my 5500 (and from this the other machines too) the ability to run X ontop of the OZ base . That said OZ & Opie is a better Qtopia based system. Horses for courses.
It\'s time for rom builders to talk about what they should do to standardise the base system and to prepare what will come. The packages list and dependencies that should be build for Debian compatibility is based on debootrap packages. The base system should be built with packages split (for example i18n, locales, man pages, low used components...). If you are agree, I\'m sure that people (and I\'m in) will help you about this also.
My impression was that debian didn\'t have this kind of fine granularity in its packages - hence the not using .deb packages (as you get lotsa of extra stuff in them which people might not want filling up their precious space). This is mentioned in the link about ipkg which I posted.
Also note (from the same link - perhaps it\'s not true, I\'ve not dug too deeply into it) that the dpkg system, although the scripting is far better than that provided by ipkg (and I think ipkg is fine for everything I\'ve come across), it\'s very large as is the state info contained in the .deb files. This is a big no-no IMHO. Not everyone can affort to allocate a couple of meg just to house the package installation database (and I for one wouldn\'t want to). Basically this means that .deb packages would have to be split up and remade (into ipks ;-) - so you\'ve gained nothing IMO.
_ the ipkg dependency structure.
_ the share of the tool-chain, libraries
_ the share of the same init scripts.
_ the menu + icons + themes structure (same as on PC).
I think both systems support dependencies, but different ones which is linked to your second point about sharing the tool-chain and libs. I do think that merging the libs is a good idea - not least because then I wouldn\'t have to make two different versions of every command line program I use (for X and for Opie). I think of all the things you\'ve said this makes the most sense. Unfortunately common toolchains is more difficult - OZ supports many different devices, pdaXrom only supports the C machines (and because of this uses a toolchain which produces ARM5 code). I suppose if we moved to shared libs then there could be two toolchains - ARM4 (for ipaq, 5000d, 5500, etc.) and ARM5 (5600, C machines, etc.), but this is still not ideal IMO. I wonder just how much of an improvement ARM5 is over ARM4? Anyone?
Menus, icons, themes? This is a mute point IMHO. Assuming that you run the same WM on pdaXrom and in Xqt (in Opie) then you\'ll get the same icons, themes, etc. I\'ve no idea how Qt/E apps will be able to run inside pdaXrom - unless it\'s through the fb emulator (which sounds slow to me) or by recompiling (this is probably not what you want, but sounds like the best idea to me). I think you have to weigh up easy of installation against speed of operation + ease of use + size of installation (& extras needed to run a given app - Xqt for example).
There\'s more to say but my coffee\'s getting cold and I\'m getting RSI.
Si
-
I don\'t know. Perhaps the language barrier... I don\'t know.
_ ipkg is the tool that replace dpkg and apt-get. Why do you want to install apt-get? You want the busybox version perhaps? We don\'t need it but if you want it you will be able to install it. What is the problem? Freedom?
_ the granularity of Debian package is a work to do and not something that is just there to use without brain juice. See Debian documentation to see all default packages installed by debootrap. Here is a link to find how a long time ago someone has shrunk Debian to fit in less than 35Mo: http://staff.washington.edu/dushaw/psion/ (http://staff.washington.edu/dushaw/psion/) (no, I\'m not trying to introduce any company here). His script remove files. What I have proposed is to split those packages instead of deleting files and to let user install what they need and applications to be able to follow dependencies. Hard? A few discussion and people knowing Debian are enough to achieve this (say... less than one week?).
_ why are you talking about megabyte taken by Debian packages? If you don\'t have the space, why do you want to install them? Won\'t you be able to use only ipk? There also, I don\'t understand the problem. You should just remember that if you want something that is not in ipk feeds, you can use the wall Debian repository because all dependencies will be met. If you want to avoid using Debian package, you will be able to use only ipk (the base system is only built with ipk packages).
All those packages for my device.... this scare me but excite me too.
Read again my posts and if you find something that contradict what I\'m saying now, please let me know so I can explain it differently.
_ as soon as QT embedded X11 layer is done, anything from Qtopia can be run on X11. There was a port in process that has never been finished because of lack of interest. Whatever happen, the base system is not concerned about this QT/Qtopia/X11 but only by the dependencies and the fact that any graphical environment could use package from another.
_ Themes, icons, desktop files... some of them need to be used by both graphical environment. Sharing menu entries for example. Of course, this is needed only if a compatibility layer is there (with QTE/X11 and X/Qt)
_ Yes, the armv4 armv5 cross-compilation issue is a problem. I didn\'t think about it before I downloaded pdaXrom sdk. I don\'t know if a binary compiled for armv5 could be run on armv4 without problem. Even if it runs slower, I will be happy if the standard application are compatible (certainly not the kernel). If an expert has an answer about this.. ?
Note: at present we have the 5000 and the 5500 with a Intel StrongARM (armv4). The SL-5600, SL-C700, SL-C750, SL-C760, SL-C860, SL-6000L, SL-6000W with a Intel XScale (armv5). Note also that the SL-5600 is the only one of the armv5 family with 320*480 screen. All other use the 640*480 hi resolution Sharp screen. I will be happy to know that armv5 optimised apps can be run on armv4 processor.
-
All this time I\'ve been assuming you wanted to use dpkg (you say merge ipkg and dpkg together which I assume means to use some of the backend of dpkg...). Is this the case? If not then ignore what I say here.
_ ipkg is the tool that replace dpkg and apt-get. Why do you want to install apt-get?
I don\'t, I\'m quite happy with ipkg, I presume you\'re referring to someone else\'s message here.
_ the granularity of Debian package is a work to do and not something that is just there to use without brain juice. See Debian documentation to see all default packages installed by debootrap. Here is a link to find how a long time ago someone has shrunk Debian to fit in less than 35Mo: http://staff.washington.edu/dushaw/psion/ (http://staff.washington.edu/dushaw/psion/) (no, I\'m not trying to introduce any company here). His script remove files. What I have proposed is to split those packages instead of deleting files and to let user install what they need and applications to be able to follow dependencies. Hard? A few discussion and people knowing Debian are enough to achieve this (say... less than one week?).
Just as long as you accept that it won\'t be a universal pancea to just be able to install .debs (which I think can be done with ipkg now in any case), and that they will most probably require \'massaging\' to produce usefully small packages. My point was that if this is the case why not just produce .ipks of the packages in question as the work involved will be equivalent?
_ why are you talking about megabyte taken by Debian packages?
Not by the packages, but by the database which is the backend to the dpkg system - the bit which keeps track of which files have been installed where. To tell the truth this is second hand knowledge as I\'ve not got much direct experience of debian (other than playing with pocketworkstation and the ROM which I linked to on the last page). I quite agree that if a package is too big you don\'t install it, but if the database which keeps track of the installed packages is also huge this is a major issue IMHO.
_ as soon as QT embedded X11 layer is done, anything from Qtopia can be run on X11. There was a port in process that has never been finished because of lack of interest. Whatever happen, the base system is not concerned about this QT/Qtopia/X11 but only by the dependencies and the fact that any graphical environment could use package from another.
Agreed this will be nice, but even nicer would be to have native X for X based ROMs and native Qt/E for Opie/Qtopia ROMs - just seems that it will be faster and will have less overhead. I admit that this won\'t probably happen though for everything.
_ Themes, icons, desktop files... some of them need to be used by both graphical environment. Sharing menu entries for example. Of course, this is needed only if a compatibility layer is there (with QTE/X11 and X/Qt)
Agreed. This should be reasonably simple to fix - perhaps have a script called \'link-menus\' which makes symlinks etc.
_ Yes, the armv4 armv5 cross-compilation issue is a problem. I didn\'t think about it before I downloaded pdaXrom sdk. I don\'t know if a binary compiled for armv5 could be run on armv4 without problem. Even if it runs slower, I will be happy if the standard application are compatible (certainly not the kernel). If an expert has an answer about this.. ?
ARM5 instructions won\'t run on ARM4 hardware. Now it\'s possible that an ARM5 binary may be able to run on an ARM4 processor if it doesn\'t use any of the new instructions, I don\'t know what the new instructions are so I can\'t comment on the probability (but all the ones I\'ve tried haven\'t worked). It\'s also possible, so I\'ve read, to produce a kernel module (?) which will handle the unrecognised instructions and make the binary work though I don\'t think anyone has done this.
Si
-
Ok. If this \'Plan\' has interested rom builders, they would have already reply.
lardman, I won\'t reply to your post because your questions can find answers with some imagination and good sense. If you didn\'t want to imagine how to solve them, it\'s because you don\'t like the idea as the Rom builders.
A flop then.