[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Freedombox-discuss] What is Freedombox?

I understood that the GUI for all of these were to be coded in an HTML, or
other portable languages that would be easily ported to other platforms.
Was this an erroneous interpretation?  I believe anyone would want what we
could coded in a portable language, items like the control of the LED's
would be device specific and a common language would be best.  In this
approach anyone with the basic computer knowledge could evaluate the code.
I understand that you could 'hide' it from people not used to the applied
language but it could be called to a knowledgeable person to check it for
aberrant code sequences.

Having been involved in this type of application, it should not be too
strenuous to attain a high degree of the platform in a portable language
and only device specific code for smaller applications with their own API.
Of course this is a generalization.


On Sat, Sep 14, 2013 at 2:21 PM, Petter Reinholdtsen <pere at hungry.com>wrote:

> [Jonas Smedegaard]
> > I agree with above, but am converned with the high risk of
> > misinterpreting the "build the software needed" part:
> And I agree with your general message, but would like to comment on some
> of the details. :)
> > I believe strongly that the FreedomBox should not contain any code
> > written specifically for FreedomBox.  FreedomBox should consist only of
> > code already in common use among geeks.
> Well, some code will have to be written specificly for the FreedomBox,
> but we should limit it as much as possible. :)
> > As a concrete example, it worries me if a GUI is invented and promoted
> > as being the "Front End for Freedom Plug UI".  That might seem
> > compelling to deploy on FreedomBox, but wait a minute: when promoted
> > so directly at the FreedomBox project, it conversely means it is less
> > likely that other related projects, e.g. emdebian router projects or
> > Debian-based phone projects or whatever, would consider reusing same
> > tool for *their* projects, thereby enhancing the quality assurance
> > inherent in Free Software through the logic of "given enough eyeballs,
> > all bugs are shallow".
> Note, that after I had a look at the code, the plinth system seem to be
> quite modular and should not be hard to adjust to work also outside the
> Freedombox.  We really should aim to make plinth a generic web
> configuration framework and not only care about the Freedombox, for the
> reasons you have stated. :)
> > We shall eat our own dogfood. We shall only ship to our non-geek
> > friends what we use and trust ourselves, and only those parts that are
> > boring to us because they just work correctly all the time.
> As a guideline, this is a good idea.  But we are also breaking new land
> here, so we can not limit ourselves to only the boring parts. :)
> --
> Happy hacking
> Petter Reinholdtsen
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20130914/a49f5f50/attachment.html>

Reply to: