Re: [WikiReader] Giving, and last chance to get?

2013-05-24 Thread Doug Jones

On 05/24/2013 12:21 AM, Patryk Benderz wrote:

Dnia 2013-05-23, czw o godzinie 14:19 -0700, Doug Jones pisze:

I just got an email from Sean recommending this:

http://igg.me/at/wikireaders4kids/x/3095893

26 days left to end of campaign?! Is this a joke? There is no chance
they will raise 232k$ in 26 days...



You may be right about that.  But with an Indiegogo Flexible Funding 
campaign like this one, they collect the pledged funds even if they 
don't hit their stated goal.  So they've already got enough for over a 
hundred WikiReaders.


Sometimes these things accelerate a lot.  We'll see.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[WikiReader] Giving, and last chance to get?

2013-05-23 Thread Doug Jones

I just got an email from Sean recommending this:

http://igg.me/at/wikireaders4kids/x/3095893

It's a non-profit campaign to give WikiReaders to thousands of kids. 
Sean is supporting the project, and is helping the organizers to get the 
best possible purchase price.


I am signing up too.  Very laudable goals.

But reading between the lines, this looks like it may represent the 
end-of-life for this excellent OpenMoko device.  If the hardware 
manufacturer has 10,000 units in overstock, of a product that was 
released years ago, then they may not be interested in ever making any 
more of these.  And if the wikireaders4kids campaign succeeds, all 
existing stock may vanish from the marketplace.


So this may be your last opportunity to buy a WikiReader (although I 
expect used ones may be available for a long time).  You can get them by 
pledging to that campaign, or for $14.99 on Amazon, or other places as 
mentioned at the bottom of this page:


http://www.thewikireader.com/

I also see that new content has recently become available for the 
WikiReader:


http://thewikireader.com/languagepacks.php

I see that the codebase is still being actively updated:

https://github.com/wikireader/wikireader

I think it would be a shame if this beautiful machine really does go out 
of manufacture, never to be updated again.  Wouldn't it be great if this 
design could be released as open hardware...


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


GTA04 (was: Re: [WikiReader] Giving, and last chance to get?)

2013-05-23 Thread Doug Jones
@Joseph Armbruster, you should have changed the subject line to 
something more appropriate.  (I just did that.)


The [WikiReader] tag indicated that the thread relates to the 
WikiReader, a different Openmoko product, not the open source smart 
phone most people talk about here.  Some people will see that tag in the 
subject line and ignore your message.


You might also want to post your message in another list, 
gta04-ow...@goldelico.com, which is more specifically targeted to the GTA04.




On 05/23/2013 02:38 PM, Joseph Armbruster wrote:

Everyone,

So I have been reading up on the GTA04 here:  
http://projects.goldelico.com/p/gta04-main/page/Manual/

Has anyone on the list printed a board, purchased parts, assembled the hardware 
and built the software stack themselves?

I am interested in doing exactly this.

If you have experience with this, please contact me off of the list.

Joseph Armbruster


On May 23, 2013, at 5:19 PM, Doug Jones wrote:


I just got an email from Sean recommending this:

http://igg.me/at/wikireaders4kids/x/3095893

It's a non-profit campaign to give WikiReaders to thousands of kids. Sean is 
supporting the project, and is helping the organizers to get the best possible 
purchase price.

I am signing up too.  Very laudable goals.

But reading between the lines, this looks like it may represent the end-of-life 
for this excellent OpenMoko device.  If the hardware manufacturer has 10,000 
units in overstock, of a product that was released years ago, then they may not 
be interested in ever making any more of these.  And if the wikireaders4kids 
campaign succeeds, all existing stock may vanish from the marketplace.

So this may be your last opportunity to buy a WikiReader (although I expect 
used ones may be available for a long time).  You can get them by pledging to 
that campaign, or for $14.99 on Amazon, or other places as mentioned at the 
bottom of this page:

http://www.thewikireader.com/

I also see that new content has recently become available for the WikiReader:

http://thewikireader.com/languagepacks.php

I see that the codebase is still being actively updated:

https://github.com/wikireader/wikireader

I think it would be a shame if this beautiful machine really does go out of 
manufacture, never to be updated again.  Wouldn't it be great if this design 
could be released as open hardware...

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[WikiReader] 32GB microSD card works

2012-08-01 Thread Doug Jones

I am testing a 32GB card in my WikiReader.

This is a Class 4 card by SanDisk.  The model number is SDSDQ-032G-AFFP. 
 I paid less than US$20 for it.


It passed the calc.elf test, so I installed all of the English-language 
wikis listed on the update page at 
http://dev.thewikireader.com/language-packs/ (all eight of them).  (BTW: 
 Thanks to whomever just updated that page.  Much easier to find things 
now.  [But the German-language version of Project Gutenberg is still not 
listed].)


I've been using this card for a day or so now, and everything is working 
fine.  Currently reading a book by Garrett Putman Serviss (an amazingly 
prophetic writer, easily the equal of Jules Verne and H. G. Wells.)  I 
discovered him by hitting the Random button repeatedly.


Those eight collections occupy about 1/3 of this card.  Plenty of space 
left for future expansion.


I have also recently tested a 16GB card.  This one is a Class 4 card 
from Kingston, model SDC4/16GB (about $10).  No problems with this card.



I have read somewhere the hypothesis that large-capacity SD cards 
sometimes misbehave because they can draw too much current from the 
power bus in these small devices.  Therefore I do all my WikiReader 
testing with 1.2V rechargeable NiMH batteries instead of the standard 
1.5V alkalines.  While testing the 16GB card, I ran my batteries down 
(this took a long time!) until the total battery voltage was less than 
2.1V;  only then did the WikiReader start to malfunction.  Thank you, 
Openmoko, for this marvelous little piece of engineering.






___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Wikireader] updates not working?

2012-07-07 Thread Doug Jones

On 07/07/2012 06:27 AM, Alexander Lehner wrote:



On Fri, 6 Jul 2012, Doug Jones wrote:


I can see the tracker now. Thanks to whoever fixed it.

I am seeding a bunch of these files now.


Partiall - enpedia works, but depedia for example not.

Alex.



Alex,

You may have just noticed that you have downloaded a few megabytes of 
that depedia file through azureus.  That's because I just seeded a small 
part of this file.


I used the trick mentioned earlier in this thread.  I trimmed the 
?torrent off of the end of the URL and started downloading the entire 
file through Firefox.  After a few megabytes I paused the download, 
copied the partial file into the download folder used by my bittorrent 
client, and told it to torrent that file.  It contacted the tracker at 
amazon, which is indeed working, and the tracker found one peer (you), 
and sent you those megabytes.


So the amazon tracker is working.  And the file is indeed present on the 
amazon server.  But the amazon tracker isn't using the amazon server as 
a seeder!


So something is still wrong.





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Wikireader] project gutenberg - was: updates not working?

2012-07-07 Thread Doug Jones

On 07/07/2012 04:28 PM, Alexander Lehner wrote:



Gutenberg WikiReader files seem to got lost completely.

http://dev.thewikireader.com/2010/06/26/project-gutenberg/

Sad - I liked that one.
Any chance, to get it updated?

A.



The links on that particular page don't seem to work any more.  But the 
most recent versions (from 2010) of Project Gutenberg are still 
available.  The English-language version is listed on


http://dev.thewikireader.com/language-packs/

but the German-language version isn't listed there.

However, I looked around a bit and found:

http://wrmlbeta.s3.amazonaws.com/deguten-20100608.7z.001

To find that file, I just downloaded the XML file at:

https://s3.amazonaws.com/wrmlbeta/

That XML file seems to contain the names of all the files shown on the 
language packs page, plus some other ones.  I found the deguten file 
listed there.


You shouldn't need the old Gutenberg-specific base file shown on that 
blog page.  The latest generic base file (20120620) from the language 
packs page should work fine.





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Wikireader] updates not working?

2012-07-07 Thread Doug Jones

On 07/07/2012 04:13 PM, Alexander Lehner wrote:



On Sat, 7 Jul 2012, Doug Jones wrote:


[...]
I used the trick mentioned earlier in this thread. I trimmed the
?torrent off of the end of the URL and started downloading the entire
file through Firefox. After a few megabytes I paused the download,
copied the partial file into the download folder used by my bittorrent
client, and told it to torrent that file. It contacted the tracker at
amazon, which is indeed working, and the tracker found one peer (you),
and sent you those megabytes.

So the amazon tracker is working. And the file is indeed present on
the amazon server. But the amazon tracker isn't using the amazon
server as a seeder!

So something is still wrong.


I now managed to download the zip files and seeding them now (for depedia).
Il will seed others also, in the hope, that the torrent network comes
back to live.

Off-topic soon, how-to:
I used azureus/vuze.
First downloaded the depedia*.7z files (as described earlier, without
.torrent).
Copied them into my torrent download folder.
Asked vuze to download the torrent 'depedia*.7z.torrent' from the
http://dev.thewikireader.com/language-packs/
page.

Got warning to continue/restart download, acknowledged that.
Started to seed then...

---

Just wondering:
I was downloading the files from web with approx. 600kB.
This is much faster than any torrent network will provide and faster
than most other download sites.

Who - if ever - will have to pay for this download speed?
Does it make sense at all here, to use torrent network to distribute
such kind of data?

A.




I assume that Openmoko is paying for the bits downloaded from that 
Amazon server.  Of course, when we ask our bittorrent clients to 
download and seed the files, Amazon doesn't see the traffic going 
between other peers so Openmoko doesn't pay for that part.  This is part 
of the reason we use bittorrent  --  we are volunteering to take some of 
the bandwidth load ourselves instead of asking some centralized server 
to cover all those costs.


Another reason for using bittorrent is this:  Suppose a group of peers 
already have, between them, a complete copy of a given file.  (No one 
peer needs to have all of the chunks;  each chunk just needs to be on at 
least one peer in the group.)  Then we just need to get a copy of the 
corresponding .torrent file to each peer, by whatever means, and then 
the peers can collectively act to build a complete copy of the big file 
on each peer.  No centralized tracker is needed, as long as the peers 
can find each other.  This brings the fully decentralized robustness of 
the Internet to torrent distribution.  (Okay, DNS isn't fully 
decentralized yet, but that's another story...)  This is what Tribler 
does.  It allows peers to find each other without a tracker.  I expect 
all bittorrent clients will eventually gain this capability.


As to the question of whether bittorrent makes much sense for these 
particular files:  That's a good question.


If you have a bunch of peers, and one of them can pump out data at 
600kBps and the others are much slower, then the fast one will 
presumably hand out most of the chunks and the slower ones won't do much 
at all.  If the fast server is worried about cost, then it could 
throttle itself down when there are other peers seeding.  But throttling 
itself down to zero (effectively that's what's happening now) is also 
undesirable, especially if the other peers don't have a complete copy 
between them yet  ;-)


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Wikireader] updates not working?

2012-07-06 Thread Doug Jones

On 07/05/2012 03:28 PM, Doug Jones wrote:

On 07/05/2012 02:06 PM, Alexander Lehner wrote:



On Thu, 5 Jul 2012, Doug Jones wrote:


I see there are some new Wikireader updates available:

http://dev.thewikireader.com/language-packs/

But I can't download them -- the tracker times out.

Anybody else having this problem?


yes, me. Tried it with the german depedia and using azureus/vuze as
torrent client.
There seem to be no sources.

A.



Looks like Openmoko is using the Amazon cloud to host these files. The
tracker is at http://tracker.amazonaws.com:6969/announce and it times
out when you talk to it.

Developers have accessed these files recently; Siebrand Mazeland and
Christopher Hall have done github updates within the last couple weeks,
and there's a base files update on the download page dated 20 June. So
this must be a recent problem.



Workaround, for anybody who wants updates and is in a hurry:

Copy the desired link URL from that page, paste it into the address bar 
of your browser, then strip the ?torrent from the end, and hit Enter. 
 This will download the entire file (up to 1GB!) instead of just the 
corresponding .torrent file.


(Yes, the files are all there...  it's just the bittorrent tracker that 
is down.)


While you're there, also download the .torrent file.  Then when both 
downloads are complete, you can use your bittorrent client to verify 
that the big file you downloaded is correct.



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Wikireader] updates not working?

2012-07-06 Thread Doug Jones

On 07/06/2012 12:00 AM, Doug Jones wrote:

On 07/05/2012 03:28 PM, Doug Jones wrote:

On 07/05/2012 02:06 PM, Alexander Lehner wrote:



On Thu, 5 Jul 2012, Doug Jones wrote:


