Cases ? geek stuff ? marketing !

Kristoffer Ericson kristoffer.ericson at gmail.com
Sat Dec 11 16:22:22 EST 2010


On Wed, Dec 08, 2010 at 07:47:16PM -0300, Werner Almesberger wrote:
> David Kuehling wrote:
> > Currently people have to checkout the full open-wrt toolchain and invest
> > some hours [...]
> 
> I think the whole concept of exposing regular users to this sort
> of build system, be it OpenWRT, OpenEmbedded, or whatever Debian,
> Ubuntu, Fedora, etc., do to go from sources to packages, is deeply
> flawed.
> 

Speaking with some experience I fully agree. The end user wants/needs
simplicity. Ive had numerous talks with users (about OE building) 
where I tried to guide them into compiling package X,Z,Y and it always ended with:
1) they fail (and bug me)
2) they make it 50% (and bug me)
3) they make it all the way but dont understand what to do next (and bug me)
4) they make it all the way and get everything working (<--never seen it)

People knowing what they are doing (or atleast custom to development ideas),
go directly to point 4 and only stop ask when stuff actually is broken.
Exposing the end user to deeper development processes is always a bad idea.
The people actually able to develope will find their way, the rest shouldnt
need to know.

> Not only is the overhead in terms of computing resources enormous,
> but users also get exposed to tasks and concepts that are
> basically distribution-specific internal plumbing. Furthermore, a
> build from sources has a lot more internal and external
> dependencies than the installation of a set of binary packages, so
> the risk of failure is higher.
> 

+1

> The only case where I saw this approach work was in Gentoo, where
> most of the ugly bits are hidden from view, making Gentoo look on
> the outside like your average binary-package-based distribution.
> Gentoo suffered (and probably still does) from the occasional
> unexpected dependency problem, though.
> 

Yes, reason why I switched to Arch, less of
"OMG Ive just overwritten gcc/glibc on a gentoo system with
crosscompilation libraries". Gentoo is a good idea with an impressive
solution, but for bleeding edge junkies like myself its a death trap.

> I've seen the "just make users build OpenEmbedded" approach fail
> horribly at Openmoko. Things there got a lot better once a group
> of developers was assigned to take care of the OE side and to
> produce a repository of binary packages as a result.
> 

+1

> These people also took care of adding new things to the build or,
> at least sometimes, of packaging stuff we wrote in Openmoko.
> 
> That was still a lot of work, but at least it was more contained,
> and it didn't drag everyone down.
> 
> 
> Fast-forward to the present. OpenWRT is capable of producing
> binary packages. Even better, there is Jlime, which is based on
> OpenEmbedded and thus has a *huge* collection of packages to start
> with, plus a nicer user interface as an added bonus.
> 

We are pushing patches into OE all the time and its really starting
to get easy to maintain.

> One can also generate a binary cross-toolchain for the host, which
> removes the dependency on OpenWRT/OE/etc. as a means to obtain the
> cross-compiler.
> 

Yes, we keep them on site for seperate download. 
They are also quite handy when crosscompiling kernels.

> Furthermore, opkg-cl can install packages into the cross-development
> environment. E.g., if my program needs SDL_gfx, I can just install
> the binary libsdl-gfx-dev package on my host, and then cross-compile
> my application.
> 
> There's also a system I used in my Openmoko days, called "myroot",
> which takes a set of binary packages and creates a rootfs from them.
> This made it very easy to have custom images. It shouldn't be too
> hard to adapt this system for the Ben with a package repository from
> Jlime or OpenWRT.
> 
> - Werner
> 
> _______________________________________________
> Qi Hardware Discussion List
> Mail to list (members only): discussion at lists.en.qi-hardware.com
> Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion




More information about the discussion mailing list


interactive