Re: JFFS2 file sizes

[Jim Gettys]

Jffs2's compression is OK, but as the block size of the compression
blocks is relatively smaller than a gzipped archive, for large objects
it's less efficient than gzip.  

Dave Woodhouse may be able to give typical numbers (he wrote jffs2, and
we're fortunate to have him working on OLPC)..  And individually gzipped
small files may not do much better than jffs2.

But you don't want uncompress the data twice, which is a power loss.

And images typically don't compress significantly, anyway; putting them
into a gzip archive is just a waste of joules; in much web content, the
images dominate.   Better there is to adapt the images to exactly
optimize to our screen; often the image data is much higher quality than
can actually be displayed.
 - Jim


On Wed, 2007-07-25 at 14:58 -0500, Ian Bicking wrote:
> When considering what content can be shipped or stored on the laptop, 
> we're wondering what the real disk(/flash) usage is for files.  Since 
> JFFS2 is doing compression behind the scenes, it's not completely clear. 
>   Also, it would be nice if we could estimate how much disk something 
> will use without actually having to put the content on a laptop.
> 
> My guess is that there will be per-file compression using gzip/zlib.  So 
> we could estimate the size by doing something like:
> 
>copy -r uncompressed-files compressed-files
>gzip -r compressed-files/*
>du -s --apparent-size uncompressed-files compressed-files
> 
> Should I use --apparent-size?  Otherwise it looks like du is taking into 
> account the actual disk usage, which on my ext3 system isn't going to be 
> representative.  Presumably there's some filesystem overhead on JFFS2, 
> but maybe less than on ext3.  Will du give accurate disk usage amounts 
> on the laptop (taking into account compression)?  If there was an 
> equation that would be handy, e.g.:
> 
>alignment = 1024
>directory_overhead = overhead = 256
>directory_file_listing = 256
>def file_size(filename):
>if os.path.isdir(filename):
>return (directory_overhead +
>directory_file_listing*len(os.listdir(filename)))
>compressed_size = len(open(filename, 'rb').read().encode('zlib'))
>compressed_size += compressed_size % alignment
>compressed_size += overhead
>return compressed_size
> 
> 
-- 
Jim Gettys
One Laptop Per Child


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Request hosting for project wikislice

[Mitchell N Charity]

1. Project name : wikislice
2. Existing website, if any :
3. One-line description : Wikipedia subsets and tools.

4. Longer description   : Creating Wikipedia subsets and tools for
   : school servers, laptops, and individuals.
   :
   :

5. URLs of similar projects :

6. Committer list 
  Please list the maintainer (lead developer) as the first entry. Only list 
  developers who need to be given accounts so that they can commit to your

  project's code repository, or push their own. There is no need to list
  non-committer developers.

 Username   Full name SSH2 key URLE-mail
    - --
  #1  sj
  #2  andy
  #3  lucks
  #4  mncharity
  #5  arael   Zdenek Broz   attached [EMAIL PROTECTED]
 ...

  If any developers don't have their SSH2 keys on the web, please attach them 
  to the application e-mail.


7. Preferred development model

  [X] Central tree. Every developer can push his changes directly to the 
  project's git tree. This is the standard model that will be familiar to 
  CVS and Subversion users, and that tends to work well for most projects.


  [ ] Maintainer-owned tree. Every developer creates his own git tree, or
  multiple git trees. He periodically asks the maintainer to look at one
  or more of these trees, and merge changes into the maintainer-owned,
  "main" tree. This is the model used by the Linux kernel, and is 
  well-suited to projects wishing to maintain a tighter control on code

  entering the main tree.

  If you choose the maintainer-owned tree model, but wish to set up some
  shared trees where all of your project's committers can commit directly, 
  as might be the case with a "discussion" tree, or a tree for an individual 
  feature, you may send us such a request by e-mail, and we will set up the 
  tree for you.


8. Set up a project mailing list:

  [ ] Yes, named after our project name
  [ ] Yes, named __
  [X] No

  When your project is just getting off the ground, we suggest you eschew
  a separate mailing list and instead keep discussion about your project
  on the main OLPC development list. This will give you more input and 
  potentially attract more developers to your project; when the volume of 
  messages related to your project reaches some critical mass, we can 
  trivially create a separate mailing list for you.


  If you need multiple lists, let us know. We discourage having many 
  mailing lists for smaller projects, as this tends to

  stunt the growth of your project community. You can always add more lists
  later.

9. Commit notifications

  [ ] Notification of commits to the main tree should be e-mailed to the list
  we chose to create above
  [ ] A separate mailing list, -git, should be created for commit
  notifications
  [X] No commit notifications, please

10. Shell accounts

  As a general rule, we don't provide shell accounts to developers unless 
  there's a demonstrated need. If you have one, please explain here, and

  list the usernames of the committers above needing shell access.

11. Notes/comments:

This project absorbs development currently taking place on crank's filesystem.


 BEGIN SSH2 PUBLIC KEY 
Comment: "rsa-key-20070723"
B3NzaC1yc2EBJQAAAIBsarVS4EN/gWaqE6NFJaXX0k0BaUB7j9KM+cd6
D/ws27xGvcGKgL7a0rhp/qkwl7rWUzVmSfYyd1kmuW8Ux8ja782BADFwPl3vkFam
deEGoiWcYvN9mlx7DhiXr6JkSELDZ/qPVgzLJsZwmtzWv+3O1SX2sczJrVlbzQWx
2zWXoQ==
 END SSH2 PUBLIC KEY 
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XOs interacting with general computers (was: Devel Digest, Vol 17, Issue 52)

[elw]

> I think a critical point is to make sure they get at least the chance to 
> learn responsible/safe behavior first.

Yes - whatever that happens to be for their particular locale and 
sociocultural positioning.  This is not something that I am particularly 
comfortable with the notion of us people "from outside" strongly 
influencing.  We don't have the context, and should avoid the temptation 
to impose mores or practices that we think are 'most' valuable.

To some extent, I think it is worthwhile to watch people who have 
previously not had access to technology evolve their own responses to it; 
they may come up with new things that are better than what anyone else 
currently has.


> An approach I've seen at schools in the US was that they taught the kids 
> what to do/not to do, but then basically allowed unrestricted access.


Yes; this happens a lot and is quite counterproductive.  We have to 
remember, though, that teachers in the US are not always the most 
sophisticated of beings.  They do what they think is best, but largely 
work independently of much supervision.


> Unfortunately these days that approach can land you in jail in certain 
> US states.

*nod*

> Having the school/teacher as an intermediary/safe guard could be an 
> approach. As you wrote, the decision about access needs to be made in 
> the local context including aspects/variables that we probably don't 
> have the faintest idea about.


I think that the host countries are largely going to deal with this 
independent of OLPC; at the school server or at the uplink to the rest of 
the world seems like the right 'boundary' to me.

[I wonder what the school server team thinks about being folks' target for 
censorware deployment..]

--e
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: JFFS2 file sizes

[Ian Bicking]

Ian Bicking wrote:
> When considering what content can be shipped or stored on the laptop, 
> we're wondering what the real disk(/flash) usage is for files.  Since 
> JFFS2 is doing compression behind the scenes, it's not completely clear. 
>   Also, it would be nice if we could estimate how much disk something 
> will use without actually having to put the content on a laptop.

 From Chris Ball and David Woodhouse on IRC I understand that:

JFFS2 compresses 4K chunks using zlib.  So it's not just per-file 
compression, it's compressing bits of a file.  It doesn't compress files 
where compression doesn't help.  And there's a 68 byte overhead per 
compressed chunk.  Plus probably some fixed overhead per file.

Running "mkfs.jffs2 --root DIR | wc" gives a more accurate picture of 
the size of a directory.  Things might change as the compression 
parameters of JFFS2 are changed; specifically LZO compression is better 
than zlib, and there might be an attribute to disable compression on a 
particular file.

I wrote a little Python script to estimate the size and compare it to 
the actual size from mkfs.jffs2 (if you have that available on your 
system), and to the original size.  For small files (500 bytes - 1.5K) 
it's compressed to 50% of the size, for Python source code 40% of the 
size (with .pyc files), the Gnome 2 User Guide (with lots of images) 
gets to about 65% (35% reduction).

Script at: http://svn.colorstudy.com/home/ianb/olpc/jffs2size.py

-- 
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
 : Write code, do good : http://topp.openplans.org/careers
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

JFFS2 file sizes

[Ian Bicking]

When considering what content can be shipped or stored on the laptop, 
we're wondering what the real disk(/flash) usage is for files.  Since 
JFFS2 is doing compression behind the scenes, it's not completely clear. 
  Also, it would be nice if we could estimate how much disk something 
will use without actually having to put the content on a laptop.

My guess is that there will be per-file compression using gzip/zlib.  So 
we could estimate the size by doing something like:

   copy -r uncompressed-files compressed-files
   gzip -r compressed-files/*
   du -s --apparent-size uncompressed-files compressed-files

Should I use --apparent-size?  Otherwise it looks like du is taking into 
account the actual disk usage, which on my ext3 system isn't going to be 
representative.  Presumably there's some filesystem overhead on JFFS2, 
but maybe less than on ext3.  Will du give accurate disk usage amounts 
on the laptop (taking into account compression)?  If there was an 
equation that would be handy, e.g.:

   alignment = 1024
   directory_overhead = overhead = 256
   directory_file_listing = 256
   def file_size(filename):
   if os.path.isdir(filename):
   return (directory_overhead +
   directory_file_listing*len(os.listdir(filename)))
   compressed_size = len(open(filename, 'rb').read().encode('zlib'))
   compressed_size += compressed_size % alignment
   compressed_size += overhead
   return compressed_size


-- 
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XOs interacting with general computers (was: Devel Digest, Vol 17, Issue 52)

[Bruno Coudoin]

I don't have a solution either but I have have been in touch with one
organisation concerned by child abuse in France. What they told me is
they would like to provide the children with an easy way to report
abuse.

The hard problem is that if an organisation go in an online forum with
the nick littlegirl_11yo, they will see abuse but it has no value for a
judge because they are adults. So they need to get report from children
directly. If the child can understand there is an abuse, she can't
easily report it, even the adults beside won't be able to easily gather
all the information needed to catch the offender because they lack the
technical knowledge.

Based on that, I would suggest to have an 'Abuse report' button that
would gather the information and send it to a team that will analyse and
take the appropriate actions. This could be to improve the filtering
system if any, blacklisting, or even go to the police with the
evidences.

Like in real live, there is no way to avoid abuse but it's rare because
the offenders are easily detected and are punished.

Bruno.



___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Registration w/ school server

[C. Scott Ananian]

On 7/25/07, Ivan Krstić <[EMAIL PROTECTED]> wrote:
> On Jul 24, 2007, at 7:38 PM, C. Scott Ananian wrote:
> > I need to make sure XO registration w/ the school server works for
> > Trial-2. Ivan, if you've got an security/protocol designs/requests,
> > now is the time.
>
> You should coordinate with Nelson and Christine who I've asked to
> write the prototype identity manager for the school server. Let's
> meet soon and hash out the details.

This is bug #1505 (http://dev.laptop.org/ticket/1505) which is a
Trial-2 blocker.  The XO code for registration needed to go into the
build last week.  Let's all meet *today*.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Activation and new builds.

[C. Scott Ananian]

On 7/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi, C.Scott,
> Excuse me to bother you.
> If I want to use command "nandwrite -p /dev/mtd0 /path"
> The method from
> http://wiki.laptop.org/go/Installing_to_NAND#flash_eraseall:_.2Fdev.2Fmtd0:_No_such_file_or_directory
> What do I need to notice?

Please use the "Autoreinstallation Image", linked to from
http://wiki.laptop.org in the top right box: "how to update".
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XOs interacting with general computers (was: Devel Digest, Vol 17, Issue 52)

[elw]

good.

looking forward to seeing you write up your ideas w.r.t. it - I guess it 
really *is* somewhat related to the things you're doing.  :-)

--e


> Precisely.
>
> Precisely.
>
> ... and precisely.
>
> Anyway, I'm pretty comfortable with my thinking about this set of 
> problems for FRS and hope to write something up about it soon. Cheers,
>
> --
> Ivan Krsti <[EMAIL PROTECTED]> | http://radian.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XOs interacting with general computers (was: Devel Digest, Vol 17, Issue 52)

[Michael Rueger]

[EMAIL PROTECTED] wrote:
...

thank you for your thoughtful answer!

> 
> I'll say it again.. I think that it is important to protect kids, but 
> probably MORE important to make sure that 'protection' isn't cutting 
> them off from flexibility and the opportunity to gain new educational 
> experiences.

Couldn't agree more :-)

I think a critical point is to make sure they get at least the chance to 
learn responsible/safe behavior first.
An approach I've seen at schools in the US was that they taught the kids 
what to do/not to do, but then basically allowed unrestricted access. 
Unfortunately these days that approach can land you in jail in certain 
US states.

Having the school/teacher as an intermediary/safe guard could be an 
approach. As you wrote, the decision about access needs to be made in 
the local context including aspects/variables that we probably don't 
have the faintest idea about.

Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XOs interacting with general computers (was: Devel Digest, Vol 17, Issue 52)

[Ivan Krstić]

On Jul 25, 2007, at 9:56 AM, [EMAIL PROTECTED] wrote:
> this is made much more complex by the fact that XOs will end up in
> countries with very different social taboos, different cultural
> assumptions, and very different legal systems.

Precisely.

> hardwiring censorship/filtering/content-protection into the XO is  
> probably
> antithetical to the educational goals of the project.

Precisely.

> While it is very important to protect kids from some things that  
> they are
> really not cognitively equipped to handle, it is also important to  
> equip
> them with a toolbelt of educational possibilities that can be applied
> freely and without too many crazy restrictions.

... and precisely.


Anyway, I'm pretty comfortable with my thinking about this set of  
problems for FRS and hope to write something up about it soon. Cheers,

--
Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XOs interacting with general computers (was: Devel Digest, Vol 17, Issue 52)

[elw]

>> does anyone see danger in letting nonXOs talk to XOs, these are
>> handled by 8 year olders
>>
>> Yes, we recognize there are very real dangers. Various security 
>> settings and UI elements will likely be used to make it clear to the 
>> user, and
>
> You must be kidding me. We are talking about very young kids, probably 
> without supervision from internet savvy adults. How do you expect them 
> to make good decisions on contact requests?

they probably can't, and won't, and at some point it seems likely that 
SOMEONE is eventually going to have to address this.

this is made much more complex by the fact that XOs will end up in 
countries with very different social taboos, different cultural 
assumptions, and very different legal systems.

hardwiring censorship/filtering/content-protection into the XO is probably 
antithetical to the educational goals of the project.

for people in the outside world to contact kids with XOs gatewayed behind 
a school jabber server could be obfuscated fairly trivially, i would 
think.  [maybe the addresses to contact from the outside should be... 
maybe an sha-1 of '[EMAIL PROTECTED]' @ 
schoolserver.xo.network??  Something similarly trivial to generate.]

kids who are smart enough to hunt up the jabber addresses of people in the 
outside world well, you'd hope that they'd be able to be quickly 
educated about appropriate behavior.


I would hate to see a situation where kids got hurt or were punished 
because some nutjob in the outside world decided to send 
culturally-vastly-inappropriate content to some kid with an XO in a 
societal situation that had not yet evolved means for coping with highly 
offensive content delivered automagically by means of Internet.



> > protect them where appropriate, from random third-parties.
>
> Define "where appropriate"...

I think that this is a highly complex situation, and one that merits a 
whole lot of thought.

While it is very important to protect kids from some things that they are 
really not cognitively equipped to handle, it is also important to equip 
them with a toolbelt of educational possibilities that can be applied 
freely and without too many crazy restrictions.

Let's imagine that a kid decides he wants to interview some kind and 
willing person from the US, who is not very hard to track down contact 
info for.  Let's say... Jim Gettys.

Should the kid not be able to contact Jim and ask him interview questions, 
just because he's an "outside person", not necessarily running inside the 
XO network?

What if a (slightly older) kid wants to collaborate with an outsider on a 
school project, drawing on the outside person's life or career experience 
in order to enhance what they themselves are doing in the local school?

Imagine all of the positive things that can happen in a social interaction 
between kids and non-kids... and then weigh that against the need to 
'protect' kids from the real world.


I'll say it again.. I think that it is important to protect kids, but 
probably MORE important to make sure that 'protection' isn't cutting them 
off from flexibility and the opportunity to gain new educational 
experiences.

Any proposed solution really needs to do both.


--e
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: XOs interacting with general computers (was: Devel Digest, Vol 17, Issue 52)

[Michael Rueger]

MBurns wrote:
> On 7/23/07, *Nehemiah Dacres* <[EMAIL PROTECTED] 
> > wrote:
> 
> does anyone see danger in letting nonXOs talk to XOs, these are
> handled by 8 year olders
> 
> 
> Yes, we recognize there are very real dangers. Various security settings 
> and UI elements will likely be used to make it clear to the user, and 

You must be kidding me. We are talking about very young kids, probably 
without supervision from internet savvy adults. How do you expect them 
to make good decisions on contact requests?

 > protect them where appropriate, from random third-parties.

Define "where appropriate"...

Michael

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

RE: Touchpad can not smooth to move mouse

[Luna.Huang]

Ok, I know.
Now I must think one way to reproduce the same event.
I lose the question.
Thank you very much.
Luna

> -Original Message-
> From: Jim Gettys [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 25, 2007 10:34 AM
> To: Luna Huang (�S��玲)
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; devel@lists.laptop.org;
> [EMAIL PROTECTED]
> Subject: RE: Touchpad can not smooth to move mouse
> 
> Luna,
> 
> If you have followed the procedure as documented in the wiki as in
> Michael's mail, then it is time to get Alps involved to do root cause
> analysis on the units that do not work properly.
>  - Jim
> 
> 
> On Tue, 2007-07-24 at 11:12 +0800, [EMAIL PROTECTED] wrote:
> > We have a new discovery.
> >
> > The original, image is 526.img and 406.14.img, bios is Q2C18.
> >
> > The touchpad can not smooth to move mouse even we have recalibrated.
> >
> > Then install image return to 406.img and bios Q2C11.
> >
> > The mouse of machine can normally respond.
> >
> > Last we afresh install to 526.img, 529.img and bios Q2C18.
> >
> > The original event does not happen again.
> >
> > Now we have two machines have the issue.
> >
> > We will set them a long time and watch the event will happen again or
> > not.
> >
> > Does any one have ideal about it?
> >
> > Luna
> >
> >
> >
> >
> >
> >
> __
> 
> > From:[EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > [EMAIL PROTECTED]
> > Sent: Tuesday, July 24, 2007 8:31 AM
> > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Cc: devel@lists.laptop.org; [EMAIL PROTECTED]
> > Subject: RE: Touchpad can not smooth to move mouse
> >
> >
> >
> >
> > Sorry I forget to say.
> >
> > Bios is Q2C18.
> >
> > My machine is using shipping image (406.XX.img).
> >
> > Install image to 526.img has the same question.
> >
> > I have tried the recalibrate but it dose not really work.
> >
> > The mouse does not respond.
> >
> > When I do an action that draw a line from upper left to lower right on
> > GS.
> >
> > The mouse just moves a little or does not move on sugar frame.
> >
> >
> >
> > Luna
> >
> >
> >
> > > -Original Message-
> >
> > > From: Zephaniah E. Hull [mailto:[EMAIL PROTECTED]
> >
> > > Sent: Monday, July 23, 2007 11:29 PM
> >
> > > To: Luna Huang (S玲)
> >
> > > Cc: devel@lists.laptop.org; [EMAIL PROTECTED]
> >
> > > Subject: Re: Touchpad can not smooth to move mouse
> >
> > >
> >
> > > What build version are you using?
> >
> > >
> >
> > > Zephaniah E. Hull.
> >
> > >
> >
> > > On Mon, Jul 23, 2007 at 08:13:04PM +0800, [EMAIL PROTECTED]
> > wrote:
> >
> > > > Um ~ ask a question.
> >
> > > >
> >
> > > > I find my B4 OLPC whose mouse can not smooth moving on sugar.
> >
> > > >
> >
> > > > The issue only happens on Glidesensor(GS) but not on Pentable(PT).
> >
> > > >
> >
> > > > I find resistive can normally respond the mouse address but
> > capacitive is hard.
> >
> > > >
> >
> > > > And catch the driver “/dev/input/mouse0”, it has a little of
> > response when move
> >
> > > the mouse.
> >
> > > >
> >
> > > > At first I think maybe ALPS touchpad device is broken.
> >
> > > >
> >
> > > > Then do mouse test on OFW.
> >
> > > >
> >
> > > > Find the touchpad device can normally respond on GS test and PT
> > test.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Now I judge that the device is not broken and the question happens
> > on other HW
> >
> > > devices.
> >
> > > >
> >
> > > > Somebody can give me ideal to fine which one device has wrong.
> >
> > > >
> >
> > > > I am not sure what different between driver and OFW test.
> >
> > > >
> >
> > > > Want to solve the question but only can measure waveform just
> > that.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Thanks.
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > Luna
> >
> > > >
> >
> > >
> >
> > > > ___
> >
> > > > Software-team mailing list
> >
> > > > [EMAIL PROTECTED]
> >
> > > > http://lists.laptop.org/listinfo/software-team
> >
> > >
> >
> > >
> >
> > > --
> >
> > > 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]>
> >
> > >  92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
> >
> > >   CCs of replies from mailing lists are requested.
> >
> >
> > ___
> > Devel mailing list
> > Devel@lists.laptop.org
> > http://lists.laptop.org/listinfo/devel
> --
> Jim Gettys
> One Laptop Per Child

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel