A Big Problem... (deleted)

[Cresho]

totally with you on this one.

[karlto]

Well said Meanie! I've been wanting to post something along those lines but not so good at explaining what I mean...

[lardman]

[My apologies in advance for this post - I know it's in the pdaXrom part of the forum and I know it mentions OpenEmbedded, but that's because I'd like to comment on the merging of sashz's work with ours.]

However, they should be working together to make a set of compat libs so one can install and run apps written for one distro on the other similar to the alien concept.

Unfortunately, there's not really enough room on the devices for this kind of thing.

With that said, changes (in libc, gcc, etc.) are not necessarily difficult to propogate (meaning that packages could be re-generated for each distro, etc.). The easiest way for me is to just run bitbake and have it generate all of the packages in OE automatically whenever we update libc (or gcc, or anything else for that matter.)

Although this does take time, it's completely automated, so you just issue a 'bitbake world' command and come back in a day or so (actually with ~5k packages, I think Koen said, it might now take a bit longer than that!)

I doubt we'll ever get sashz to move pdaXrom to use bitbake and the openembedded metadata, though both teams would benefit. The real issue about the transition, is that pdaXrom is written for the Zaurus (mainly - I have seen that there's an x86 version too, but I'm not sure how many changes are necessary to the metadata and build process to accomplish this) while bitbake/openembedded supports many different hardware types. This means that build instructions and the build environment has to be more complex than that for pdaXrom as there are lots of permutations.

Now there is an in-between option, to use OE for pdaXrom, but only to support the Zaurus machines. This would have the automation advantages, and would also be a start towards sharing the code between both.

Just my opinions of course. I welcome non-flaming replies,


Si

[pgas]

The pdaxrom builder is based on:

http://www.pengutronix.de/software/ptxdist_en.html

I'm not sure what exactly sashz has changed. (He also builds for phycore board and PS2 with it)

Basically I don't think sashz will change the way he builds pdaxrom either, or that openzaurus will go to ptxdist.....both "team" have a good knowledge of their tools and put lot of work in them. Recent history of cooperation also has shown the little "communication" problems that exist....

It's difficult to comment on how the functionalities of the 2 build systems differ as basically there are no (good or in-depth) documentation and features list for either system...