I see there are some new Wikireader updates available:

http://dev.thewikireader.com/language-packs/

But I can't download them -- the tracker times out.

Anybody else having this problem?


yes, me. Tried it with the german depedia and using azureus/vuze as
torrent client.
There seem to be no sources.

A.



Looks like Openmoko is using the Amazon cloud to host these files. The
tracker is at http://tracker.amazonaws.com:6969/announce and it times
out when you talk to it.

Developers have accessed these files recently; Siebrand Mazeland and
Christopher Hall have done github updates within the last couple weeks,
and there's a base files update on the download page dated 20 June. So
this must be a recent problem.



Workaround, for anybody who wants updates and is in a hurry:

Copy the desired link URL from that page, paste it into the address bar
of your browser, then strip the ?torrent from the end, and hit Enter.
This will download the entire file (up to 1GB!) instead of just the
corresponding .torrent file.

(Yes, the files are all there... it's just the bittorrent tracker that
is down.)

While you're there, also download the .torrent file. Then when both
downloads are complete, you can use your bittorrent client to verify
that the big file you downloaded is correct.




I can see the tracker now.  Thanks to whoever fixed it.

I am seeding a bunch of these files now.



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[Wikireader] updates not working?

2012-07-05 Thread Doug Jones

I see there are some new Wikireader updates available:

http://dev.thewikireader.com/language-packs/

But I can't download them  --  the tracker times out.

Anybody else having this problem?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Wikireader] updates not working?

2012-07-05 Thread Doug Jones

On 07/05/2012 02:06 PM, Alexander Lehner wrote:



On Thu, 5 Jul 2012, Doug Jones wrote:


I see there are some new Wikireader updates available:

http://dev.thewikireader.com/language-packs/

But I can't download them -- the tracker times out.

Anybody else having this problem?


yes, me. Tried it with the german depedia and using azureus/vuze as
torrent client.
There seem to be no sources.

A.



Looks like Openmoko is using the Amazon cloud to host these files.  The 
tracker is at http://tracker.amazonaws.com:6969/announce and it times 
out when you talk to it.


Developers have accessed these files recently;  Siebrand Mazeland and 
Christopher Hall have done github updates within the last couple weeks, 
and there's a base files update on the download page dated 20 June.  So 
this must be a recent problem.



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: $100 computers

2012-02-08 Thread Doug Jones

On 02/08/2012 12:51 PM, Joshua Judson Rosen wrote:

Shawn Rutledgeshawn.t.rutle...@gmail.com  writes:


With an Atmel it sounds like a dancing bear to me; it has so little
memory that you basically have to use it only for fixed purposes, like
the games they show.  No dynamic languages or possibility of
downloading much content.


$100 would also get you Qi Hardware's Nanonote units, which is
comparable to a Raspberry Pi + monitor + keyboard that you can
actually carry in your pocket and use on the go (comes with
a Li-ion battery, runs for ~9 hours in my experience).

I have one. I like it. I use it mainly as a smart music-player;
I've also written and run some Python and Scheme programs on it
(so, it makes a nice `programmer's calculator' for, e.g.: solving
  recursive problems).

Not sure what others do with theirs.

A couple of friends also have them, and it seems to take about
3 days between ordering from Sharism in Hong Kong and having them
arrive on our doorsteps in the US.




It appears you can now buy the Ben Nanonote from a U.S. retailer:

http://www.amazon.com/NanoNote-copyleft-hardware-pocket-computer/dp/B0064URJNQ

It costs less this way ($94 including shipping, if you don't mind it 
taking a few extra days to arrive) and you don't have to deal with 
offshore banks and shippers.  (But you do have to deal with Amazon...)



(In recent times, the only times I have had money stolen from my 
accounts have been immediately after dealing directly with companies in 
other countries.  To their credit, Sharism does appear to be making 
serious efforts to prevent these kinds of things, and before they 
shipped my Nanonote I even got a personal email from someone at Sharism 
discussing the identity theft issue.)


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: uSD corruption

2011-12-17 Thread Doug Jones

On 12/16/2011 01:08 AM, Radek Polak wrote:

On Thursday 15 December 2011 22:00:22 fdvj...@vodafone.it wrote:


Hi
I have a Kingstone microSD card 8GB. It seems to be reliable for data
but if I use it with a running distro, at this moment QtMoko, I
experience, during a day of usage, several freezings. I mean, when it is
in suspend mode (deep suspend enabled) if I press the power button the
Neo does not recover from the suspend. I have to pull off the battery
and then restart the Neo, but as can you imagine, after a couple of
times the file system gets corrupted and I have to format the partition.
Moreover this behaviour seems to become worse as the time passes.
Should I consider to replace the uSD card? are there known issues in
using running distro on it?
Thanks.


For me uSD card never worked as stable rootfs. I always ended up with
corrupted filesystem after a couple of days. But for data on FAT it always
worked quite good.

I guess this is some flaw in Freerunner's hardware or kernel driver. On GTA04
i have rootfs on uSD and no problems at all. I am starting to think that NAND
on GTA04 is quite useless - it would be quite cool if it had 2 uSD cards
instead (with BTRFS as fs it could rock).

Regards

Radek



I suspect there is something about the SD card implementation that is 
deeply flawed.


To my way of thinking, an interface should be well enough defined so 
that two devices should be able to figure out how to reliably talk to 
one another after being connected for a short time, even if they were 
designed by different groups years apart.  The spec should spell out 
how, and every device should follow the spec.  If it doesn't work this 
way, then there is something wrong with the spec, or with the processes 
vendors use to implement the spec, and/or with the group that manages 
and enforces the spec.


Four years ago I discovered that some SD cards had problems with the 
OLPC XO-1.  Then I had troubles with micro SD cards in the Freerunner. 
Then I heard about problems people were having with the EEE-PC running 
Linux.  Then the SheevaPlug.  And on and on.


Four years later and I'm still hearing stories about SD cards getting 
corrupted, and you still find lists of known to work / not work cards 
in the wikis of various projects.  Yet, if you exclude those cards that 
have obviously failed (because they don't work properly in anything), I 
never have problems with any SD card in any camera.


What is the source of this discrepancy?  Those cameras are proprietary 
inside, but those other projects are open source.  Perhaps the people in 
charge of SD aren't revealing something to the open source communities? 
 I don't know.


There have been endless discussions over the years, about file systems, 
race conditions, suspend modes, the gravitational influence of 
Jupiter...  But I have never heard anyone claim that they actually 
understand why a card that Just Works in my camera can't be made to Just 
Work in all of our open source devices.



Yes, I know this isn't very constructive...  Sometimes I just have to 
vent...   :-)



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[WikiReader] Wikitravel announced

2011-02-03 Thread Doug Jones
It was nice to get the WikiReader newsletter today.  I'd forgotten that 
I had subscribed to that.


They announced Wikitravel.

It's not listed on the update page yet, but I found the torrent here:

http://wrmlbeta.s3.amazonaws.com/entrav-20101116.7z.001?torrent

Seeding it now.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[WikiReader] what's up with Wikitravel?

2011-02-03 Thread Doug Jones
I just added Wikitravel to my WikiReader.  But it doesn't appear on the 
menu.


Does it require a newer base file?  Perhaps this one?

http://wrmlbeta.s3.amazonaws.com/base-20110106.7z?torrent

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


list strangeness?

2011-02-03 Thread Doug Jones
I just realized I haven't received any mail from this list for the past 
week.  But the list archives show some messages during that period, 
including some I just sent.


I logged into the list manager and checked my options, and everything 
looked fine.  I changed a few, just to see if this action might jog the 
list's memory.  Still not receiving any messages.


Anybody else having this problem?  (If you don't receive this, please 
reply to the list.  ;)


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


list strangeness

2011-02-03 Thread Doug Jones

I just sent a message to mailman about this.

I also checked the archives of the other published Openmoko lists.  The 
Community list is the only one showing any activity since January 21, 
and even that is very small.


Prior to January 21, the list was getting about seven messages per day, 
similar to the rate for the last few months.  Now it is down to about 
one per day.  They all seem to be replies to messages sent on or before 
January 21, or newly created messages, or the 'list strangeness' 
messages where we are generating replies manually from the list archive.


This suggests to me that nobody is receiving list messages via email.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Wikireader FAQ draft

2010-12-28 Thread Doug Jones

Christoph Pulster wrote:

Any comments welcome !

Chris


Openmoko Wikireader - Frequently asked questions


- dimensions ?

The Wikireaders size is 10x10cm with 2cm depth, Weight: 120g. Compare it here:
PICTURES


- handling ?

The unit has only three buttons and is very easy to use.
The touchscreen display can be navigated with the fingers (no need for a stylus)
and is easy to read indoors and out.
The case is very robust and the organic shape is a joy to hold.
Explicit Wikipedia content can be protected with a password. So the Wikireader
is kid-safe.

- manual ?

The unit comes with a small printed manual. Please find a PDF copy here:
http://thewikireader.com/files/WR_Manual_V4_en.pdf

- power ?

The Wikireader uses two standard batteries (size AAA) which last for a full 
year of usage.
No annoying discharged battery, no fittling with power adapters.



fittling  fiddling



This makes the device helpful while travelling in the Australian outbacks.



Rechargeable 1.2V AAA batteries can be used in place of standard 1.5V ones.




- Languages ?

Please see a list of available languages here: 
http://dev.thewikireader.com/language-packs
Several languages can be used simultaneously.
Additional languages can be installed with the Update application from Openmoko:
http://www.thewikireader.com/update/
After installation, you can choose language on the Wikireader by touching the 
globe symbol
on the search page.


- Quickupdate GERMAN ?

Remove memory card from Wikireader, insert it in your PC-cardreader.
Download FILE, extract and copy directory depedia to the memory card.
Put the card back to the Wikireader and German language is now available !


- Update ?

Please download the Openmoko Update Application here:
http://www.thewikireader.com/update
The Wikireader content is updated quaterly from Openmoko and is always free to 
download !



- eBooks ?

Next to Wikipedia you can use simultaneously the eBooks from Project Gutenberg.
Project Gutenberg on WikiReader contains the eBooks from http://gutenberg.org 
(but not http://gutenberg.cc). You will need to upgrade to a 16 GB memory card.
The Gutenberg eBooks can be downloaded with the Openmoko Update Application:
http://www.thewikireader.com/update



 - Other kinds of content ?

Any wiki that runs on MediaWiki software ( 
http://www.mediawiki.org/wiki/MediaWiki ) can be converted to the 
WikiReader format and copied to the memory card.  In addition to many 
language versions of Wikipedia and the eBooks from Project Gutenberg, 
the English Wiktionary ( 
http://en.wiktionary.org/wiki/Wiktionary:Main_Page ) and Wikiquote ( 
http://www.wikiquote.org/ ) have already been converted and are 
available on the Update page ( 
http://dev.thewikireader.com/language-packs/ ).  There is enough room on 
a 16GB card to fit one Wikipedia, Gutenberg, Wikiquote and Wiktionary, 
all at the same time, with gigabytes to spare.


There are many other language versions of Wikipedia that have not been 
converted to WikiReader format yet, and many other kinds of useful wikis 
that are suitably licensed for free redistribution as well.  WikiReader 
users who have the required skills, and an itch to scratch, are 
encouraged to convert these and offer them to the community.




- Custom content?

For more technically inclined users:  You can put custom content in your 
WikiReader by first uploading it into a wiki running on MediaWiki and 
then doing an xml dump as described at 
http://www.mediawiki.org/wiki/XML_dump#XML_dump .  The dump is then 
converted to WikiReader format using the Python program found in the 
WikiReader git tree ( https://github.com/wikireader/wikireader ) .


Creating an empty private wiki is easy, and it only takes minutes to get 
started.  First install VirtualBox ( http://www.virtualbox.org/ ) and 
then within it, install a MediaWiki appliance ( 
http://www.turnkeylinux.org/mediawiki ).  When you start the appliance, 
it displays a URL that you enter into your web browser.  Then you add 
content and edit it in the usual wiki way.






- more functionality ?

Calculator = press and hold History-button while powering the Wikireader on.
System applications = press and hold Search-button while powering the 
Wikireader on.
Debug console (GPIO) for developers = press and hold Random-button while 
powering on.
Forth programms - the Wikireader can execute Forth written code (check *.4th, 
*.4mu files in root dir on the memory card)


- developement ?

You can find source code, technical specifications etc. here:
https://github.com/wikireader/wikireader
A SDK can be found here: http://wrdk.seabright.co.nz/

(C) Wikireader Shop www.pulster.de



Christoph



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community




___
Openmoko community mailing list

[wikireader] There are updates!

2010-08-13 Thread Doug Jones
I just noticed that there are updated WikiReader files available. 
Happened a couple months ago. I don't think this was announced on the 
list at the time  (or at least I didn't see it whizzing by).


I see that the little gizmo can handle multiple wikis now.  You can put 
subdirectories on the SD card and it knows how to use them.  This is 
excellent.

There are a bunch of languages available, as well as English Wiktionary 
and English Wikiquote.


See:

http://thewikireader.com/update/


If you want to use torrents for downloading instead, go here:

http://dev.thewikireader.com/beta-language-packs/

(That page is labeled 'Beta', but the links now appear to be pointing to 
the same files listed on the other page.)


There's a developer blog too:

http://dev.thewikireader.com/



P.S.  Can anybody give a list of 16GB SD cards that are known to work in 
the WikiReader?  Or should we expect that they all will work?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [freerunner] data plan USA

2009-11-11 Thread Doug Jones
jeremy jozwik wrote:
 On Wed, Nov 11, 2009 at 12:34 AM, Ed Kapitein e...@kapitein.org wrote:
 Hi all,
 Last time i bought a card like [1], but only for voice calls, and that
 worked well.

 Thanks for the input!

 Kind regards,
 Ed
 
 my last experiences looking for a pre-paid data sim in the us ended in
 disappointment. this was a few months ago and things may have changed
 but att USED to be the only pre-paid sim available with data but that
 has long since been discontinued.
 
 i would really like you know if you find something that works.


QikRoam supposedly has a prepaid data sim that works in the U.S., and 
lots of other countries too.

However, I've never heard of anyone using one successfully in a 
Freerunner.  If somebody does get it to work, I'd like to hear how they 
did it...

http://www.qikroam.com/Info/About.aspx

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[WikiReader] License review (was: Re: [Wikireader] Any news on Wikireader ?)

2009-11-01 Thread Doug Jones
Wolfgang Spraul wrote:

[snip]

  Can you spend a bit of time to check the licenses? Chris Hall reviewed it
  so I'm sure it's all good, but since it is all statically linked together
  and GPL-licensed it means like you said every last bit of software needs
  to be at least GPL compatible. An independent review on this would be 
great.

[snip]


As you requested, I have begun a software review.  This is a progress 
report.

I downloaded the complete source tree from github on 10/22/09.  I ran 
make and make install with no errors.

The source tree does appear to contain some code under licenses that are 
not GPL compatible.  However, so far I have not determined with any 
certainty if any of that code is compiled into executables that go onto 
the device.  A lot of code goes into the tools instead.

I don't have a lot of experience with make.  If anybody knows a simple 
way of automatically generating lists of the files that get compiled 
into each target, that would be a big help.


*



2464 files found



Directory: host-tools/offline-renderer/mediawiki-offline contains a file 
indicating its contents are under license: GPL2+
Directory: host-tools/offline-renderer/pylzma-0.3.0 contains a file 
indicating its contents are under license: LGPL2.1
Directory: host-tools/fonts contains a file indicating its contents are 
under license: GPL3+
Directory: host-tools/qt4-simulator contains a file indicating its 
contents are under license: GPL2
Directory: samo-lib/fatfs contains a file indicating its contents are 
under license: free software
Directory: samo-lib/forth contains a file indicating its contents are 
under license: BSD 2-clause
Directory: samo-lib/mahatma contains a file indicating its contents are 
under license: GPL3+



I assume that no differently-licensed files have been moved into the 
parts of the directory tree listed above.



__

The following analysis ignores the above directories.


__

_

[BSD-2clause-stdlib.h]

The following text:


See stdlib.h for licence.


...appears in the following files:

samo-lib/mini-libc/src/stdlib/itoa.c
samo-lib/mini-libc/src/stdlib/ltoa.c
samo-lib/mini-libc/src/stdlib/ultoa.c
samo-lib/mini-libc/src/stdlib/utoa.c


(stdlib.h has a 2-clause BSD license.)

_

[BSD-2clause]

The following text:


  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *notice, this list of conditions and the following disclaimer in the
  *documentation and/or other materials provided with the distribution.
  *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS `AS IS'' AND
  * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
PURPOSE
  * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL
  * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 
STRICT
  * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN 
ANY WAY
  * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  * SUCH DAMAGE.


...appears in the following files:

samo-lib/mini-libc/include/ctype.h
samo-lib/mini-libc/include/errno.h
samo-lib/mini-libc/include/inttypes.h
samo-lib/mini-libc/include/stdio.h
samo-lib/mini-libc/include/stdlib.h
samo-lib/mini-libc/include/string.h



_

[BSD-3clause]

The following text:


  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *notice, this list of conditions and the following disclaimer in the
  *documentation and/or other materials provided with the distribution.
  * 3. The name of the author may not be used to endorse or promote products
  *derived from this software without specific prior written permission.
  *
  * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED 
WARRANTIES,
  * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
  * AND FITNESS FOR A 

Re: [Wikireader] Any news on Wikireader ?

2009-11-01 Thread Doug Jones
(Part 1 was in the previous message, this is part 2)














__
The files listed above are not included in the analysis below.

Many of the files remaining are not source code and presumably don't 
require software licenses.

Most of the files remaining do not contain license text and do not 
appear in directories that contain license text.  However I have not 
read all of the files yet.
__


Graphics and texts and others...



graphics files:

   .png:

host-tools/splashimages/dead_battery.png
host-tools/splashimages/i_love_samo.png
host-tools/splashimages/openmoko_zh.png
host-tools/splashimages/samo_cat.png
host-tools/splashimages/samo_cool.png
host-tools/splashimages/samo_in_heart.png
samo-lib/flash/fail.png
samo-lib/flash/ok.png
samo-lib/flash/program.png
samo-lib/mbr/empty.png
samo-lib/mbr/splash.png

   .pbm:

wiki-app/clear_history.pbm
wiki-app/keyboard_abc_mono2.pbm
wiki-app/keyboard_numb_mono2.pbm


text files:

   (no extension):

.git/FETCH_HEAD
.git/HEAD
.git/config
.git/description
.git/index
.git/info/exclude
.git/logs/HEAD
.git/logs/refs/heads/2
.git/logs/refs/heads/master
.git/logs/refs/remotes/origin/gh-pages
.git/logs/refs/remotes/origin/master
.git/packed-refs
.git/refs/heads/2
.git/refs/heads/master
.git/refs/remotes/origin/gh-pages
.git/refs/remotes/origin/master
.gitignore
Makefile
TODO
doc/QuickStart
host-tools/.gitignore
host-tools/console-simulator/.gitignore
host-tools/flash07/.gitignore
host-tools/hash-gen/.gitignore
host-tools/jackknife/.gitignore
host-tools/offline-renderer/.gitignore
host-tools/pcf2bmf/.gitignore
host-tools/splashimages/README
host-tools/wiki-xml/.gitignore
samo-lib/.gitignore
samo-lib/drivers/.gitignore
samo-lib/flash/.gitignore
samo-lib/include/.gitignore
samo-lib/mbr/.gitignore
samo-lib/mini-libc/.gitignore
samo-lib/mini-libc/README
samo-lib/mini-libc/src/bsd/.gitignore
samo-lib/mini-libc/src/stdlib/.gitignore
samo-lib/mini-libc/src/string/.gitignore
samo-lib/scripts/CopyToSD
samo-lib/scripts/MakeSD
samo-lib/scripts/MakeTestFile
samo-lib/scripts/SendCountedFile
samo-lib/scripts/p33
testudo/init-scripts/gpib
testudo/linux-gpib-svn/.gitignore
testudo/linux-gpib-svn/AUTHORS
testudo/linux-gpib-svn/COPYING
testudo/linux-gpib-svn/ChangeLog
testudo/linux-gpib-svn/INSTALL
testudo/linux-gpib-svn/NEWS
testudo/linux-gpib-svn/README
testudo/linux-gpib-svn/TODO
testudo/linux-gpib-svn/applications/Makefile
testudo/linux-gpib-svn/bootstrap
testudo/linux-gpib-svn/contrib/Makefile
testudo/linux-gpib-svn/drivers/gpib/Makefile
testudo/linux-gpib-svn/drivers/gpib/agilent_82350b/Makefile
testudo/linux-gpib-svn/drivers/gpib/agilent_82357a/Makefile
testudo/linux-gpib-svn/drivers/gpib/cb7210/Makefile
testudo/linux-gpib-svn/drivers/gpib/cec/Makefile
testudo/linux-gpib-svn/drivers/gpib/eastwood/Makefile
testudo/linux-gpib-svn/drivers/gpib/hp_82335/Makefile
testudo/linux-gpib-svn/drivers/gpib/hp_82341/Makefile
testudo/linux-gpib-svn/drivers/gpib/ines/Makefile
testudo/linux-gpib-svn/drivers/gpib/nec7210/Makefile
testudo/linux-gpib-svn/drivers/gpib/ni_usb/Makefile
testudo/linux-gpib-svn/drivers/gpib/pc2/Makefile
testudo/linux-gpib-svn/drivers/gpib/sys/Makefile
testudo/linux-gpib-svn/drivers/gpib/tms9914/Makefile
testudo/linux-gpib-svn/drivers/gpib/tnt4882-tms/Makefile
testudo/linux-gpib-svn/drivers/gpib/tnt4882/Makefile
testudo/linux-gpib-svn/etc/pcmcia/linux-gpib-pcmcia
testudo/linux-gpib-svn/language/guile/README
testudo/linux-gpib-svn/language/perl/Changes
testudo/linux-gpib-svn/language/perl/MANIFEST
testudo/linux-gpib-svn/language/perl/README
testudo/linux-gpib-svn/language/perl/typemap
testudo/linux-gpib-svn/language/php/run
testudo/linux-gpib-svn/language/python/README
testudo/linux-gpib-svn/language/tcl/.xsetup
testudo/linux-gpib-svn/language/tcl/README
testudo/linux-gpib-svn/language/tcl/examples/.xsetup
testudo/linux-gpib-svn/language/tcl/examples/tclib/tclIndex
testudo/linux-gpib-svn/lib/gpib_version_script
testudo/linux-gpib-svn/test/README
testudo/linux-gpib-svn/test/runtest
testudo/linux-gpib-svn/usb/agilent_82357a/agilent_82357a
testudo/linux-gpib-svn/usb/ni_usb_gpib/ni_usb_gpib
testudo/linux-gpib-svn/util/linux_flags/Makefile
testudo/linux-gpib-svn/util/subdirs
wiki-app/.gitignore

   .txt:

Licenses/BSD.TXT
Licenses/BSD2CL.TXT
Licenses/GPLV2.TXT
samo-lib/misc-files/README.TXT
testudo/linux-gpib-svn/doc/obsolete-linux-gpib.txt
testudo/linux-gpib-svn/drivers/gpib/cb7210/cb_cis_dump.txt
testudo/linux-gpib-svn/drivers/gpib/cb7210/cbi4882.txt
testudo/linux-gpib-svn/drivers/gpib/ines/ines_cis_dump.txt
testudo/linux-gpib-svn/drivers/gpib/tnt4882/ni-usb-b.txt
testudo/linux-gpib-svn/drivers/gpib/tnt4882/ni_cis_dump.txt

   .text:

00ReadMe.text
doc/Compiling-on-AMD64.text
doc/Using-schroot.text
host-tools/00ReadMe.text
samo-lib/00ReadMe.text
samo-lib/mbr/application-ReadMe.text
testudo/00ReadMe.text
testudo/test-scripts.text


Re: [WikiReader] License review

2009-11-01 Thread Doug Jones
(Eeeek!  Just posted the following message under the wrong subject line. 
  Sorry.  Here it is again.)



(Part 1 was in the previous message, this is part 2)










__
The files listed above are not included in the analysis below.

Many of the files remaining are not source code and presumably don't
require software licenses.

Most of the files remaining do not contain license text and do not
appear in directories that contain license text.  However I have not
read all of the files yet.
__


Graphics and texts and others...



 graphics files:

.png:

host-tools/splashimages/dead_battery.png
host-tools/splashimages/i_love_samo.png
host-tools/splashimages/openmoko_zh.png
host-tools/splashimages/samo_cat.png
host-tools/splashimages/samo_cool.png
host-tools/splashimages/samo_in_heart.png
samo-lib/flash/fail.png
samo-lib/flash/ok.png
samo-lib/flash/program.png
samo-lib/mbr/empty.png
samo-lib/mbr/splash.png

.pbm:

wiki-app/clear_history.pbm
wiki-app/keyboard_abc_mono2.pbm
wiki-app/keyboard_numb_mono2.pbm


 text files:

(no extension):

.git/FETCH_HEAD
.git/HEAD
.git/config
.git/description
.git/index
.git/info/exclude
.git/logs/HEAD
.git/logs/refs/heads/2
.git/logs/refs/heads/master
.git/logs/refs/remotes/origin/gh-pages
.git/logs/refs/remotes/origin/master
.git/packed-refs
.git/refs/heads/2
.git/refs/heads/master
.git/refs/remotes/origin/gh-pages
.git/refs/remotes/origin/master
.gitignore
Makefile
TODO
doc/QuickStart
host-tools/.gitignore
host-tools/console-simulator/.gitignore
host-tools/flash07/.gitignore
host-tools/hash-gen/.gitignore
host-tools/jackknife/.gitignore
host-tools/offline-renderer/.gitignore
host-tools/pcf2bmf/.gitignore
host-tools/splashimages/README
host-tools/wiki-xml/.gitignore
samo-lib/.gitignore
samo-lib/drivers/.gitignore
samo-lib/flash/.gitignore
samo-lib/include/.gitignore
samo-lib/mbr/.gitignore
samo-lib/mini-libc/.gitignore
samo-lib/mini-libc/README
samo-lib/mini-libc/src/bsd/.gitignore
samo-lib/mini-libc/src/stdlib/.gitignore
samo-lib/mini-libc/src/string/.gitignore
samo-lib/scripts/CopyToSD
samo-lib/scripts/MakeSD
samo-lib/scripts/MakeTestFile
samo-lib/scripts/SendCountedFile
samo-lib/scripts/p33
testudo/init-scripts/gpib
testudo/linux-gpib-svn/.gitignore
testudo/linux-gpib-svn/AUTHORS
testudo/linux-gpib-svn/COPYING
testudo/linux-gpib-svn/ChangeLog
testudo/linux-gpib-svn/INSTALL
testudo/linux-gpib-svn/NEWS
testudo/linux-gpib-svn/README
testudo/linux-gpib-svn/TODO
testudo/linux-gpib-svn/applications/Makefile
testudo/linux-gpib-svn/bootstrap
testudo/linux-gpib-svn/contrib/Makefile
testudo/linux-gpib-svn/drivers/gpib/Makefile
testudo/linux-gpib-svn/drivers/gpib/agilent_82350b/Makefile
testudo/linux-gpib-svn/drivers/gpib/agilent_82357a/Makefile
testudo/linux-gpib-svn/drivers/gpib/cb7210/Makefile
testudo/linux-gpib-svn/drivers/gpib/cec/Makefile
testudo/linux-gpib-svn/drivers/gpib/eastwood/Makefile
testudo/linux-gpib-svn/drivers/gpib/hp_82335/Makefile
testudo/linux-gpib-svn/drivers/gpib/hp_82341/Makefile
testudo/linux-gpib-svn/drivers/gpib/ines/Makefile
testudo/linux-gpib-svn/drivers/gpib/nec7210/Makefile
testudo/linux-gpib-svn/drivers/gpib/ni_usb/Makefile
testudo/linux-gpib-svn/drivers/gpib/pc2/Makefile
testudo/linux-gpib-svn/drivers/gpib/sys/Makefile
testudo/linux-gpib-svn/drivers/gpib/tms9914/Makefile
testudo/linux-gpib-svn/drivers/gpib/tnt4882-tms/Makefile
testudo/linux-gpib-svn/drivers/gpib/tnt4882/Makefile
testudo/linux-gpib-svn/etc/pcmcia/linux-gpib-pcmcia
testudo/linux-gpib-svn/language/guile/README
testudo/linux-gpib-svn/language/perl/Changes
testudo/linux-gpib-svn/language/perl/MANIFEST
testudo/linux-gpib-svn/language/perl/README
testudo/linux-gpib-svn/language/perl/typemap
testudo/linux-gpib-svn/language/php/run
testudo/linux-gpib-svn/language/python/README
testudo/linux-gpib-svn/language/tcl/.xsetup
testudo/linux-gpib-svn/language/tcl/README
testudo/linux-gpib-svn/language/tcl/examples/.xsetup
testudo/linux-gpib-svn/language/tcl/examples/tclib/tclIndex
testudo/linux-gpib-svn/lib/gpib_version_script
testudo/linux-gpib-svn/test/README
testudo/linux-gpib-svn/test/runtest
testudo/linux-gpib-svn/usb/agilent_82357a/agilent_82357a
testudo/linux-gpib-svn/usb/ni_usb_gpib/ni_usb_gpib
testudo/linux-gpib-svn/util/linux_flags/Makefile
testudo/linux-gpib-svn/util/subdirs
wiki-app/.gitignore

.txt:

Licenses/BSD.TXT
Licenses/BSD2CL.TXT
Licenses/GPLV2.TXT
samo-lib/misc-files/README.TXT
testudo/linux-gpib-svn/doc/obsolete-linux-gpib.txt
testudo/linux-gpib-svn/drivers/gpib/cb7210/cb_cis_dump.txt
testudo/linux-gpib-svn/drivers/gpib/cb7210/cbi4882.txt
testudo/linux-gpib-svn/drivers/gpib/ines/ines_cis_dump.txt
testudo/linux-gpib-svn/drivers/gpib/tnt4882/ni-usb-b.txt
testudo/linux-gpib-svn/drivers/gpib/tnt4882/ni_cis_dump.txt

.text:

00ReadMe.text
doc/Compiling-on-AMD64.text
doc/Using-schroot.text
host-tools/00ReadMe.text

Re: [WikiReader] file system questions

2009-11-01 Thread Doug Jones
Christopher Hall wrote:
 On Fri, 30 Oct 2009 12:46:57 -0700
 Doug Jones dj...@frombob.to wrote:
 
 [snip]
 I like this approach, just remind that as far I see the code and by
 comments of the devs, the kernel implements the bare just enough to
 read files, so I think directories are not implemented at all that's
 why all is on root directory so at least basic hierarchical
 filesystem has to be implemented before we can do this solution.
 But directories will easy the organization of pictures too

 Good point.

 So two important questions to be answered, before we get any further 
 into this:

 (1) Has OpenMoko made the policy decision that filenames will be
 limited to 8.3?
 
 I would prefer to keep it simple, the boot loader must run in under 7kB
 of internal RAM (actually it uses overlays) so adding more code
 here is not so easy.  

 (2) How complicated will it be to implement subdirectory support?
 The version of the file system supports directory access, but there
 is no support for chdir
 
 we are using this:   http://elm-chan.org/fsw/ff/00index_e.html
 presently at version: R0.06
 
 so all pathnames have to be absolute, I tried a couple of quick
 tests and I could create and read a file in the folder, but I am missing
 mkdir in forth, (just need to add the interface routine)
 
 It looks like there is a new version with chdir support, but
 I have not investigated this yet
 
 Hope this answers your questions 
 


Yes, thanks for that.  Helps a lot.


This is what I've got in mind:


No changes to boot loader.  The only things to be changed are on the SD 
card.

Suppose the user wants two different wikis on the device.  To keep 
things simple, each wiki is independent and resides in its own 
directory.  Once a particular wiki is running, there is no way to access 
the other one without rebooting.  For backwards compatibility, we let 
the default wiki reside at root, just as in the current implementation.

A directory may contain a Wikipedia in a different language, or perhaps 
some entirely different wiki using the same WikiReader app, or perhaps 
some other app that is yet to be written.  (For convenience, we call 
each one an app here, even if the subdirectory actually contains 
multiple applications).


The boot loader runs /kernel.elf as before, but instead of the 
WikiReader app, it's just a menu system (the WikiReader app has been 
renamed something like wrkernel.elf).  It scans the subdirectories (only 
one level down) on the SD card, looking for a particular filename, say 
menu.png, which contains an image of the menu entry for that particular 
app.  By using pictures for the entries, we don't need any 
(multi-language!) font support in the menu app, kernel.elf.

