From: Theodore Ts'o <tytso@mit.edu>
To: David Lang <david@lang.hm>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Is there a particular reason cerowrt isn't using UBIFS?
Date: Sun, 31 Aug 2014 18:03:07 -0400 [thread overview]
Message-ID: <20140831220307.GI8974@thunk.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1408311234340.433@nftneq.ynat.uz>
On Sun, Aug 31, 2014 at 12:37:07PM -0700, David Lang wrote:
> As a datapoint in this discussin, take a look at the openwrt thread
> [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of
> binaries produced by Barrier Breaker relative to Attitude Adjustment
>
> Apparently with BB they changed the gcc options on mips to produce 16 bit
> code because it results in smaller binaries, but this cripples performance
> in some cases
>
> It doesn't answer your funding issue, but it shows another case of people
> being very sensitive to storage size.
Right, but *wrt is a bit of a special case, since what we're trying to
do here is shoehorn a different software load unto pre-existing
hardware where someone else has already cost-optimized the BOM so that
it only has, say, 8MB of flash instead of 16MB of flash.
But if company is designing a new product from scratch, the delta to
the BOM cost of using 16MB of flash versus 8MB of flash (unless the
company is making gazillions of units) is probably not going to
justify sponsoring an engineer to do open source work on a new file
system feature.
So I'm sure there are cases where people are sensitive to storage size
--- including for example, handset companies who want to be able to
install a newer version of Android on an older handset which doesn't
have enough flash for Kit Kat, or some such.... (and I hear the
peanut gallery burst into laughter at this point --- what? handset
vendors caring about software updates? They *want* people to buy a
new phone since that's the only way they get money out of the deal.
And if they can use the excuse of, "so sorry, the handset doesn't have
enough flash storage space to upgrade to Kit Kat", so much the
better. :-)
:-/
- Ted
next prev parent reply other threads:[~2014-08-31 22:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-30 21:34 Theodore Ts'o
2014-08-30 21:57 ` Dave Taht
2014-08-31 1:38 ` Theodore Ts'o
2014-08-31 7:05 ` David Lang
2014-08-31 16:45 ` Theodore Ts'o
2014-08-31 17:29 ` Dave Taht
2014-08-31 19:37 ` David Lang
2014-08-31 22:03 ` Theodore Ts'o [this message]
2014-08-31 16:58 ` Dave Taht
2014-08-31 7:01 ` David Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140831220307.GI8974@thunk.org \
--to=tytso@mit.edu \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=david@lang.hm \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox