Paul Boddie paul at
Mon Dec 10 17:57:48 EST 2012

On Monday 10 December 2012 20:08:41 Jiří Brožovský wrote:
> But to be serious, there are real problems. I don't know how to
> promote the NanoNote to people. The fact that the hardware is mostly
> open is cool but people are also asking about  features (what it can
> do and what software can be used on it). And there I see problems.
> The software is still half-baked. It looks like Xiangfu, David
> Kuehling and others are spending most of time in catching of the
> OpenWRT upstream and in fixing of regressions so they are not able to
> do improvements in software.

I appreciate the work done on OpenWrt, but chasing upstream for huge numbers 
of packages is just too much work unless one dedicates one's entire time to 
it. I'm not sure what the situation is with Gtk+ and Qt, but I found it 
frustrating learning about what the Gtk+ people have decided over the 
extended period of time that I have not followed their project, and Qt can be 
such a beast that it demands a significant investment to work with it 
effectively even though the project is reasonably well-managed during major 
release cycles.

So, I just decided to explore the Debian option, particularly Emdebian which 
is coming of age. This permits me to let others take care of the hard work 
packaging and building upstream software.

> There are problems with software inconsistenciy (several GUI toolkits
> ang graphical libraries, every application has different controls -
> even the NanoNote-specific ones like the NuPDF, the NanoMap and the
> imgv), there is no strategy how to work with media (and other) files
> (the file dialog points to the "~/ "directory: the first thing that
> one can see here is a bunch of .dot files...). New users can be
> confused by fact that they have to mount internal disk by hand. If one
> starts a shell from the Gmenu2x then the default directory  /usr/bin
> (and the user is "root" - so it is very easy to broke something with
> that setup, isn't it?).

What we see here is the conflict that always occurs with devices that can 
potentially run most software (subject to resource constraints) available for 
GNU/Linux: you can have existing applications and figure out how the user 
interface is best operated on the device, or you can sketch out a vision for 
how optimally designed applications should behave, probably enforcing a 
framework for those applications. The latter option usually seems like it is 
throwing away all the benefits provided by the software of the former option, 
but it doesn't have to be this way.

That said, following the latter path does involve work that either strips down 
and builds up applications to work in a different environment - I imagine 
that the NightSky program is a good example of this - or involves development 
of completely new applications, albeit not necessarily completely from 
scratch because libraries do exist for many areas separate from user 
interface considerations.

> I personally use the NanoNote on a daily basis (as a RSS reader, as a
> note taking device, as a calendar and as a music player). I still use
> a very old firmware (from 2011) without a WPAN support ( though I do
> have several Ben WPAN cards) because the new firmwares have broken
> other things that I use (I'm not able to fix these problems), for
> example. The WPAN development seems dead to me.

I can't comment on this, but I thought that the kernel support was being 
continuously updated.

> The SDK is continously changing (at the moment I don't have a working
> 32bit SDK that is compatible with current NanoNote software and
> buildings of it needs so much time) so if I will want to fix or
> enhance some software I have to rebuild it first. So I haven't ported
> or improved any piece of software for a very long time (I still have
> to finish the DopeWars and I wish to enhance the NuPDF with a search
> and a bookmarking somewhere in future).

I want to look into the Emdebian cross-building support. Currently, I've been 
satisfied with cross-bootstrapping and writing Python programs on top, but I 
will need to rebuild packages at some point.

> There are other confusing things:
> - it is easy to press something in the Gmenu2x and don't be able to return
> - no time/date indication in Gmenu2x
> - no screen blanking feature in Gtk+/Qt applications
> - no suspend feature (does it work in the last releases? I'm not able
> to activate it) and thus poor battery life (it is sometimes hard to
> explain why a device without wireless can't survive at least weekend
> when it is on - an old Nokia 770 can run about a week and much newer
> NanoNote can't survive a single day!)
> - no gui or dialog interface for wireless features (WiFi or WPAN)
> - sound in games (they are too loud)
> - no usb-disk mode (yes, the ethernet over usb is more powerfull, but
> it must be supported on both sides)
> The another thing is an inability to cooperate with other (less or
> more open) gadgets: there is no way how to connect the NanoNote to the
> FreeRunner/GTA04 phone for example. It is also hard to explain to some
> people.

It's instructive to consider the FreeRunner/GTA04 phone situation and how it 
now appears (to a non-owner and casual observer like myself) that QtMoko is 
becoming the most viable project in that space. I'm sure some people would 
prefer to run LXDE and X applications and try and use their phone like a 
conventional desktop computer, but I think that many people would now prefer 
a more coherent experience even if it means that their favourite applications 
need to be adjusted or ported to whatever it is that provides such an 

> Sorry for so long  and so negative post. It's just my opinion.

Personally, I think that the software has long been the sticking point for 
such initiatives. Some people may wish for built-in WLAN/GSM/3G support and 
USB Host mode, and these would be very nice, but it isn't as if there aren't 
valid use-cases for the NanoNote without those things. Meanwhile, devices 
like the GTA04 which does have such things (maybe not 3G - I don't remember) 
aren't magically flying off the shelves because of their presence in the 
specification sheet.


More information about the discussion mailing list