(OE has probably more meta-data, and more complex handling of dependencies, pdxdist is probably simpler and  more straightforward to use - I don't talk about using "make world" vs "bitbake world")

It may seems easier to put what is missing from pdaxrom in openembbeded but I think that it would mean for sashz to start and learn from the beginning a new build system, redoing what he has allready done with ptxdist (for instance I don't know if OE builds live cds or make distribution for x86, if target exists for the phycore board or playstation, I know it doesn't create an all in one native sdk)   and I 'm not sure if that what's he wants to work on....or if OE would be ready to accept the things he does the way he does them (for instance I don't know a full kde ipk would be considered as acceptable)

The opposite is also impossible, openembedded is used by a lot of developers working on different projects, have many packages and configuration that aren't in pdaxrom, it has a lot of infrastructure that doesn't exist for the pdaxrom builder (bug tracker, vc ....)

So unless people from the outside starts to work on bringing the 2 worlds together, there are 0 chances for this to happen. I'm not convinced that's so important anway...(though probably more "friendly" information exchange would be nice...)

Also I don't think that having binary compatible libs is an easy goal to achieve as in my opinion, part of the art of building a linux distro is to manage to have some things that work correctly together, so it would perhaps mean to use exactly the same set of configurations and patches for the 2 distributions ...hence making the same distribution.

A little bit of competition and to have the liberty to choose is not so bad anyway (save the insults), from a user point of view we want the best of everything but it's not allways possible.

[albertr]

Right to the point, pgas!
-albertr

[sashz]

why OZ/OE guys think their build system is best of the best and always want some must come on it? My pointview is they must come on pdaXrom/ptxdist build system.

[lardman]

why OZ/OE guys think their build system is best of the best and always want some must come on it? My pointview is they must come on pdaXrom/ptxdist build system.

Our points of view differ, but that is to be expected. I think the main reason, is that the bitbake/oe system can be used to build for a number of devices - whole range of zaurus, ipaqs, simpad, slugs, and more, without having to edit anything mroe than one config file (which says what the distro name is and what the machine is) - it all just works.

The question I was trying to ask is 'does the pdaX system also enable this flexibility without needing to edit much?' It may do, I don't know as I've not tried using it for a long time, but my impression was that the patches that were contained within it had to be tuned for each platform?

for instance I don't know if OE builds live cds or make distribution for x86, if target exists for the phycore board or playstation

Not sure about liveCDs either, however x86 can be built as far as I know. Dunno about the phycore board, though I understand there are targets for development boards so I suppose this is similar. I don't think anyone has tried adding the playstation as a target.

I know it doesn't create an all in one native sdk

It can create native SDKs.

or if OE would be ready to accept the things he does the way he does them (for instance I don't know a full kde ipk would be considered as acceptable)

Things will surely be accepted, however the fact that bitbake/OE supports lots of different archs means that the build instructions/patches must not be just for a specific platform. A compliant KDE .bb file (the instructions used to build it) would be accepted as long as it built, packaged and ran correctly.

Regarding the patches to the 2.6 kernel, my understanding is that rpurdie (RP) will implement them, but that, as with the rest of his work, he wants to have the changes accepted upstream. This means that specific coding/patching styles must be adopted. He said he'd work on it when he has time.


Si

[Gorth]

Coding, patching "styles" and arbitrary, inflexible constraints on submission and application procedures, or even asking questions suffocates creativity IMHO.  It also facilitates dictatorial pronouncements by those who create such self-serving constraints.
Economies of scale are not gained, but rather a significant population of motivated, creative contributors is disenfranchised.
It is antithematic to the open-source concept and stifiling to the emergence of creative solutions to erect gateways and filtering procedures that do not accept innovation contributions that fail only on presentation protocol.  
It's the ideas that count.  Development efforts should be flexible enough to recognize superior ideas and find a way to accept them based on their merit.
[I apologize if this is off-topic or presented in the wrong forum, but it needs to be said somewhere]

[sashz]

The question I was trying to ask is 'does the pdaX system also enable this flexibility without needing to edit much?' It may do, I don't know as I've not tried using it for a long time, but my impression was that the patches that were contained within it had to be tuned for each platform?

For add new system you need create target /etc directory and strartup scripts (or use one common from prepared etc and scripts) and write vendor rules file, which will finish build image procedure. There you can customize your target image.

For patches, there 5 types:
1) generic - for all targets (ex. patches/icewm-1.0.3/generic/*.{path,diff}[.gz|.bz2] )
2) by cpu architecture - appling for targets with this cpu only (ex. patches/icewm-1.0.0/arm/*.{path,diff}[.gz|.bz2] )
3) by fpu architecture - appling for targets with this fpu type only (ex. patches/icewm-1.0.0/arm-softfloat/*.{path,diff}[.gz|.bz2] )
4) by cpu + vendor - (ex. patches/icewm-1.0.0/arm-pcm027/*.{path,diff}[.gz|.bz2] )
5) by сpu + target_libc - (ex. patches/microwindows-1.0.0/sh4-newlib/*.{path,diff}[.gz|.bz2] )

[lpotter]

There's room for all build systems. There's more than openembedded and pdaxrom build systems out there and also more than just 2 rom image distributions. I use old buildroot for the Qtopia Trolltech roms. I prefer it over openembedded.
There's also other non free distributions as well.

Use what works for you.
Linux is all about choice, not getting tied onto only one 'thing'.

It's good to have more than one "rom", or gui environment, or build system to choose from.

[lardman]

Coding, patching "styles" and arbitrary, inflexible constraints on submission and application procedures, or even asking questions suffocates creativity IMHO. It also facilitates dictatorial pronouncements by those who create such self-serving constraints.
Economies of scale are not gained, but rather a significant population of motivated, creative contributors is disenfranchised.
It is antithematic to the open-source concept and stifiling to the emergence of creative solutions to erect gateways and filtering procedures that do not accept innovation contributions that fail only on presentation protocol.

I take umbrage at your usage of the work 'arbitrary' in this context. Afaik, the rules we're talking about are not arbitrary - they are there for a reason.

If you want to have work accepted by a project (this is on the assumption that you can't do everything yourself, if you can then it makes no odds what your coding style is), then you have to adopt some kind of style to ensure that others can actually understand what you've added. Hopefully most people will realise that the enforcement of guidelines will ensure that code is clean and understandable (as you're trying to add value for the other developers too.)

It's the ideas that count. Development efforts should be flexible enough to recognize superior ideas and find a way to accept them based on their merit.

Right, so let's say the ideas are out there and tested and have been seen to add value; therfore the way to have them accepted is to re-write them in whatever standard form is necessary.


Si

[lardman]

sashz - thanks for the explanation

lpotter - I agree, people should have choice, but hopefully there is also inter-working (is that a word?) between groups, as we are only a small community.


Si

[Mickeyl]

DISCLAIMER: Not speaking about OE or OZ or pdaXrom or even Zaurus here, but about the 'choice' thing among the Linux community in general, so please don't get my opinion in a wrong way.

When people are doing their prayer wheel telling about "who cares, it's better to have a choice", to me personally it always sounds like a cheap explanation for

 * lack of communication skills,
 * lots of duplicated work because of resistance to learn new things,
 * going the easiest way,
 * not taking the time to think out,
 * results that are just incomplete.

Choices are cool - no kidding, it's great to have 'em...

...but I'd gladly give up chosing between 10 crappy things when I could just take the one really cool thing out there.

I really wish we (all, me included of course) had a bit more of a collaborative sense in us. All the one- and few-man-shows in Open Source land are doing no good. And that's the major reason why we suffer in contrast to the commercial stuff.

[tg]

The *problem* is that we all very subjective and everyone has his/her own ideas about what is crappy and/or cool (ie it is clear that Sash thinks his buildsystem is cooler than openembedded while OZ team certainly does not agree). There is nothing wrong with this - open source is about choice (which includes choice of not thinking things through as Mickey or anyone else would like but reimplementing or reinventing the wheel - it is surprising how often this seemingly wastefull activity actually leads to improved projects and better code - sometimes things are improved that were not even originally intended). I actually think this is why Linux is so great - people constantly reimplement and look at things from different angles and you never know what will come out of all the chaos. I also think that some of the flame wars are not unhealthy as they show dedication developers have to their projects and points of view. And us as users are free to read them or not - sometimes reading through these carefully actually hints at which projects really are *better* and/or more likely to make it in the long run (isn't it great to have both gnome and kde - at any one point in time over the last 10 years you could have picked a point where one of those distributions fell behind in some ways - but supporters of both stubbornly kept pushing forward and today users have a choice of two excellent alternatives - that to me is the real power of open source - why can't something like that be the case with oz and pdaxrom?).
And while I'm ranting about open source let me also add that in my opinion people should stop focusing on how to defeat M$ and aruging that without unifying projects open source does not have a chance - this is counterproductive because once you accept this approach you are playing by M$ rules and you certainly can't win that battle).

[sashz]

...but I'd gladly give up chosing between 10 crappy things when I could just take the one really cool thing out there.

What is crap and what is cool? Who willl judge?