---------- Forwarded message ----------
From: Peter Pearse <Peter.Pearse(a)arm.com>
Date: Mon, Nov 8, 2010 at 9:50 AM
Subject: FW: Why the software matters
To: "Peter Pearse (peter.pearse(a)linaro.org)" <peter.pearse(a)linaro.org>
> -----Original Message-----
> From: Dave Butcher
> Sent: 05 November 2010 21:24
> To: pdsw-systems
> Subject: Why the software matters
> I think there is something pretty relevant to us in this
> answer from Steve Jobs during the Apple Earnings call:
> [Q: Market share question.]
> You’re looking at it wrong. You’re looking at it as a
> hardware person in a fragmented world. You’re looking at it
> as a hardware manufacturer that doesn’t really know much
> about software, who doesn’t think about an integrated product
> but assumes the software will somehow take care of itself.
> And you’re sitting around saying, well, how can we make this
> cheaper? Well, we can put a smaller screen on it, and a
> slower processor, and less memory, and you assume that the
> software will somehow just come alive on this product that
> you’re dreaming up, but it won’t. Because these app
> developers have taken advantage of the products that came
> before, with faster processors, with larger screens, with
> more capabilities that they can take advantage of to make
> better apps for customers. And they’re not… it’s a hard one,
> because it throws you right back into the beginning of that
> chicken-and-egg problem again, to change all the assumptions
> on these developers. Most of them will not follow you. Most
> of them will say, “I’m sorry, but I’m not going to write down
> a watered-down version of my app just because you’ve got this
> phone that you can sell for $50 less, and you’re begging me
> to write software for it.”
> I found this via these two blogs, but I wanted to
> particularly highlight one comment, which I think will
> probably ring true with a few people, even if it doesn't
> apply to Apple products specifically for them.
> ... but it even got developers interested in writing native
> iPhone apps before the iPhone even went on sale,
> because developers wanted to write the sort of inspiring
> apps Apple itself had written (and shown off) for
> the original iPhone.
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose, or
store or copy the information in any medium. Thank you.
Due to an ongoing migration in the data centre any image builds that are
done from now until sometime tomorrow will not appear on
snapshots.linaro.org until tomorrow.
Reorganisation as part of the migration means that firewalls need to be
updated for the rsyncs to work, and that won't be done until sometime
tomorrow US time.
Everything should return to normal within 24 hours, and I will update
you if that changes.
-----BEGIN PGP SIGNED MESSAGE-----
With the help of Paul Larson we now have a Launch Control PPA.
Currently it does not have the most interesting package (dashboard) but
we're slowly getting there.
The ppa is at:
I have created a daily build of the first package: python-linaro-json.
This package contains the JSON utilities that I've developed for launch
control. As soon as the dust settles out and I'm comfortable with
packaging I'll release and upload a non-daily build. (Q: what is the
best way do to that with launchpad?)
Next in the queue for that PPA is a python package for working with
dashboard bundle files (extracted from the current dashboard code base).
I hope that those two packages can make it to natty eventually and help
the nice folks in Ubuntu QA to produce test results not as unstructured
text files but as bundle files. Hopefully this will allow them to store
those files as they currently do and later on decide to either push them
to a dashboard instance of their choice or convert them to launchpad
subunit format (yes! it's _should_ be possible to convert all data to
subunit) once that is ready for production.
Feedback welcome :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
On Thu, Nov 4, 2010 at 4:58 PM, Amit Arora <amit.arora(a)linaro.org> wrote:
> Hello John,
> We, in Power Management work group, are developing a new tool
> (PowerDebug) which will show users/developers various Power Management
> related information exported from the kernel. This includes regulator
> info., sensor info., clock tree etc. For kernel to display this
> information to userspace (via sysfs/debugfs), we need to enable a few
> config options. These are:
> I believe first couple of these are already enabled by default in
> Linaro kernel. Do you mind enabling others too, so that PowerDebug
> works with the default kernel installed ?
John, are you using the 'enforce check' system from ubuntu kernels
that make sure that certain config options always have expected
It might be worth adding these to our enforce system since we want all
our kernel flavours to enable these options.
(+linaro-dev(a)lists.linaro.org. Apologies for not copying the list
earlier. I thought I had added to CC)
On Wed, Nov 3, 2010 at 9:59 PM, Anand Gadiyar <gadiyar(a)ti.com> wrote:
> This is v2 of a pull-request I sent a few minutes ago for getting OMAP4
> Pandaboard support on linux-linaro-2.6.35. Change from v1 is a different
> branch being used, and the commits were cherry picked with the -x option.
> MMC support is still work in progress. I'll try and get that working ASAP,
> so we can have a slightly more useful kernel.
> - Anand
> The following changes since commit 5c1ae6d7d1035a335cc66b1636ed7bdff7fd0e7b:
> Felipe Contreras (1):
> video: omap: vram: remove from normal memory
> are available in the git repository at:
> git://dev.omapzoom.org/pub/scm/anand/linux-omap-usb.git for-linaro-v2
> David Anders (1):
> omap4: Panda: Add DEBUG_LL support
> Santosh Shilimkar (3):
> omap4: Update id.c and cpu.h for es2.0
> omap4: l2x0: Fix init parameter for es2.0
> omap4: Fix bootup crash observed with higher CPU clocks
> arch/arm/mach-omap2/id.c | 38
> arch/arm/mach-omap2/omap4-common.c | 10 +++++--
> arch/arm/plat-omap/dmtimer.c | 2 +-
> arch/arm/plat-omap/include/plat/cpu.h | 5 +++-
> arch/arm/plat-omap/include/plat/uncompress.h | 1 +
> 5 files changed, 44 insertions(+), 12 deletions(-)
The "weekly" report for the Linaro Infrastructure team covers the past two weeks due to UDS last week, and the report may be found at:-
Status report: https://wiki.linaro.org/Platform/Infrastructure/Status/2010-11-04
The Infrastructure related blueprints, of which currently there are 4 active ones (4 from the last report), are showing that there are 11 work items in progress (11 last report), and 12 work items to undertake (12 last report).
arm-m-validation-dashboard; 0 work items completed since last report; 2 in progress; 8 to do
arm-m-image-building-console; 0 work items completed since last report; 7 in progress; 3 to do
arm-m-automated-testing-framework; no change in status from last report; 1 in progress; 0 to do
arm-m-testsuites-and-profilers; no change in status from last report; 1 in progress; 1 to do
In arm-m-image-building-console, 6 items are awaiting review before they can be completed.
UDS preparations occupied the time leading up to UDS for all team members. Subsequent to UDS, the focus has been on preparing Blueprints for the next cycle.
Specifics accomplished this week include:-
* Preparing for, and holding the Infrastructure Stakeholder meeting
* Drafting Blueprints for the next cycle
* Got QEMU working with current images
Please let me know if you have any comments or questions.
As discussed at UDS/LDS, there is a very good chance that the next
Linaro release will be based on kernel version 2.6.38.
What that means is that we still have 4-6 weeks to get some code into
various maintainer trees before the 2.6.38 merge window opens in early
January. If you are working on consolidation of some feature across
SoCs, it might be nice to get this code in before then so that we
don't have to backport patches for the release.