How Far Should I go?

Andrea Bolognani eof at
Mon Oct 17 05:01:00 EDT 2011

On Sun, Oct 16, 2011 at 09:20:29PM -0300, Rafael Ignacio Zurita wrote:

> On Sun, Oct 16, 2011 at 6:34 PM, Andrea Bolognani <eof at> wrote:
> > Reinventing the wheel is a good idea only if you are
> > absolutely, positively sure your new wheel will be at least ten times
> > better than the current state–of–the–art wheel.
> I am not an expert about if that applies in all the places and
> topics. Ask to the chinese people. Maybe reinventing the wheel
> is one way to know if something could be done better?. No all the
> things are understood before it is done and you test and modify
> the new thing for a long time.

That’s why I said reinventing the wheel is not a bad thing per se, you
just have to be pretty sure your new design is actually going to
significantly improve things in the long run.

You also have to take into account that you’re not “competing” with a
fixed design, but with something that is itself constantly improving,
thanks to the collaborative efforts of hundreds of talented developers.

So all I’m saying is, think carefully before you commit yourself to such
a huge undertaking. Maybe your time would be better spent improving what
we already have.

> > Linux is not a perfect, but it works pretty damn well; moreover, it is
> > developed by hundreds of really smart guys and supported by large
> > companies that use it as a base for their main products, which ensures
> > it will become better and better as time goes by.
> I agree. But Linux is not the only one and surely no the best of the bests
> for many things.

As far as Free Software goes, I think you’ll be hard–pressed finding
another OS that works as good on MIPS as Linux does.

FreeBSD, for example, doesn’t seem to have a proper MIPS port, which
means you would have to work much harder to get it to run on the Ben. And
even if you did that, would it actually buy you any advantage? Not sure
about that.

> > If you really want to create something Ben–specific, my advice would
> > be: don’t. Instead, use your time to improve the upstream situation
> > of the Ben, to take mainteniance burden off Qi as much as possible.
> I still think that embedded Debian or some similar embedded Fedora should
> be better than Openwrt or OpenEmbedded in many devices. For Ben
> I can not prove that idea yet,

I’m personally a huge Debian fan, and I would love to have it running on
my Ben. I haven’t been able to try it yet, but according to reports Debian
is more memory–hungry than OpenWrt, and given that the Ben has so little
RAM it might not be the best choice.

> but I do not agree that helping with upstream
> situation (I suppose that you are talking about openwrt)

Actually I was referring to upstream development of the software
components used on the Ben, like Linux or u-boot.

The more Ben–specific bits we can get into mainline Linux, for example,
the easier it is to replace OpenWrt with another Linux–based OS.

> is the best of
> the bests things to do for Ben. Help is the best thing. But, in my opinion,
> neither there is not a best OS thing for the Ben, nor a really good one
> for final users yet.

I agree with you when you say the current Ben OS is not ready for prime
time yet. But I think we can get there, if we focus on it.

The way I see it, efforts should be focused on two main areas:

  * Base OS: make Linux and the base components work great on the Ben, and
             feed all changes upstream;

  * UI/apps: build a great user–facing UI for the Ben. Pick a UI toolkit
             and stick with it: if none of the currently available cuts it,
             fix them; if that proves not to be feasible, build your own.
             Retool existing applications to use the chosen UI toolkit, so
             that the user experience is seamless.

Note that very little of this work would be specific to OpenWrt, or even
Linux: once you move to userland, portability is much easier to achieve.

Andrea Bolognani <eof at>
Resistance is futile, you will be garbage collected.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <>

More information about the discussion mailing list