If it finds no /*/menu.png then it loads /wrkernel.elf and the device 
works just as it does now, with everything at / on the card.  The user 
does not see anything different from what they see now.

If it does find some /*/menu.png, it displays a menu containing all of 
the bitmaps found (including the default one at /menu.png).  If the user 
selects one other than the default, say for example the one at 
/pt/menu.png, kernel.elf passes control to /pt/wrkernel.elf and the 
Português version of Wikipedia runs.  From that point on, the app 
doesn't need to know anything about what's at / or any other 
subdirectory.  All of the .bmf font files and Forth files and whatnot 
are in that subdirectory.

So kernel.elf needs to be able to do dir /*/menu.png, wrkernel.elf needs 
to be able to do chdir (once), and nobody needs to do mkdir.  All other 
filesystem operations happen within a single directory.


This initial menu system also is displayed if the user holds down a 
button while booting, so /pt/forth.elf or /pt/calc.elf or whatever will 
be run as appropriate.


With this scheme, the 8.3 filename limit is no problem.  And different 
language versions of Wikipedia can reside in directories named after the 
language designations used by Wikipedia.

If a user wants to add a wiki of their own, they just use the existing 
tools to build the pedia* files from an xml dump.  They put these into a 
folder along with the other files copied from / on a standard WikiReader 
SD card, add a menu.png file for the menu entry (we can give them a tool 
to generate one in their language), and then they copy the folder onto 
the SD card and put it into the device and off they go.

If somebody writes an entirely different app, all they have to do is 
name it wrkernel.elf, supply a menu.png, put it all in a folder and do 
as above.


And nobody has to flash the ROM.




 Note that only one subdirectory level is really needed to implement
 what has already been suggested.

 The current implementation contains 81 files, totaling 4.2GB for the 
 English version.  Nearly all of that is in the big wiki data files 
 (pedia*).  The other files, the ones you get when you make install, 
 comprise 49 files and only 18MB, and most of that is fonts (which are 
 often

Re: [wikireader]Suggestions for next steps on software

2009-10-30 Thread Doug Jones
David Reyes Samblas Martinez wrote:
 Though on how the evolution of the soft of the wikireader must be, I
 have oredered the sugesstions by impact on functionality/easy to
 implement ratio, of course under a totally  non-hardcore developer and
 only-one-week user criteria.
 *First and prioritary,
 allow have multiple languages on same sdcard, I think a one easy
 approach is to have a selection menu on boot with the available
 languages on the sdcard (looking at the sufix of the pedia files
 pedia_es, pedia_de, pedia_pt. ) present a bare text menu
 with the items, select,  and then operate as usual.
 More complex things like changing of language inside a topic or
 include non wikipedia content to  that menu using a config file can be
 implemented later on.


I notice that the current implementation fits within the old 8.3 DOS 
file naming scheme (except that both upper case and lower case is used). 
  Is this done to avoid the FAT patent issue?

If so, then we need to devise a naming scheme that fits within that... 
perhaps something like

llnn.ext


where:

 indicates which wiki

ll   indicates which language

nn   indicates which alphabetical section  (I assume the articles are 
grouped according to first letter, 00 through 26 for A-Z and other 
characters...   or is this wrong?)


Other alphabets have different numbers of letters, so do we sometimes 
need more than two digits?

And some languages don't use alphabets...   has somebody already worked 
out a general scheme for breaking up the files, and is this documented 
somewhere?


We have to break up the data into chunks somehow.  FAT has a 4GB file 
limit, as I recall...

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [wikireader]Suggestions for next steps on software

2009-10-30 Thread Doug Jones
Doug Jones wrote:
 David Reyes Samblas Martinez wrote:
 Though on how the evolution of the soft of the wikireader must be, I
 have oredered the sugesstions by impact on functionality/easy to
 implement ratio, of course under a totally  non-hardcore developer and
 only-one-week user criteria.
 *First and prioritary,
 allow have multiple languages on same sdcard, I think a one easy
 approach is to have a selection menu on boot with the available
 languages on the sdcard (looking at the sufix of the pedia files
 pedia_es, pedia_de, pedia_pt. ) present a bare text menu
 with the items, select,  and then operate as usual.
 More complex things like changing of language inside a topic or
 include non wikipedia content to  that menu using a config file can be
 implemented later on.
 
 
 I notice that the current implementation fits within the old 8.3 DOS 
 file naming scheme (except that both upper case and lower case is used). 
   Is this done to avoid the FAT patent issue?
 
 If so, then we need to devise a naming scheme that fits within that... 
 perhaps something like
 
 llnn.ext
 
 
 where:
 
  indicates which wiki
 
 ll   indicates which language
 
 nn   indicates which alphabetical section  (I assume the articles are 
 grouped according to first letter, 00 through 26 for A-Z and other 
 characters...   or is this wrong?)
 
 
 Other alphabets have different numbers of letters, so do we sometimes 
 need more than two digits?
 
 And some languages don't use alphabets...   has somebody already worked 
 out a general scheme for breaking up the files, and is this documented 
 somewhere?
 
 
 We have to break up the data into chunks somehow.  FAT has a 4GB file 
 limit, as I recall...


Actually it seems a bit more complicated than this.

The language designations used within Wikipedia are not just limited to 
two characters  --  these aren't just country codes.

Most languages there are designated by a two-letter code, but some are 
three letters, and go all the way up to simple for simple English and 
cbk-zam for Chavacano de Zamboanga.

Clearly we should be aiming for a system that can accommodate all 
available versions of Wikipedia, as well as those yet to be implemented.


The current implementation uses a flat directory structure, with no 
subdirectories.  Is there some compelling reason for this?

We could put each separate wiki into its own directory.  This would make 
it much easier to fit everything within the 8.3 naming scheme (assuming 
that this scheme really is a requirement).  It would also make it easier 
for the user to copy a new wiki onto the card;  they just have to copy 
one folder, instead of keeping track of dozens of files.

This would also eliminate the need for a config file at the root that 
would need to be updated as wikis are added or removed.  Instead, the 
boot code scans the root, finds all the directories, looks inside each 
one for a short metadata file that contains the description for that 
wiki (in the appropriate language of course), and then uses that data to 
build the first menu that the user sees.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[WikiReader] file system questions (was: [wikireader]Suggestions for next steps on software)

2009-10-30 Thread Doug Jones
[snip]
 I like this approach, just remind that as far I see the code and by
 comments of the devs, the kernel implements the bare just enough to
 read files, so I think directories are not implemented at all that's
 why all is on root directory so at least basic hierarchical filesystem
 has to be implemented before we can do this solution. But directories
 will easy the organization of pictures too


Good point.

So two important questions to be answered, before we get any further 
into this:

(1) Has OpenMoko made the policy decision that filenames will be limited 
to 8.3?


(2) How complicated will it be to implement subdirectory support?



Note that only one subdirectory level is really needed to implement what 
has already been suggested.

The current implementation contains 81 files, totaling 4.2GB for the 
English version.  Nearly all of that is in the big wiki data files 
(pedia*).  The other files, the ones you get when you make install, 
comprise 49 files and only 18MB, and most of that is fonts (which are 
often different for different languages).

We could adopt a brain-swap approach:  After bootup, the user selects 
one wiki and then the app switches to the selected subdirectory and 
considers that to be the root until the next cold boot.  All 81 files 
for that particular wiki and language would be in that subdirectory, 
including the big wiki data files and the fonts and the remaining files 
(45 files, only 381KB, and this includes ALL of the executables!)  While 
the single app is running, it would not have to access (or even know 
about) anything outside its current directory, so no filesystem calls 
relating to directory navigation would be needed within that particular 
kernel.elf.  Only the initial wiki selection app (we would have to write 
one) would have to understand subdirectories, and only to one level deep.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [WikiReader] file system questions

2009-10-30 Thread Doug Jones
David Reyes Samblas Martinez wrote:
 2009/10/30 Doug Jones dj...@frombob.to:
 [snip]
 I like this approach, just remind that as far I see the code and by
 comments of the devs, the kernel implements the bare just enough to
 read files, so I think directories are not implemented at all that's
 why all is on root directory so at least basic hierarchical filesystem
 has to be implemented before we can do this solution. But directories
 will easy the organization of pictures too

 Good point.

 So two important questions to be answered, before we get any further
 into this:

 (1) Has OpenMoko made the policy decision that filenames will be limited
 to 8.3?


 (2) How complicated will it be to implement subdirectory support?



 Note that only one subdirectory level is really needed to implement what
 has already been suggested.

 The current implementation contains 81 files, totaling 4.2GB for the
 English version.  Nearly all of that is in the big wiki data files
 (pedia*).  The other files, the ones you get when you make install,
 comprise 49 files and only 18MB, and most of that is fonts (which are
 often different for different languages).

 We could adopt a brain-swap approach:  After bootup, the user selects
 one wiki and then the app switches to the selected subdirectory and
 considers that to be the root until the next cold boot.  All 81 files
 for that particular wiki and language would be in that subdirectory,
 including the big wiki data files and the fonts and the remaining files
 (45 files, only 381KB, and this includes ALL of the executables!)  While
 the single app is running, it would not have to access (or even know
 about) anything outside its current directory, so no filesystem calls
 relating to directory navigation would be needed within that particular
 kernel.elf.  Only the initial wiki selection app (we would have to write
 one) would have to understand subdirectories, and only to one level deep.
 
 mmm this aproach will not complicate too much if after more apps than
 a reader are implemented? It would not be better to have a even a one
 level dir fs? nevertheless you will implement it for the starting
 menu, why not do it directly in the kernel and allow other apps take
 advantage of this implementation?
 Again talking from the most totally inexperience.


These are good questions.  But first we need to answer question #1 
above.  If we do indeed limit ourselves to 8.3 file names, that also can 
complicate a lot that we might want to do later, especially if we are 
limited to a flat directory.


When we are thinking about future apps to put on this device, we ought 
to be careful to keep in mind its current limitations, and what it would 
take to go beyond them.  It has no actual operating system, as most 
people understand this term.  Each app has to be almost completely 
self-contained.  There are no services to allow apps to talk to each 
other, and indeed only one app can run at a time.  When the WikiReader 
app is running, it is in complete control of the device and nothing else 
can run until you reboot the device.  (The WikiReader app is called 
kernel.elf for a reason.)

Changing this would require putting something resembling a real 
operating system on there.  This is certainly possible, but I suspect it 
is way, way beyond the scope of anything we have been talking about so far!


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [WikiReader] file system questions

2009-10-30 Thread Doug Jones
[snip]
 
 Yes, I had missed the point of the monolitic app, so then an easy
 approach to make different apps (menus,calculator, note taking, basic
 drawing, ...) is to enrich  it in the reader app itself this way maybe
 some services (read services as already implemented functions in the
 code of the reader app) can be used by the little apps, understanding
 than this little apps are not independent apps but just another screen
 of the same big app.
 


Actually, the possibility that interests me the most is the idea of 
making it easy to put additional content into the reader.  The current 
software is good at displaying textual content, and good at searching 
for text as well.  The hardware is less than optimal for the other types 
of apps you mentioned  --  but it's a good reader.

There are many sources of text that one might want to carry around in 
such a device, not just Wikipedia.  E-books, websites, mail archives, 
other wikis...   all we have to do is build the tools to convert the 
content into a format the device can understand.  This is much easier 
than writing new code to run on the device.


For those people who want to write code that runs on the device, there 
are plenty of things that would make it an even better reader.  But I 
expect to concentrate on the WikiReader tools that run on other computers.




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


carriers evolving in the U.S.

2009-10-26 Thread Doug Jones
Yes, but will any of this benefit Freerunner users?

http://market-ticker.org/archives/1542-Mobile-Phone-Wars!.html


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Wikireader] Any news on Wikireader ?

2009-10-22 Thread Doug Jones
-= Apertum =- wrote:
 Hello,
 
 The (very interesting, IMHO) Wikireader product has been launched about
 2 weeks ago, but still i don't see any information about hardware and
 software (IE we don't know if there is a Linux kernel in it, or not),
 and/or how it will be hackable by the community.
 
 It's there any news somewhere on the net, or when you at OpenMoko plan
 to discover these (important) informations?
 
 Thank you so much for your attention :-)
 


Look for the thread labeled [reader] on this list

I have one, and have been spending some time looking at the code and 
available docs.

It does not use a Linux kernel.  It is an embedded device containing 
only minimal amounts of software, just enough to be a WikiReader.  The 
WikiReader program itself is the kernel.

AFAICT the code on the device is entirely written in C and Forth, and is 
100% Free Software.  Unlike the Freerunner and every other cellphone on 
this planet, it does not contain any chunks of proprietary code (it 
doesn't need to worry about what the cell providers or the FCC thinks). 
  I don't think RMS would have any complaints about carrying one of 
these around.

This device is perfect for Free Software purists and for people who, for 
whatever reason, don't carry Internet access in their pockets.  (As the 
global collapse deepens, I expect more and more people will be unable to 
justify the monthly cost of carrying around Internet access.)


The wiki is small now but gradually growing:

http://wiki.github.com/wikireader/wikireader


Much of the documentation is stashed away in the source tree:

http://github.com/wikireader/wikireader


The device fits in my shirt pocket (barely) and has a daylight-readable 
monochrome LCD display with no backlight.  It's a touchscreen;  you 
scroll it up and down with a gesture, and follow links with a tap.

The on/off button is on the top edge.  It uses two AAA batteries, which 
should last a very long time as the device is extremely miserly.  You 
can use rechargeable (1.2 V) batteries if you like.

Under the display are three buttons:  Search, History, and Random.

The History button displays a list of the most recently displayed pages. 
  The other buttons are self-explanatory.

The database contains a text-only snapshot of the entire 
English-language Wikipedia, over three million articles.  You can search 
on any word in the text.  The touchscreen keyboard is a bit small for my 
fat fingers, but I can manage (it's capacitive, and won't work with a 
stylus).

It has no connectivity, other than a serial port I haven't tried yet, 
and SneakerNet (you take out the micro SD card and walk over to another 
computer to update its contents).  This lack of connectivity keeps the 
internals simple and the cost down.  The card and the serial port are in 
the battery compartment.

If you hold the first button down while you turn the device on, it 
displays a list of Forth programs you can run.  Just tap on the name.  A 
lot of these are diagnostics, but there is also a simple calculator and 
a drawing program.  If you know Forth, you can probably write your own 
program and put it on the card, I imagine.

If you hold the second button down while turning on, it runs the calculator.

If you hold the third button down while turning on, it starts up the 
serial console (19200 8N1).

The drawing program shows that the device could be used for pictures, 
but don't expect any Wikipedia image content  --  there isn't room on 
the card.  However, it might be practical to put in a lot of the 
diagrams that can be compactly stored as SVG files.  Hopefully somebody 
will add that functionality in, as well as equation support.

The microSD card that comes with it is an 8GB model.  I don't know if 
larger ones will work.  I hope so.

The card has 3.8GB of free space on it, so there is plenty of room for 
more content.  I have been looking into the possibility of adding custom 
content (the multi-wiki concept).


As I see it, there are two paths for code development:  New code to run 
on the device, and user-friendly cross-platform code to run on the 
user's desktop machine or laptop and which is used to simplify and 
manage the task of updating the contents of the SD card.

New code to run on the device would come from Forth programmers who can 
write new Forth apps, and embedded developers who can write C code for 
tiny machines that don't have operating systems.





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[WikiReader] can we edit the WikiReader wiki?

2009-10-22 Thread Doug Jones
I clicked that Edit button, but it seems to want money from me.  :-)

But I assume that somebody else here can edit this page:

http://wiki.github.com/wikireader/wikireader/building-from-source

In addition to the dependencies listed there, I also had to install 
gforth, qt4-qmake, and g++.


After installing those, I got as far as:


g++ -c -pipe -O2 -D_REENTRANT -Wall -W -DQT_NO_DEBUG -DQT_GUI_LIB 
-DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. 
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 
-I../../../wiki-app -I../../../samo-lib/include 
-I../../../samo-lib/drivers/include -I../../..//samo-lib/minilzo/ 
-I../../../samo-lib/lzma -I../../../samo-lib/fatfs/src 
-I../../../samo-lib/fatfs/config/c33/read-write -I. -I. -o main.o main.cpp
main.cpp:21:17: error: QtGui: No such file or directory




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Wikireader] Any news on Wikireader ? [OT]

2009-10-22 Thread Doug Jones
Carsten Haitzler (The Rasterman) wrote:
 On Thu, 22 Oct 2009 11:14:25 -0700 Doug Jones dj...@frombob.to said:
  
 This device is perfect for Free Software purists and for people who, for 
 whatever reason, don't carry Internet access in their pockets.  (As the 
 global collapse deepens, I expect more and more people will be unable to 
 justify the monthly cost of carrying around Internet access.)
 
 just fyi... the global collapse is likely past its bottom point. everything i
 see is either bumping aong the bottom or well on its way up. in australia/asia
 at any rate thats for sure. i don't think you're going to see any deepening in
 the west (australia excluded - it's hooking into the asian supply line so it's
 economy is more affected now the panic has gone, by supply and demand, and
 china's demand - india's too is on the up).
 
 no point panicing about deepenging problems.


Who's panicking?

On the back of my WikiReader, I'm planning to write Don't Panic in big 
friendly letters


 
 the usa though is in some deep poo poo and likely will see its currency
 devalue further. massive debt doesn't make the us economy look strong.
 especially as investors are over the panic now and need a safe haven for their
 money, it's a self-fulfilling prophecy that as the dollar goes down, moving
 money to a currency not tied to the dollar thats on the rise, makes sense, 
 thus
 putting up the # of dollars being sold and unless someone picks up the slack
 and buys the extra multi-billions of dollars as fast as they are sold, means
 that the dollar will go down further due to investors trying to go to another
 currency for safety. but then again, as the dollar drops, things will drift
 back to on-shore as the usa simply becomes cheaper and thus helping create
 jobs in making use produced goods + services cheaper. it'll reach equilibrium
 at some point... but that won't be for a while.
 
 (sorry. just had to point this out as the above didnt seem incredibly accurate
 given current world economic circumstances) :)



Yes, let us know how that works out   :-)


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [WikiReader] can we edit the WikiReader wiki?

2009-10-22 Thread Doug Jones
Christopher Hall wrote:
 On Thu, 22 Oct 2009 16:20:39 -0700
 Doug Jones dj...@frombob.to wrote:
 
 I clicked that Edit button, but it seems to want money from me.  :-)
 
 Did you create an account on github, I think the free account should
 work.


Ah!  I didn't even notice that option.  Duh.


 
 But I assume that somebody else here can edit this page:

 http://wiki.github.com/wikireader/wikireader/building-from-source

 In addition to the dependencies listed there, I also had to install 
 gforth, qt4-qmake, and g++.
 
  I can, I added the packages I use.
 (these are listed in doc/Using-schroot for Ubuntu jaunty_i386)



Yes, I didn't read that particular doc   because I am not using 
schroot, I'm just running Ubuntu 9.04 32-bit.

 
 After installing those, I got as far as:


 g++ -c -pipe -O2 -D_REENTRANT -Wall -W -DQT_NO_DEBUG -DQT_GUI_LIB 
 -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. 
 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 
 -I../../../wiki-app -I../../../samo-lib/include 
 -I../../../samo-lib/drivers/include -I../../..//samo-lib/minilzo/ 
 -I../../../samo-lib/lzma -I../../../samo-lib/fatfs/src 
 -I../../../samo-lib/fatfs/config/c33/read-write -I. -I. -o main.o
 main.cpp main.cpp:21:17: error: QtGui: No such file or directory
 
 maybe you are missing libqt4-dev
 


Yep, that's what I was missing.  Make worked this time.  Thanks!


Now the only questions left on my current open question list are:


How does one connect to that serial port?  Is there some kind of dongle 
one has to jam in there?


Will the WikiReader work with 16GB cards?  Or larger?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Wikireader] Any news on Wikireader ?

2009-10-22 Thread Doug Jones
Wolfgang Spraul wrote:
snip
 I don't think RMS would have any complaints about carrying one of 
 these around.
 
 Can you spend a bit of time to check the licenses? Chris Hall reviewed it
 so I'm sure it's all good, but since it is all statically linked together
 and GPL-licensed it means like you said every last bit of software needs
 to be at least GPL compatible. An independent review on this would be great.


Sure, that looks doable.  Thank goodness the codebase is so small.


 In addition to the microSD card, there is only a small bootloader in an
 EEPROM (to boot from the SD card), but I think it's free software and in
 the source tree as well.
 Reflashing that EEPROM is a bit tricky (though possible, needs documentation),
 but not sure who would need it.
 
 If you hold the third button down while turning on, it starts up the 
 serial console (19200 8N1).
 
 Is it documented somewhere how to hook up a serial cable?


Good question!  I looked under that sticker, and saw eight little golden 
contact pads.  Do we have to open the case and solder something onto there?


 Currently there are three simulators available (console, cocoa, Qt4), but
 when you want to do active development on the device, I think having a
 serial cable is the only way to get faster feedback cycles, log output, etc.
 
 It has no connectivity, other than a serial port I haven't tried yet, 
 and SneakerNet (you take out the micro SD card and walk over to another 
 computer to update its contents).  This lack of connectivity keeps the 
 internals simple and the cost down.  The card and the serial port are in 
 the battery compartment.
 
 If I think about this device, the one thing that pops out again and again
 is BRUTAL SIMPLICITY. That is the real beauty of it.
 You can load some software into this device, then give it to anybody and
 not be worried they will get lost in a number of buttons and options.
 They will (have to) focus on what you are delivering in front of their eyes,
 and one thing where the WikiReader excels technically is the capacitive
 touch screen, which makes interacting with it a joy.
 
 Get more software on it!
 :-)
 Wolfgang


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [reader] Wikireader received

2009-10-20 Thread Doug Jones
Torfinn Ingolfsen wrote:
 Hi,
 
 On Tue, Oct 20, 2009 at 1:41 AM, Doug Jones dj...@frombob.to 
 mailto:dj...@frombob.to wrote:
 
 
 
 This single change would approximately double the (already considerable)
 usefulness of the Wikireader to me.
 
 
 Aha - I think I see where this is going. :-)
 Next, I will want to have my ebooks on the SD card.
 Is there any software convert text only ebooks into Wikipedia format?


For any book that really is text only (for example all those Project 
Gutenberg books that are simple ASCII text files) all you have to do is 
create a wiki page on a wiki and dump the text onto the page.  (Might 
have to filter it a bit to get rid of characters that the wiki might 
confuse for wiki markup, but that should be pretty easy.)  Of course a 
wide variety of file formats can be exported to plain text by using a 
word processor.

I'm on an Ubuntu machine right now.  I can install MediaWiki (the 
software Wikipedia runs on) with a few clicks;  it's in the Ubuntu 
repositories.  Then I can run the wiki server on this machine and build 
a private wiki.  Then dump that data through Wikireader's tools, and 
you've got the compressed files to put on the SD card.

I haven't looked, but I'm guessing that there already exist tools for 
sucking HTML content and other kinds too into a wiki.  If not we could 
write some.

Here is the use case I am thinking of:

- A person who does not have any kind of internet access while away from 
home and work, but wants to carry a collection of useful information 
with them wherever they go.

Here, useful means useful to that particular person and perhaps not to 
anyone else.  Thus the need to make it easy for the user to collect the 
information together, get it into a format the Wikireader can use, and 
copy it onto the SD card.

I envision a desktop app I can install on this Ubuntu machine that 
simplifies these tasks, with a nice GUI interface and all.  I might even 
be able to write such a thing myself.  :-)

But the first step is to make the changes I outlined in the earlier 
post.  Unless I am completely mistaken, only a small number of patches 
would be required, so it would be relatively quick and painless and easy 
to debug.


Of course, an alternate approach is to add lots and lots of code to the 
Wikireader so that it can handle many kinds of formats.  This might 
happen in the future, perhaps OpenMoko is already working on this, but 
we have to recognize that this would be an embedded development problem 
and not one easily accessible to the many people who like to write nice 
cross-platform desktop apps using whatever toolkits and languages they 
happen to like.

The approach advocated here shifts almost all of the development to 
writing code that runs on desktops, and minimizes the amount of new code 
written to run on the Wikireader itself.

And as support for other formats is gradually added to the Wikireader 
itself, we can of course support that too if we wish.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [reader] Wikireader received

2009-10-20 Thread Doug Jones
arne anka wrote:
 For any book that really is text only (for example all those Project
 Gutenberg books that are simple ASCII text files) all you have to do is
 create a wiki page on a wiki and dump the text onto the page.
 
 i still don't really understand that focus on wiki.
 is it hardcoded into the reader?
 
 i'd think apps like plucker would be a far better alternative, not at  
 least because a lot of stuff already exists in plucker format (and others,  
 too) and plucker files are created with way less effort.
 why squeeze everything into a wiki first?


The Wikireader already has a program for displaying wikis.

If you want to port other programs onto this rather small embedded 
device, you are welcome to do so!  I hope people do exactly that.

But having never done embedded development myself, I could not even 
begin to guess how long that would take.

I have spent a bit of time looking through the source.  It appears to be 
written primarily in C and Forth, two languages I am not fluent in.  And 
there is no Linux under there, in fact there is very little that could 
be called an operating system.

For me, and a lot of other Wikireader owners I imagine, writing code to 
run on this device is not really an option.  But writing some code that 
runs on a typical desktop system, that converts content into a form that 
the device can use, looks much more like something I can do, and perhaps 
  fairly quickly (especially if somebody jumps in and helps a bit!).


In the last few hours I have succeeded in the following tasks, most of 
which I have never even tried before:

- Installing an empty MediaWiki server on my Ubuntu machine
- Building some wiki pages inside it
- Generating an XML dump from it

(And I haven't had to write any code at all so far)


Next I will try to use the Wikireader development tools to convert the 
XML dump into image files the device can understand.  If that works, I 
will copy them onto a blank SD card using the same filenames used by the 
Wikipedia data files, and then copy over the rest of the files from the 
original SD card.  Then I stick the new card into the Wikireader, turn 
it on, and see what happens.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[reader] Wikireader received

2009-10-19 Thread Doug Jones
I ordered it a few hours after Sean's announcement.

It arrived a few minutes ago.

It works.



However, I was disappointed that it contained no entry for Wikireader.



;-)



Was pleased to see it came with nice alkaline batteries, not those cheap 
carbon ones that eventually fail and destroy the device they came with.

But instead, I put in a pair of eneloop rechargeable NiMH batteries, 
1.2 volts.  Those seem to work just fine.

It came with an 8GB microSDHC card.  3.2GB free, plenty of room for more 
data.


Next:  Figure out how to hack in a extra button at the top level that 
takes us to a custom page where we can link in our own personal content...


...and some code to run on my desktop machine, to manage the content of 
these SD cards...


...thanks, guys, there goes another chunk of my copious spare time...

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [Off Topic] Prepaid SIM Suggestions

2009-09-02 Thread Doug Jones
Cameron Frazier wrote:
 Evening all,
 
 I'll be heading to the EU for a little over 2 weeks in a week or so,
 and am in need of some advice.  I'd like to use my FR over there, and
 as such need a prepaid SIM.
 
 As for requirements;
 1) I'd like to use the same card in Germany (Munich), France
 (Toulouse), and Switzerland (Lausanne)
 2) I need to be able to make/receive international calls/SMS
 3) I'd like to try out some of this newfangled GPRS stuff (N.America
 sucks this for reasonable plans).
 
 I'll be arriving in Munich so that'll be where I'll pick up the SIM.
 
 Since a good number of the community are from those areas, I'd like to
 ask your advice on a carrier/options for all this.
 
 Any suggestions?
 



Qik Roam has a prepaid SIM that works in hundreds of countries.

But I have no idea if anybody has succeeded in getting one working in a 
Freerunner.


http://www.qikroam.com

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Mailing list glitch?

2009-06-05 Thread Doug Jones
Harald Welte wrote:
 On Wed, Jun 03, 2009 at 03:21:26PM -0300, Werner Almesberger wrote:
 Doug Jones wrote:
 Has this bug been there all along?  Does our community's collective 
 memory have a hole in it?
 Seems that it chopped the mail at the line beginning with From.
 Not sure where the rest ended up ...
 
 It looks like the mailman/pipermail parser is somewhat broken and considers
 every line starting with ^From  as the beginning of a new mail
 (envelope-from).  This is really weird, one would expect this kind of bug in
 the UUCP days of the early 1990ies but not in 2009.
 

This is a test message.
 From this point on, will it be truncated in the archive?


I did a cursory search of the mailman-user archives:

http://www.mail-archive.com/mailman-users%40python.org/

but didn't find any reference to this bug.  I suppose we should report 
it to them.

Apparently they don't have a bug tracker, just the lists.  I imagine the 
code doesn't change very often.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Mailing list glitch?

2009-06-02 Thread Doug Jones
I read Sean's message this morning, and was going to send a link for it 
to a friend who is off-list.  So I went to the list's archive:

http://lists.openmoko.org/pipermail/community/2009-June/048966.html

As you can see, the version of Sean's message shown in the web archive 
has been almost entirely truncated.


Has this bug been there all along?  Does our community's collective 
memory have a hole in it?



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


what hardware version do I REALLY have?

2009-05-10 Thread Doug Jones
I ordered my FreeRunner from the Openmoko store in April 2009.  By that 
time, someone on the list was telling people that all FreeRunners 
currently shipping were hardware version 6 or later.  (I really wanted 
version 7, but decided I didn't want to wait, 6 would be good enough.)

Well, I just did cat /proc/cpuinfo and it said:

Revision : 0350

...which means hardware version 5, I think.


Did they really ship me an older hardware version?


The date code printed inside the phone is 20080605.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: what hardware version do I REALLY have?

2009-05-10 Thread Doug Jones
Johny Tenfinger wrote:
 On Sun, May 10, 2009 at 21:34, Marcel tan...@googlemail.com wrote:
 I don't think the aux led is such a significant change, it doesn't light
 that often anyway... I mostly see it on kernel panics which luckily isn't
 that often :D
 
 But other changes are less significant ;) Booting without battery,
 which still doesn't work... and SD/GPS fix, which is fixed by software
 ;)



Aargh..

The SD/GPS issue was the one I really wanted to avoid.  I waited for 
many months to order my Neo, just so I could avoid that.  Guess I just 
need to start not believing anything I read on this list.  ;)

I've spent the last month trying out various distros and various SD 
cards, with varying amounts of agony.
Does anyone know of a list somewhere of distros that have the software 
fix and are *known* to work well booted from SD cards 2GB, with GPS 
running?


...AND, if/when somebody succeeds in organizing a buzz fix party in 
California, is there any possibility of upgrading this v5 to v6 and then 
to v7?


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: US Buzz/GPS Fix

2009-04-22 Thread Doug Jones
+1

I'm also in California.  If somebody threw a Buzz Fix party anywhere in 
California, I would be there.  Isn't Openmoko in California too? 
Fremont Buzz Fix Party, anyone?


I do have soldering experience, but not with such small parts.  (In my 
day, everything was the size of a Buick.)  But I'm game.



Russell Dwiggins wrote:
 I'm interested as well.  I'm in the Southern California area.  I'm sure
 there's someone with the expertise in the area / country who can perform
 these fixes.
 
 Anyone?
 
 Russell Dwiggins
 -Original Message-
 From: community-boun...@lists.openmoko.org
 [mailto:community-boun...@lists.openmoko.org] On Behalf Of Staley, Daniel L
 Sent: Wednesday, April 22, 2009 11:01 AM
 To: List for Openmoko community discussion
 Subject: US Buzz/GPS Fix
 
 Hi all,
 
 I keep hearing of these great Buzz Fix parties going on across Europe, and
 think it is great that the community is pulling together like that.
 Has there been any word of one of these events or just someone in the United
 States attempting the same thing?
 
 I'd love to get the fixes (Buzz and GPS for sureperhaps also the audio
 capacitor?) applied to my freerunner, but don't have the soldering tools or
 expertise requiredI'm more of a software guy. =P
 
 Thanks,
 -Dan Staley
 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community
 No virus found in this incoming message.
 Checked by AVG - www.avg.com 
 Version: 8.0.238 / Virus Database: 270.12.1/2069 - Release Date: 04/20/09
 10:36:00
 
 
 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community
 


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Qik Roam SIM card?

2009-04-19 Thread Doug Jones
Has anybody tried a Qik Roam SIM card in a Freerunner?

http://qikroam.com/Shop/Buy.aspx

Pay-as-you-go voice and data.  They say it works in 213 countries, 
including the U.S.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: SD slot + suspend

2008-09-02 Thread Doug Jones
Daniel Benoy wrote:
 I've been having trouble with my SD card ever since I upgraded my kernel 
 (with 
 the unstable feed) and turned on suspend... specifically, it got wiped out :( 
  
 Multiple times.  I don't know if it's a coincidence or now.. I wonder if 
 someone who's brave and doesn't have important data on their card could try 
 reproducing this?   Mount a partition and/or run something like 
 badblocks /dev/mmcblk0 and then while that's going suspsend... and see if 
 your data goes poof.
 
 Maybe it's just me.. possibly a defective SD card.
 
 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community
 


This is a known problem.  I'm still waiting for a definitive resolution 
before I order my FR.

It's not just openmoko that's affected.  This same bug took down the SD 
card in my OLPC laptop back in January.

There have been persistent rumors that there are people who understand 
this problem and know how to fix it. But I still haven't seen any 
announcement that the problem has actually, really, finally been 
eliminated in any shipping software.

Apparently this bug doesn't affect cards of size 512MB and smaller.

Many people who are trying to do things that require SD cards are 
working around the problem by disabling suspend.  Battery life suffers, 
but at least development can happen.


http://docs.openmoko.org/trac/ticket/1802

http://dev.laptop.org/ticket/6532


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


openmoko.org site problems

2008-08-01 Thread Doug Jones
Go to

http://lists.openmoko.org/mailman/listinfo/

and try the links.  Some haven't been working lately, giving errors like:


Secure Connection Failed

lists.openmoko.org uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.

(Error code: sec_error_unknown_issuer)




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: openmoko.org site problems

2008-08-01 Thread Doug Jones
Jan Keymeulen wrote:
 On Fri 01 August 2008 om 10:06:32 GMT Doug Jones told us:
 Go to

 http://lists.openmoko.org/mailman/listinfo/

 and try the links.  Some haven't been working lately, giving errors like:


 Secure Connection Failed

 lists.openmoko.org uses an invalid security certificate.

 The certificate is not trusted because the issuer certificate is unknown.

 (Error code: sec_error_unknown_issuer)

 
 That's not the openmoko site's fault. The problem is exactly as your
 (Firefox 3?) browser says: the certificate isn't trusted. Which means
 openmoko didn't pay a 'trusted' third party to get their certificate
 signed.
 So if you add the certificate to you list of trusted certificates,
 all will be fine.
 
 ___
 Openmoko community mailing list
 community@lists.openmoko.org
 http://lists.openmoko.org/mailman/listinfo/community
 


Ah, yes.  Had heard about that a while ago, and forgot.  Thanks.

Strange that this is the first site that bit me, I've been using FF3 
since before release day...


I was thinking that there might be some other kind of problem with the 
site, as I also couldn't get into the openmoko bug tracker.  (But that 
is working fine now, there must have been something else going on 
yesterday that has already resolved itself.)

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Opening the Cellwaves

2008-07-27 Thread Doug Jones
Doc Searls:

...If we follow the second path, we'll fail at a fundamental mission, 
which is opening the infrastructure itself. To do that we need to create 
open phones that are damned good at being Net-generation radios and 
televisions, as well as recording and producing devices. We also need to 
work at making clear how much more business the carriers and phone 
makers will find in a world of generative devices, rather than 
locked-down ones — a world where anything is possible, rather than one 
where legacy monopolies get leveraged for the duration.


http://www.linuxjournal.com/content/opening-cellwaves


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-26 Thread Doug Jones
Joerg Reisenweber wrote:

snip

 As I think this seems to be quite a good clue to what's really happening here,
 quote from the OLPC ticket #6532:

snip


Yes, anybody working on this issue really ought to read that ticket in 
its entirety:

http://dev.laptop.org/ticket/6532

(keeping in mind that some of the earlier entries, from months ago, may 
contain erroneous data)

Note that some people think that this problem may affect things other 
than the SD card, and that external storage connected through USB might 
have a problem too.

OLPC really really wants to do aggressive power management.  They want 
to do things like halt the processor between keystrokes.  If they can't 
do suspend and resume in  100 msec, they may not ever be able to 
deliver the holy grail:  a laptop that can run for ten minutes on the 
power provided by one minute of muscle power from a four-year-old child.

If they can achieve this, then OpenMoko ought to be able to achieve such 
aggressive power management too.  That's how you get really long battery 
life.

It seems that reconciling the need for data integrity on flash drives 
with the desire to achieve excellent power management is a hard problem.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-24 Thread Doug Jones
Mikael Berthe wrote:
 * Doug Jones [EMAIL PROTECTED] [2008-07-24 01:21 +0200]:
 There have been some indications that partition type may have some 
 effect on this problem on the OLPC.
 
 I doubt it.
 
 So, shrink the default vfat partition that came on the card and put
 an ext3 on there too.  If you want to be adventurous, try some other
 types.
 
 Happens to me with ext3 partitions as well (or mixed vfat/ext3
 partitions).
 
 However if I restore the partition table the data are not corrupted,
 at least so far it's been all right...


Most people who use SD cards on OLPC are leaving them formatted as vfat, 
because Sugar can't see any other type.  I don't recall seeing any 
reports of partition table mangling from these people, who are the vast 
majority of OLPC users.

It's when they try something other than vfat that the corruption occurs. 
  When it happened to me, I had one vfat and one ext3 on there.

So on the OLPC at least, the corruption does seem to be correlated with 
partition type.


Because the number of people trying different file systems on the SD 
card was relatively small, and because the corruption was happening sort 
of randomly, it's been difficult to figure out what's happening.  Sample 
size too small.

People were making all kinds of assumptions based on the limited 
reports, some of them wrong.  If you look through that bug ticket and 
also various reports on forums and lists, you find contradictory 
information regarding which builds were affected, which file systems 
were affected, and so on.  This kind of noise makes it a lot harder to 
debug.  It's still not clear that this problem is understood, even six 
months later.

This is why I suggested that lots of people try various file systems in 
their Neos, even if they don't need to have a card in there right now. 
If there is indeed an SD problem in the Neo, we need lots of reports, 
otherwise the sampling size problem might drag out the debugging for 
months as happened with OLPC.

If there is no problem with SD, then there's no harm done.  You'll just 
have a lot of people walking around with SD cards they aren't using yet 
sitting inside their phones.



And of course it's entirely possible that the OLPC / SD problem has 
nothing to do with the Neo.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Doug Jones
Stefan Fröbe wrote:
 Hi,
 
 just a quick observation from my side that could possibly be related:
 Until yesterday, my 4GB SanDisk card worked fine with a recent (e.g. 
 2008-07-22 or 21) kernel - after an opkg upgrade this morning that got 
 me a new kernel I was surprised to see the card not beeing recognized 
 anymore - furthermore, its MBR was zeroed out, and no tool could read or 
 reformat it except a SD-Card recovery tool by Panasonic ( sdfv2003.exe 
 running only under Windows, of course ) !
 
 I now backup'ed the partition table and mbrs in hope to be able to dd it 
 back, should this happen again. Sorry, but I haven't got any logs as I 
 was busy recovering what was left, but I'll surly save them next time ...
 
 Stefan
 
 uname -a
 Linux om-gta02 2.6.24 #1 PREEMPT Wed Jul 23 06:34:19 CEST 2008 armv4tl 
 unknown


Not sure if this is connected with what you are seeing, but...

Something similar has been happening with SD cards on the OLPC laptop 
(another example of hardware specifically designed for the FOSS world) 
for at least the last six months.  Last time I checked, there was still 
no real fix.  Has been a major pain for people who want to multiboot  -- 
  forces them to use storage devices that don't fit inside the case.

http://dev.laptop.org/ticket/6532

I am getting the impression that interfacing to SD cards is hard.



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: strange problem with Intenso 4GB SDHC card

2008-07-23 Thread Doug Jones
Stefan Fröbe wrote:
 Thanks for the link, seems to be quite valuable to me as it explains the 
 background quite well!
 
 Something similar has been happening with SD cards on the OLPC laptop
 (another example of hardware specifically designed for the FOSS world)
 for at least the last six months.  Last time I checked, there was still
 no real fix.  
 
  
 Well, from recent comments it looks like a 400ms delay (yuck!) in
 drivers/mmc/core/sd.c is a temporary workaround, but the root cause (as 
 Andy already suggested) seems to be related to the resume cycle.
 
 Has been a major pain for people who want to multiboot  --
  forces them to use storage devices that don't fit inside the case.
 
 http://dev.laptop.org/ticket/6532
 
  
 At least it doesn't look like a HW issue with the card, then.
 
 Stefan


Just spent some time looking at that bug ticket again.  I've been trying 
to follow this story ever since my OLPC trashed the partition table on 
my 16GB SDHC card back in January.

A consensus seems to be building that suspend/resume is involved.  But I 
don't think anybody really understands what's going on, and people have 
been bashing their heads against this again and again for six months.

If something like this is happening in the Neo, then this could turn 
into a world of hurt.


Recommendation:


Everybody, get a Micro-SD card and stick it in your Neo.  Put some 
random files on it, you don't have to do anything serious with it, just 
let it sit in there for a while.  Periodically check that you can still 
see those files.  If you lose those files, post about it.  Maybe we 
should start a new thread to keep track of this data.

There have been some indications that partition type may have some 
effect on this problem on the OLPC.  So, shrink the default vfat 
partition that came on the card and put an ext3 on there too.  If you 
want to be adventurous, try some other types.

If more people start seeing problems like this, we ought to start 
comparing notes with the OLPC people who are working on this.  And 
Pierre Ossman too, he did a lot of work on SD support in the kernel.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


now Koolu makes a phone too ;-)

2008-02-07 Thread Doug Jones

http://koolu.com/Koolu-WE-Appliance/WE-Phone.html

looks kinda familiar


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Recent spam.

2008-01-07 Thread Doug Jones

flexd wrote:

I don't like spam. Do you? :(

There should be a boxtrapper or something to stop this :)



This person gets around.

I'm also on the laptop.org policy discussion mailing list.  These spams 
are showing up there too.  Same name and address:


Super Star [EMAIL PROTECTED]

So somebody is methodically going around to various open-source-related 
lists and subscribing, so they can enlighten us all for a while.



Judging by the headers, these are coming through Google's servers, so 
it's a real gmail account, not just a Joe Job spoof.


Anybody have any experience dealing with gmail admins?  Maybe we can get 
this account deleted.


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Use Neo w/out removing from pocket

2007-11-19 Thread Doug Jones

Michael Shiloh wrote:



AVee wrote:

On Saturday 17 November 2007 21:09, Joshua Layne wrote:

Ted Lemon wrote:

On Sat, 2007-11-17 at 11:19 -0800, Michael Shiloh wrote:

I'd like to explore adding a head mounted display to the Neo, like the
i-glasses PC/SVGA Head Mounted Display at about $700. Would require
an
off-board SVGA controller, which could be prototyped with a USB SVGA
controller, assuming Linux drivers can be found.



New thread since I realized that I was guilty of hijacking the laptop 
replacement thread.


My suggestion regarding a head mounted display was so that the Neo could 
  be used without taking removal from pocket, sort of the video display 
equivalent of the bluetooth headset. Ultimately, I'm sure we will have 
bluetooth head mounted displays, but we can prototype this right now 
with USB and start experimenting. What sort of applications make sense 
this way? What sort of new applications does this allow?


I'm well aware that the input side of things is not addressed yet, but I 
think we can explore the video side without having to wait for a 
solution on the input side. It will come soon enough, I'm sure. 
Especially once we start showing what we can do on the output side.


Michael



Seems unlikely bluetooth will ever be used for video.  Insufficient 
bandwidth.


Ultra wideband, on the other hand, should work fine.  High bandwidth, 
low power, but short range.


UWB chips are available.  Can get it in a USB dongle.  No special 
drivers required  --  just looks like USB to the host.


But I think you would need USB 2.0 to make this work.  Current Neo 
versions still use USB 1.1, don't they?


We need to build UWB into some future version of Neo.  That would open 
many doors.



___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Neo1973 drawings

2007-10-18 Thread Doug Jones

Alexey Feldgendler wrote:

On Thu, 18 Oct 2007 06:33:12 +0200, Doug Jones [EMAIL PROTECTED] wrote:

Would be great if somebody did a really thorough job of documenting 
the Neo case.  In other words, disassemble a Neo as described here:


http://wiki.openmoko.org/wiki/Disassembling_Neo1973

and make nice orthographic images of all the case parts, from all 
angles   --  back, front, edge-on, etc.


As far as I know, the GTA02 case would be different from GTA01 inside, 
though the outer shape doesn't change.






If this is true, then the GTA02 case should be documented in the same 
way, when we get our hands on it.  (I am planning to do this myself in 
December, if the current schedule holds.)


But the GTA01 should be documented too.  And the sooner this is done, 
the sooner we will be able to finish the designs of things like 
ExpansionBack and ExpansionSpacer, which should work equally well with 
GTA01 and GTA02.


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Neo1973 drawings

2007-10-17 Thread Doug Jones





for a start that some of us have made on the wiki. is anyone with a
GTA01 up for whipping out their micrometer/3d scanner and knocking
something together?
even better, is anyone at FIC/openmoko able and willing to provide us
with detailed drawings of the case?


If this doesn't happen before next wednesday, remind me and I'll measure 
up one of my GTA01s with my digital micrometer. I happen to be 1000km 
from it this weekend (my micrometer not my neo :-)



Would be great if somebody did a really thorough job of documenting the 
Neo case.  In other words, disassemble a Neo as described here:


http://wiki.openmoko.org/wiki/Disassembling_Neo1973

and make nice orthographic images of all the case parts, from all angles 
 --  back, front, edge-on, etc.


The easiest way to do this is to simply place the parts on a flatbed 
scanner.  And put a pair of short rulers on there too, at right angles, 
for calibration (millimeter scale!).


The orthographic images produced in this way aren't perfect, but they're 
a lot better than what you get with an ordinary camera, at least for 
some purposes.  You don't have to worry about camera angles and such, 
and the resolution is potentially much higher too.


By all means, make lots of measurements with the micrometer, everything 
you can think of that might be useful to somebody who wants to hack 
hardware or design add-on parts.  But with some good orthographic images 
uploaded into the wiki, people would have an opportunity to make 
measurements that weren't thought of when the micrometer measurements 
were made, or that aren't easy to make with a micrometer.


Some non-trivial things to measure include draft angles and radii of 
curvature (there are lots of these, as molded parts rarely have true 
sharp corners on them  --  these corners are usually radiused).


Use a high resolution, true color, PNG format.  Leave the scanner lid up 
and turn off the room lights for a nice black background.


Yes the image files will be large.  I don't mind, I have broadband.  :)




___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: Hooks in Base Code

2007-07-18 Thread Doug Jones

Jim McDonald wrote:
[This may have been better to post to the development list but as people 
are talking about it here I'll start here]


Hi,
   A number of people have been talking about the cool things that they 
would like their 'phone to do but after spending some time looking at 
the information available so far I don't see anything that suggests the 
current codebase will allow people the freedom that they need.  If I 
take a simple example of an incoming call them some of the suggestions 
that we have seen so far to handle it include different ring tones for 
different people or groups of people, auto-handling of the call by 
sending it to voicemail or letting it through, different responses 
depending on the time of day, /etc.  /The point that I'm trying to make 
is that there are a multitude of things that you /could/ do but each 
person will have a limited number of things that they want the 'phone to 
/actually/ do.  As such, building out all of these options in to a 
single piece of code will not only be very hard to manage and maintain 
but will severely limit the ability of people to scratch their itches 
and develop code to make the 'phone do what they want it to.


   If the monolithic approach is out then some sort of modular approach 
is required.  The most obvious example out there today is Firefox, which 
comes in a relatively simple base configuration but provides any number 
of hooks to allow people to write their own extensions on top of the 
base code and as such to alter the functionality of the product very 
extensively.  If we want this openmoko to be as free as possible then it 
also needs to be as easy as possible for people to extend, and this is 
the most likely way of doing it.


   I know that there are a lot of potential problems that need to be 
addressed when building this out but if there is a vision from the start 
as to how this would work then it would go a long way to making the 
final product the 'phone that we are all dreaming of, regardless of the 
fact that those dreams are often divergent from others if not totally 
exclusive.  So my questions are there plans to include these hooks, and 
if not can it be considered?


   Or is there another way to do this other than hooks?

Cheers,
Jim.




Take a look at EToys.

http://en.wikipedia.org/wiki/EToys_%28Programming_Language%29

[whoa, that article doesn't even mention OLPC, gotta go edit that]

and look at these tiles:

http://community.ofset.org/wiki/En-Presentation_of_Squeak_Visuals-Toys

Now, imagine a tile that looks like a Neo.  It represents the GSM 
transceiver and modem that lives inside the physical Neo.


It has a mike at the bottom and a little speaker at the top.  Those are 
the hooks  --  you connect them with little lines to the connectors on 
other tiles.  It has other hooks too, for the other signals that go in 
and out, like Caller ID and ring signals and such.


Of course you have a whole lot of tiles, for sound recorders and sound 
players and GPS receivers and WiFi and Bluetooth and everything else you 
can think of.  And all that math and program control stuff too.


You just program your Neo to do whatever you want it to do by hooking 
all these tiles together.


Now most people wouldn't have a clue how to do such a thing, including a 
lot of us old fogeys around here, but if the OLPC people get their way 
millions of children will be learning how to do exactly that Real Soon 
Now.  They will even have the same set of tiles on their little laptops.


And in a few years tens of millions of children will be doing it.  And 
then, maybe, hundreds of millions.


Pretty much anything they can do in their XOs can also be done in a Neo. 
 And anything they create will work in a Neo too, and it doesn't even 
have to be ported.  EToys runs on Squeak, and Squeak runs bit 
identically on so many different platforms that it makes my head hurt 
just thinking about it.


So we're gonna have a whole generation of kids who are absolute masters 
of their little personal Universal Communications Platforms.  Doesn't 
matter if it's an XO or a Neo or whatever, they all work the same, 
seamlessly.  And any task they set their minds to, as long as it fits 
within the constraints of memory and CPU time and battery life, they 
will accomplish.




Never been so scared in my entire life.



Now even if only a tiny fraction of all the wondrous stuff they invent 
is useful to the rest of us, that will be a whole lot of wondrous stuff. 
 And since it's all open source, you'll just go click on a web page on 
that little screen and there it's installed.


We'll have so many choices it's bound to get confusing for a while.  And 
then Darwinian things happen and the best solutions rise to the top. 
Nobody can predict what things will look like.


Predicting what things will look like is a popular sport around here, 
and important, but it's not really what OpenMoko is about right now. 
It's about making something that 

this phone, with WiFi

2007-07-15 Thread Doug Jones

I have a little WiFi USB dongle.  Found it at Frys for like $5.

Tried it on an Ubuntu machine about a year ago.  It works.


Assuming one has an appropriate cable, and assuming one can find some 
way to get power into the thing, it ought to be possible to make it work 
with the Neo.  (The Neo that is hopefully shipping next week, the one 
without built-in WiFi.)


Assuming that all of the software interfaces used in the Neo to talk to 
WiFi hardware are sufficiently general, it shouldn't be particularly 
difficult to get this Neo working with this dongle.  (Or any other 
dongle that has open source drivers, for that matter.)


Aside from the people working on the actual drivers for the coming WiFi 
Neo, people who are working on WiFi-aware apps are hopefully _not_ going 
to be hard-coding things that work with the Atheros AR6K and nothing 
else.  So these apps could be tested on actual Neo hardware with one of 
these cheap dongles added.


So maybe we could have WiFi awareness actually working before the next 
phone ships in October.



Now I have recompiled a kernel before, but I've never built OpenMoko 
before and I've never messed with wireless drivers either, so I don't 
really have a good idea about how 'particularly difficult' it would be 
to do what I just described with random cheap dongles.  But I figure 
there are people here who _do_ know.


It's only three months before the next phone ships.  Is it worth it to 
take the time to mess with dongles?


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: this phone, with WiFi

2007-07-15 Thread Doug Jones

Christian Fischer wrote:

Doug Jones schrieb:


Assuming one has an appropriate cable, and assuming one can find some
way to get power into the thing, it ought to be possible to make it work
with the Neo.  (The Neo that is hopefully shipping next week, the one
without built-in WiFi.)


The USB-Bus Device is unpowered. It uses external Power for Battery
Charging.

So try to make your own 5V supply.


Getting power into it isn't really a problem, at least as long as you're 
not trying to be portable.  For development purposes, you can tie 
yourself down with wires.


There are lots of USB chargers on the market now.  I see them at Frys 
for less than $10;  they seemed to be aimed primarily at the iPod crowd. 
 And doesn't the Neo come with one?


One could also use a powered USB hub.  (And couldn't you just use the 
USB hub on the debug board if you have the Advanced package?)



I recently found a hand-crank flashlight that has a built-in USB charger 
(and a radio too).  Two for $18 at CostCo.  (Unfortunately, it only 
supplies power to the USB connector while you are turning the crank. 
Would be handy if you could power external things directly from the 
energy already stored in the flashlight's rechargeable battery.)



Anyway, figuring out how to power an external WiFi adapter isn't the 
main issue.  The question is, is it worth the time to monkey around with 
WiFi drivers for hardware that isn't going into the final product, just 
so we can test WiFi apps before the proper hardware is available?


___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community