Tag Archives: Maemo

100 days of postmarketOS

Post Syndicated from corbet original https://lwn.net/Articles/732792/rss

The postmarketOS distribution looks
back at its first 100 days
. “One of our previously stated goals
is using the mainline Linux kernel on as many mobile devices as
possible. This is not as easy as it might sound, since many Linux-based
smartphones (Android) require binary drivers which depend on very specific
kernel versions. It’s a tremendous task to rewrite these drivers to work
with the current kernel APIs. Nevertheless, some people have been doing
that since long before postmarketOS existed. In the case of the Nokia N900
this has been going on for some number of years and almost all components
are now supported in the mainline kernel. This has allowed us to use the
mainline kernel as the default kernel for the N900, jumping from Maemo’s
2.6.x to mainline 4.12!

Will Nokia Ever Realize Open Source Is Not a Panacea?

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/08/18/open-source-not-panacea.html

I was pretty sure there was something wrong with the whole thing in
fall of 2009, when they first asked me. A Nokia employee contacted me
to ask if I’d be willing to be a director of
the Symbian
Foundation
(or so I thought that’s what they were asking —
read on). I wrote them a thoughtful response explaining my then-current
concerns about
Symbian:

the poor choice of
the Eclipse Public
License
for the eventual code,

the fact that Symbian couldn’t be built in any software freedom
system environment, and

that the Symbian source code that had been released thus far didn’t
actually run on any existing phones.

I nevertheless offered to serve as a director for one year, and I would
resign at that point if the problems that I’d listed weren’t
resolved.

I figured that was quite a laundry list. I also figured that they
probably wouldn’t be interested anyway once they saw my list.
Amusingly, they still were. But then, I realized what was really going
on.

In response to my laundry list, I got back a rather disturbing response
that showed a confusion in my understanding. I wasn’t being invited to
join the board of the Symbian Foundation. They had asked me instead to
serve as a Director of a small USA entity (that
they heralded
as Symbian DevCo
) that would then be permitted one Representative of
the Symbian Foundation itself, which was, in turn, a trade association
controlled by dozens of proprietary software companies.

In fact, this Nokia employee said that they planned to channel all
individual developers toward this Symbian DevCo in the USA,
and that would be the only voice these developers would have in
the direction of Symbian. It would be one tiny voice against dozens of
proprietary software company who controlled the real Symbian Foundation,
a trade association.

Anyone who has worked in the non-profit sector, or even contributed to
any real software freedom project can see what’s deeply wrong
there. However, my response wasn’t to refuse. I wrote back and said
clearly why this was failing completely to create a software freedom
community that could survive vibrantly. I pointed out the way the Linux
community was structured: whereby the Linux Foundation is a trade
association for companies — and, while they do fund Linus’ salary,
they don’t control his or any other activities of developers.
Meanwhile, the individual Linux developers have all the real authority:
from community structure, to licensing, to holding copyrights, to
technical decision-making. I pointed out if they wanted Symbian to
succeed, they should emulate Linux as much as they could. I suggested
Nokia immediately change the whole structure to have developers in
charge of the project, and have a path for Symbian DevCo to ultimately
be the primary organization in charge of the codebase, while Symbian
Foundation could remain the trade association, roughly akin to the Linux
Foundation. I offered to help them do that.

You might guess that I never got a reply to that email. It was thus no
surprise to me in the least what happened to Symbian after that:

In December 2010 (nearly 13 months to the day after my email exchange
described
above), the
Symbian Foundation shut down all its websites
.

In February
2011, Nokia
announced its partnership with Microsoft to prefer Windows 7 on its phones
.

In April
2011, Nokia
announced that Symbian would no longer be available as Free Software
.

In June
2011, Nokia
announced that some other consulting company will take over proprietary
development of Symbian
.

So, within 17 months of Symbian Foundation’s inquiry to ask me to help
run Symbian DevCo, the (Open Source) Symbian project was
canceled entirely, the codebase was now again proprietary (with
a few of the old
codedumps floating around on other sites
),
and the Symbian Foundation
consists only of a single webpage filled with double-speak
.

Of course, even if Nokia had tried its hardest to build an actual
software freedom community, Symbian still had a good chance of
failing, as I
pointed out in March 2010
. But, if Nokia had actually tried to
release control and let developers have some authority, Symbian might
have had a fighting chance as Free Software. As it turned out, Nokia
threw some code over the wall, gave all the power to decide what happens
to a bunch of proprietary software companies, and then hung it all out
to dry. It’s a shining example of how to liberate software in a way
that will guarantee its deprecation in short order.

Of course, we now know that during all this time, Nokia was busy
preparing a backroom deal that would end its
always-burgeoning-but-never-complete affiliation with software freedom
by making a deal with Microsoft to control the future of Nokia. It’s a
foolish decision for software freedom; whether it’s a good business
decision surely isn’t for me to judge. (After all, I haven’t worked in
the for-profit sector for fifteen years for a reason.)

It’s true that I’ve always given a hard time to Maemo (and to MeeGo as
well). Those involved from inside Nokia spent the last six months
telling me that MeeGo is run by completely different people at Nokia,
and Nokia
did recently launch yet another MeeGo based product
. I’ve meanwhile
gotten the impression that Nokia is one of those companies whose
executives are more like wealthy Romans who like to pit their champions
against each other in the arena to see who wins; Nokia’s various
divisions appear to be in constant competition with each other. I
imagine someone running the place has read too much Ayn Rand.

Of course, it now seems that MeeGo hasn’t, in Nokia’s view,
“survived as the fittest”.
I learned today (thanks
to jwildeboer) that,
In
Elop’s words, there is no returning to MeeGo, even if the N9 turns out
to be a hit
. Nokia’s commitment to Maemo/MeeGo, while it did last
at least four years or so, is now gone too, as they begin their march to
Microsoft’s funeral dirge. Yet another FLOSS project Nokia got serious
about, coordinated poorly, and yet ultimately gave up.

Upon considering Nokia’s bad trajectory, it led me to think about how
Open Source companies tend to succeed. I’ve noticed something
interesting, which I’ve confirmed by talking to a lot of employees of
successful Open Source companies. The successful ones — those
that get something useful done for software freedom while also making
some cash (i.e., the true promise of Open Source) — let the
developers run the software projects themselves. Such
companies don’t relegate the developers into a small
non-profit that has to lobby dozens of proprietary software companies to
actually make an impact. They
don’t throw code over the wall — rather, they
fund developers who make their own decisions about what to do in the
software. Ultimately, smart Open Source companies treat software
freedom development like R&D should be treated: fund it and see what
comes out and try to build a business model after something’s already
working. Companies like Nokia, by contrast, constantly put their carts
in front of all the horses and wonder why those horses whinny loudly at
them but don’t write any code.

Open Source slowly became a fad during the DotCom era, and it strangely
remains such. A lot of companies follow fads, particularly when they
can’t figure what else to do. The fad becomes a quick-fix solution. Of
course, for those of us that started as volunteers and enthusiasts in
1991 or earlier, software freedom isn’t some new attraction at
P. T. Barnum’s circus. It’s a community where we belong and collaborate
to improve society. Companies are welcomed to join us for the ride, but
only if they put developers and users in charge.

Meanwhile, my personal postscript to my old conversation with Nokia
arrived in my inbox late in May 2011. I received a extremely vague email
from a lawyer at Nokia. She wanted really badly to figure out how to
quickly dump some software project — and she wouldn’t tell me what
it was — into the Software Freedom Conservancy. Of course, I’m
sure this lawyer knows nothing about the history of the Symbian project
wooing me for directorship of Symbian DevCo and all the other history of
why “throwing code over the wall” into a non-profit is
rarely known to work, particularly for Nokia. I sent her a response
explaining all the problems with her request, and, true to Nokia’s
style, she didn’t even bother to respond to me thanking me for my
time.

I can’t wait to see what project Nokia dumps over the wall next, and
then, in another 17 months (or if they really want to lead us
on, four years), decides to proprietarize or abandon it because, they’ll
say, this open-sourcing thing just doesn’t work. Yet, so many
companies make money with it. The short answer is: Nokia,
you keep doing it wrong!

Update (2011-08-24):
Boudewijn
Rempt argued another side of this question
.
He says
the Calligra suite is a counterexample of Nokia getting a FLOSS project
right
. I don’t know enough about Calligra to agree or disagree.

Musings on Software Freedom for Mobile Devices

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2010/03/04/mobile.html

I started using GNU/Linux and Free Software in 1992. In those days,
while everything I needed for a working computer was generally available
in software freedom, there were many components and applications that
simply did not exist. For highly technical users who did not need many
peripherals, the Free Software community had reached a state of complete
software freedom. Yet, in 1992, everyone agreed there was still much work
to be done. Even today, we still strive for a desktop and server
operating system, with all relevant applications, that grants complete
software freedom.

Looked at broadly, mobile telephone systems are not all that different
from 1992-era GNU/Linux systems. The basics are currently available as
Free, Libre, and Open Source Software (FLOSS). If you need only the bare
minimum of functionality, you can, by picking the right phone hardware,
run an almost completely FLOSS operating system and application set. Yet,
we have so far to go. This post discusses the current penetration of
FLOSS in mobile devices and offers a path forward for free software
advocates.

A Brief History

The mobile telephone market has never functioned like the traditional
computer market. Historically, the mobile user made arrangements with some
network carrier through a long-term contract. That carrier
“gave” the user a phone or discounted it as a loss-leader. Under
that system, few people take their phone hardware choice all that
seriously. Perhaps users pay a bit more for a slightly better phone, but
generally they nearly always pick among the limited choices provided by
the given carrier.

Meanwhile, Research in Motion was the first to provide
corporate-slave-oriented email-enabled devices. Indeed, with the very
recent focus on consumer-oriented devices like the iPhone, most users
forget that Apple is by far not the preferred fruit for the smart phone
user. Today, most people using a “smart phone” are using one
given to them by their employer to chain them to their office email 24/7.

Apple, excellent at manipulating users into paying more for a product
merely because it is shiny, also convinced everyone that now a phone
should be paid for separately, and contracts should go even longer. The
“race to mediocrity” of the phone market has ended. Phones
need real features to stand out. Phones, in fact, aren’t phones
anymore. They are small mobile computers that can also make phone calls.

If these small computers had been introduced in 1992, I suppose I’d be
left writing the Mobile GNU Manifesto, calling for developers
to start from scratch writing operating systems for these new computers,
so that all users could have software freedom. Fortunately, we have
instead been given a head start. Unlike in 1992, not every company in the
market today is completely against releasing Free Software. Specifically,
two companies have seen some value in releasing (some parts of) phone
operating systems as Free Software: Nokia and Google. However, the two
companies have done this for radically different reasons.

The Current State of Mobile Software Freedom
For its part, Nokia likely benefited greatly from the traditional
carrier system. Most of their phones were provided relatively cheaply with
contracts. Their interest in software freedom was limited and perhaps even
non-existent. Nokia sold new hardware every time a phone contract was
renewed, and the carrier paid the difference between the loss-leader price
and Nokia’s wholesale cost. The software on the devices was simple and
mostly internally developed. What incentive did Nokia have to release
software in software freedom? (Nokia realized too late this was the wrong
position, but more on that later.)

In parallel, Nokia had chased another market that I’ve never fully
understood: the tablet PC. Not big enough to be a real computer, but too
large to be a phone, these devices have been an idea looking for a user
base. Regardless of my personal views on these systems, though, GNU/Linux
remains the ideal system for these devices, and Nokia saw that. Nokia
built the Debian-ish Maemo system as a
tablet system, with no phone. However, I can count on one hand all the
people I’ve met who bothered with these devices; I just don’t think a
phone-less small computer is going to ever become the rage, even if Apple
dumps billions into marketing the iPad. (Anyone remember the Newton?)

I cannot explain, nor do I even understand, why Nokia took so long to
use Maemo as a platform for a tablet-like telephone. But, a few months
ago, they finally released
one. This N900 is among only a
few available phones that make any strides toward a fully free software
phone platform. Yet,
the list of
proprietary components required for operation
remains quite long. The
common joke is that you can’t even charge the battery on your N900 without
proprietary software.

While there are surely people inside Nokia who want more software
freedom on their devices, Nokia is fundamentally a hardware company
experimenting with software freedom in hopes that it will bolster hardware
sales. Convincing Nokia to shorten that proprietary list will prove
difficult, and the community based effort to replace that long list with
FLOSS (called Mer) faces many
challenges. (These challenges will likely increase with the recent Maemo
merger with Moblin to form MeeGo).

Fortunately, hardware companies are not the only entity interested in
phone operating systems. Google, ever-focused on routing human eyes to its
controlled advertising, realizes that even more eyes will be on mobile
computing platforms in the future. With this goal in mind, Google released
the Android/Linux system, now available on a variety of phones in varying
degrees of software freedom.

Google’s motives are completely different than Nokia’s. Technically,
Google has no hardware to sell. They do have a set of proprietary
applications that yield the “Google online experience” to
deliver Google’s advertising. From Google’s point of view, an
easy-to-adopt, licensing-unencumbered platform will broaden their
advertising market.

Thus, Android/Linux is a nearly fully non-copylefted phone operating
system platform where Linux is the only GPL licensed component essential
to Android’s operation. Ideally, Google wants to see Android adopted
broadly in both Free Software and mixed Free/proprietary deployments.
Google’s goals do not match that of the software freedom community, so in
some cases, a given Android/Linux device will give the user more software
freedom than the N900, but in many cases it will give much less.

The HTC
Dream
is the only Android/Linux device I know of where a careful
examination of the necessary proprietary components have been
analyzed. Obviously, the “Google experience” applications are
proprietary. There also
are about
20 hardware interface libraries
that do not have source code available
in a public repository. However, when lined up against the N900 with
Maemo, Android on the HTC Dream can be used as an operational mobile
telephone and 3G Internet device using only three proprietary components:
a proprietary GSM firmware, proprietary Wifi firmware, and two audio
interface libraries. Further proprietary components are needed if you
want a working accelerometer, camera, and video codecs as their hardware
interface libraries are all proprietary.

Based on this analysis, it appears that the HTC Dream currently gives
the most software freedom among Android/Linux deployments. It is unlikely
that Google wants anything besides their applications to be proprietary.
While Google has been unresponsive when asked why these hardware interface
libraries are proprietary, it is likely that HTC, the hardware maker with
whom Google contracted, insisted that these components remain proprietary,
and perhaps
fear patent
suits like the one filed this week
are to blame here. Meanwhile,
while no detailed analysis of
the Nexus One is yet available,
it’s likely similar to the HTC Dream.

Other Android/Linux devices are now available, such as those from
Motorola and Samsung. There appears to have been no detailed analysis done
yet on the relative proprietary/freeness ratio of these Android
deployments. One can surmise that since these devices are from
traditionally proprietary hardware makers, it is unlikely that these
platforms are freer than those available from Google, whose maximal
interest in a freely available operating system is clear and in contrast
to the traditional desires of hardware makers.

Whether the software is from a hardware-maker desperately trying a new
hardware sales strategy, or an advertising salesman who wants some
influence over an operating system choice to improve ad delivery, the
software freedom community cannot assume that the stewards of these
codebases have the interests of the user community at heart. Indeed, the
interests between these disparate groups will only occasionally be
aligned. Community-oriented forks, as has begun in the Maemo community
with Mer, must also begin in the Android/Linux space too. We are slowly
trying with
the Replicant
project
, founded by myself and my colleague Aaron Williamson.

A healthy community-oriented phone operating system project will
ultimately be an essential component to software freedom on these devices.
For example, consider the fate of the Mer project now that Nokia has
announced the merger of Maemo with Moblin. Mer does seek to cherry-pick
from various small device systems, but its focus was to create a freer
Maemo that worked on more devices. Mer now must choose between following
the Maemo in the merge with Moblin, or becoming a true fork. Ideally, the
right outcome for software freedom is a community-led effort, but there
may not be enough community interest, time and commitment to shepherd a
fork while Intel and Nokia push forward on a corporate-controlled
codebase. Further, Moblin will likely push the MeeGo project toward more
of a tablet-PC operating system than a smart phone.

A community-oriented Android/Linux fork has more hope. Google has
little to lose by encouraging and even assisting with such forks; such
effort would actually be wholly consistent with Google’s goals for wider
adoption of platforms that allow deployment of Google’s proprietary
applications. I expect that operating system
software-freedom-motivated efforts will be met with more support from
Google than from Nokia and/or Intel.

However, any operating system, even a mobile device one, needs many
applications to be useful. Google experience applications for
Android/Linux are merely the beginning of the plethora of proprietary
applications that will ultimately be available for MeeGo and Android/Linux
platforms. For FLOSS developers who don’t have a talent for low-level
device libraries and operating system software, these applications
represent a straightforward contribution towards mobile software
freedom. (Obviously, though, if one does have talent for low-level
programming, replacing the proprietary .so’s on Android/Linux would be the
optimal contribution.)

Indeed, on this point, we can take a page from Free Software history.
From the early 1990s onward, fully free GNU/Linux systems succeeded as
viable desktop and server systems because disparate groups of developers
focused simultaneously on both operating systems and application software.
We need that simultaneous diversity of improvement to actually compete
with the fully proprietary alternatives, and to ensure that the
“mostly FLOSS” systems of today are not the “barely
FLOSS” systems of tomorrow.

Careful readers have likely noticed that I have ignored Nokia’s other
release, the Symbian> codebase. Every time I write or speak about the
issues of software freedom in mobile devices, I’m chastised for leaving it
out of the story. My answer is always simple: when a FLOSS version of
Symbian can be compiled from source code, using a FLOSS compiler or SDK,
and that binary can be installed onto an actual working mobile phone
device, then (and only then) will I believe that the Symbian source
release has value beyond historical interest. We have to get honest as a
community about the future of Symbian: it’s a ten-year-old proprietary
codebase designed for devices of that era that doesn’t bootstrap with any
compilers our community uses regularly. Unless there’s a radical change
to these facts, the code belongs in a museum, not running on a phone.

Also, lest my own community of hard-core FLOSS advocates flame me, I
must also mention
the Neo FreeRunner
device
and the
OpenMoko project.
This was a noble experiment: a freely specified hardware platform running
100% FLOSS. I used an OpenMoko FreeRunner myself, hoping that it would be
the mobile phone our community could rally around. I do think the device
and its (various) software stack(s) have a future as an experimental,
hobbyist device. But, just as GNU/Linux needed to focus on x86 hardware
to succeed, so must software freedom efforts in mobile systems focus on
mass-market, widely used, and widely available hardware.

Jailbreaking and the Self-Installed System

When some of us at my day-job office decided to move as close to a
software freedom phone platform as we could, we picked Android/Linux and
the HTC Dream. However, we carefully considered the idea of permission to
run one’s own software on the device. In the desktop and server system
market, this is not a concern, but on mobile systems, it is a central
question.

The holdover of those carrier-controlled agreements for phone
acquisition is the demand that devices be locked down. Devices are locked
down first to a single carrier’s network, so that devices cannot (legally)
be resold as phones ready for any network. Second, carriers believe that
they must fear the FCC if device operating systems can be reinstalled.

On the first point, Google is our best ally in this
regard. The
HTC Dream developer models, called the Android Dev Phone 1 (aka ADP1)
,
while somewhat more expensive than T-Mobile branded G1s, permit the user
to install any operating system on the phone, and the purchase agreement
extract no promises from the purchaser regarding what software runs on the
device. Google has no interest in locking you to a single carrier, but
only to a single Google experience application vendor. Offering a user
“carrier freedom of choice”, while tying those users tighter
to Google applications, is probably a central part of their marketing
plans.

The second point — fear of an FCC crack down when mobile users
have software freedom — is beyond the scope of this
article. However, what Atheros has done with their Wifi devices shows that
software freedom and FCC compliance can co-exist. Furthermore, the
central piece of FCC’s concern — the GSM chipset and firmware
— runs on a separate processor in modern mobile devices. This is a
software freedom battle for another day, but it shows that the FCC can be
pacified in the meantime by keeping the GSM device a black box to the Free
Software running on the primary processor of the device.
Conclusion

Seeking software freedom on mobile devices will remain a complicated
endeavor for some time. Our community should utilize the FLOSS releases
from companies, but should not forget that, until viable community forks
exist, software freedom on these devices exists at the whim of these
companies. A traditional “get some volunteers together and write
some code” approach can achieve great advancement toward
community-oriented FLOSS systems on mobile devices. Developers could
initially focus on applications for the existing “mostly
FLOSS” platforms of MeeGo and Android/Linux. The challenging and
more urgent work is to replace lower-level proprietary components on these
systems with FLOSS alternatives, but admittedly needs special programming
skills that aren’t easy to find.

(This blog post first appeared
as an
article
in
the March
2010 issue
of the Canadian online
journal, The Open Source Business Resource
.)

Android/Linux’s Future and Advancement of Mobile Software Freedom

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/11/04/android-vs-gnu.html

Harald Welte knows more about development of embedded systems than I
ever will. So, I generally defer completely to his views about software
freedom development for embedded systems. However, as you can tell by
that opening, I am setting myself up to disagree a little bit with him
just this once on the topic. 🙂

But first, let me point out where we agree: I think
his recent
blog post about what Android/Linux is not
should be
read by everyone interested in software freedom for mobile devices.
(Harald’s post also refers to a presentation by Matt Porter. I agree
with Harald that talk is worth looking at closely.) The primary point
Matt and Harald both make is one that Stallman has actually made for
years: Linux is an operating system kernel, not a whole system for a
user. That’s why I started saying Android/Linux to refer to this new
phone platform. It’s just the kernel, Linux, with a bunch of Java stuff
on top. As Matt points out, it doesn’t even use a common Linux-oriented
C Library, such as uClibc or the GNU C Library; it used a BSD-derived
libc called Bionic.

Indeed, my colleague Aaron
Williamson
discovered this fact quickly five months ago when he
started trying to make a fully FaiF Android/Linux platform on the HTC
Dream. I was amazed and aghast when he told me about adb
and how there is no real shell on the device by default. It’s not a
GNU/Linux system, and that becomes quickly and painfully obvious to
anyone who looks at developing for the platform. On this much, I agree
with Harald entirely: this is a foreign system that will be very strange
to most GNU/Linux hackers.

Once I learned this fact, I immediately pondered: Why did Google
build Android in this way? Why not make it GNU/Linux like the
OpenMoko? I concluded that there are probably a few reasons:

First, while Linux is easy to cram into a small space, particularly
with BusyBox and uClibc, if you want things both really small and have a
nice GUI API, it’s a bit tougher to get right. There is a reason the
OpenMoko software stack was tough to get right and still has issues.
Maemo, too, has had great struggles in its history that may not be fully
overcome.

Second, Google probably badly wanted Java as the native application
language, due to its ubiquity. I dislike Java more than the average,
but there’s no denying that nearly all undergraduate Computer Science
students of the last ten years did most of their work in Java. Java is
more foreign to most GNU/Linux developers than Python, Perl, Ruby and
the like, but to the average programmer in the world, Java is the lingua
franca.

Third, and probably most troubling, Google wanted to have as little
GPL’d and LGPL’d stuff in the stack as possible. Their goal isn’t
software freedom; it is to convince phone carriers and manufacturers to
make Google’s proprietary applications the default mobile application
set. The operating system is pure commodity to sell the proprietary
applications. So, from Google’s perspective, the more permissively
licensed stuff in the Android/Linux base system, the better.

Once you ponder all this, the obvious next question is: Should we
bother with this platform, or focus on GNU/Linux instead? In fact,
this very question comes up almost weekly over on
the Replicant
project
‘s IRC channel (#replicant on freenode). Harald’s arguments
for GNU/Linux are good ones, and as I tell my fellow Replicant hackers,
I don’t begrudge anyone who wants to focus on that line of development.
However, I think this is the place where I disagree with Harald: I think
the freed Android code does have an important future in the advancement
of software freedom.

We have to consider carefully here, as Android/Linux puts us in a place
software freedom developers have never been in before. Namely, we have
an operating system whose primary deployments are proprietary, but the
code is mostly available to us as Free Software, too. Furthermore, this
operating system runs on platforms that we don’t have a fully working
port of GNU/Linux yet. I think these factors make the decision to port
GNU/Linux or fork the mostly FaiF release into nearly a coin-flip
decision.

However, when deciding where to focus development effort, I think the
slight edge goes to Android/Linux. It’s not a huge favorite —
maybe 54% (i.e., for my fellow poker players, all-in-prelfop in HE,
Android would be the pair, not the unsuited overcards :). Android/Linux
deserves the edge primarily because Google and their redistributors
(carriers and phone makers) will put a lot of marketing and work into
gaining public acceptance of “Android” as an iPhone
replacement. We can take advantage of this, and say: What we have is
Android too, but you can modify and improve it and run more applications
not available in the Android Market! Oh, and if you really really do
want that proprietary application from the Market, those will run on our
system, too (but we urge you not to use proprietary software). It’s
simply going to be easier to get people to jailbreak their phones and
install a FaiF firmware if it looks almost identical to the one they
have, but with a few more features they don’t have already.

So, by all means, if porting GNU/Linux and/or BusyBox/Linux to strange
new worlds is your hobby, then by all means make it run on the HTC Dream
too. In fact, as a pure user I’ll probably prefer it
once it’s ready for prime time. However, I think the strategic move to
get more software freedom in the world is to invest development effort
into a completely freedom-respecting fork of Android/Linux. (And, yet
another shameless plug, we need driver hacker help
on Replicant!
:).

Software Freedom on Mobile Devices

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2009/10/26/symbian.html

I
agree pretty completely with Harald Welte’s comments regarding
Symbian
. I encourage everyone to take a look at his comments.

We are in a very precarious time with regard to the freedom of mobile
devices. We currently have no truly Free Software operating system that
does the job, and there are multiple companies trying to get our
attention with code releases that have some Free Software in them. None
of these companies have pro-software-freedom motives about these issues
(obviously, they are for-profit companies, who focus solely on their own
profits). So, we have to carefully analyze what these proprietary
software companies are up to, why they are releasing some code, and
determine if we’ll be successful forking these platforms to build a
fully software freedom phone platform.

We thus must take care not to burn our developer time on likely
hopeless codebases. I think Harald’s analysis convinces me that Symbian
is such a hopeless codebase. They haven’t released software we can
build for any known phone for sale, and we don’t have a compiler that
can build the stuff. It’s also under a license that isn’t a bad one by
any means, but it is however not a widely used license for operating
system software. Symbian’s release, thus, is purely of academic
interest to historians who might want to study what phone software
looked like at the turn of the millennium before the advent of
Linux-based phones.

Currently, given the demise of mass-market OpenMoko production, our
best hope, in my opinion, is the HTC Dream running a modified version of
Android/Linux. We don’t have 100% Free Software even for that
yet, but
we are
actively working on it
, and the list of necessary-to-work
proprietary components is down to two libraries. Plus, the Maemo
software (and the new device it runs on, not even released yet) is the
only other option, and it has quite
an extensive
list of proprietary components
. As far as we can tell currently,
the device may even be unusable without a large amount of proprietary
software.

Even so, Android/Linux isn’t a Dream (notwithstanding the name of the
most widely used hardware platform). It’s developed generally by a
closed community, who throw software over the wall when they see fit,
and we’ll have to maintain forks to really make a fully Free Software
version. But this is probably going to be true of any Free Software
phone platform that a company releases anyway.

I’ll keep watching and expect my assessment will change if facts
change. However, unless I see that giant laundry list of proprietary
components in Maemo decreasing quickly, I think I’ll stick with the least
of all these evils, Android/Linux on the HTC Dream. It’s by far the
closest to having a fully free software platform. Since the only way to
get us to freedom is to replace proprietary components one-by-one,
picking the closest is just the best path to freedom. At the very
least, we should eliminate platforms for which the code can’t even be
compiled!

[ PC was kind enough to make
a Belorussian
translation
of this blog post. I can’t speak to its accuracy, of
course, since I don’t know the language. 🙂 ]

Conferences

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/lpc-bluez-maemo-2009.html

Last week I’ve been at the Linux Plumbers Conference in
Portland. Like last year it kicked ass and proved again being one of the most
relevant Linux developer conferences (if not the most relevant one). I
ran the Audio MC at the conference which was very well attended. The slides
for our four talks in the
track are available online
. (My own slides are probably a bit too terse
for most readers, the interesting stuff was in the talking, not the
reading…) Personally, for me the most interesting part was to see to which
degree Nokia actually adopted PulseAudio
in the N900. While I was aware that Nokia was using it, I wasn’t aware that
their use is as comprehensive as it turned out it is. And the industry
support from other companies is really impressive too. After the main track we
had a BoF session, which notes I’ll post a bit later. Many thanks to Paul,
Jyri, Pierre for their great talks. Unfortunately, Palm, the only manufacturer
who is actually already shipping a phone with PulseAudio didn’t send anyone to
the conference who wanted to talk about that. Let’s hope they’ll eventually
learn that just throwing code over the wall is not how Open Source works.
Maybe they’ll send someone to next year’s LPC in Boston, where I hope to be
able to do the Audio MC again.

Right now I am at the BlueZ Summit in Stuttgart. Among other things we have
been discussing how to improve Bluetooth Audio support in PulseAudio. I guess
one could say thet the Bluetooth support in PulseAudio is already one of its
highlights, in fact working better then the support on other OSes (yay, that’s
an area where Linux Audio really shines!). So up next is better support for
allowing PA to receive A2DP audio, i.e. making PA act as if it was a Headset or
your hifi. Use case: send music from from your mobile to your desktop’s hifi
speakers. (Actually this is already support in current BlueZ/PA versions, but
not easily accessible). Also Bluetooth headsets tend to support AC3 or MP3
decoding natively these days so we should support that in PA too. Codec
handling has been on the TODO list for PA for quite some time, for the SPDIF or
HDMI cases, and Bluetooth Audio is another reason why we really should have
that.

Next week I’ll be at the Maemo Summit in Amsterdam.
Nokia kindly invited me. Unfortunately I was a bit too late to get a proper
talk accepted. That said, I am sure if enough folks are interested we could do
a little ad-hoc BoF and find some place at the venue for it. If you have any
questions regarding PA just talk to me. The N900 uses PulseAudio for all things
audio so I am quite sure we’ll have a lot to talk about.

See you in Amsterdam!

One last thing: Check out Colin’s
work to improve integration of PulseAudio and KDE
!

Conferences

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/lpc-bluez-maemo-2009.html

Last week I’ve been at the Linux Plumbers Conference in
Portland. Like last year it kicked ass and proved again being one of the most
relevant Linux developer conferences (if not the most relevant one). I
ran the Audio MC at the conference which was very well attended. The slides
for our four talks in the
track are available online
. (My own slides are probably a bit too terse
for most readers, the interesting stuff was in the talking, not the
reading…) Personally, for me the most interesting part was to see to which
degree Nokia actually adopted PulseAudio
in the N900. While I was aware that Nokia was using it, I wasn’t aware that
their use is as comprehensive as it turned out it is. And the industry
support from other companies is really impressive too. After the main track we
had a BoF session, which notes I’ll post a bit later. Many thanks to Paul,
Jyri, Pierre for their great talks. Unfortunately, Palm, the only manufacturer
who is actually already shipping a phone with PulseAudio didn’t send anyone to
the conference who wanted to talk about that. Let’s hope they’ll eventually
learn that just throwing code over the wall is not how Open Source works.
Maybe they’ll send someone to next year’s LPC in Boston, where I hope to be
able to do the Audio MC again.

Right now I am at the BlueZ Summit in Stuttgart. Among other things we have
been discussing how to improve Bluetooth Audio support in PulseAudio. I guess
one could say thet the Bluetooth support in PulseAudio is already one of its
highlights, in fact working better then the support on other OSes (yay, that’s
an area where Linux Audio really shines!). So up next is better support for
allowing PA to receive A2DP audio, i.e. making PA act as if it was a Headset or
your hifi. Use case: send music from from your mobile to your desktop’s hifi
speakers. (Actually this is already support in current BlueZ/PA versions, but
not easily accessible). Also Bluetooth headsets tend to support AC3 or MP3
decoding natively these days so we should support that in PA too. Codec
handling has been on the TODO list for PA for quite some time, for the SPDIF or
HDMI cases, and Bluetooth Audio is another reason why we really should have
that.

Next week I’ll be at the Maemo Summit in Amsterdam.
Nokia kindly invited me. Unfortunately I was a bit too late to get a proper
talk accepted. That said, I am sure if enough folks are interested we could do
a little ad-hoc BoF and find some place at the venue for it. If you have any
questions regarding PA just talk to me. The N900 uses PulseAudio for all things
audio so I am quite sure we’ll have a lot to talk about.

See you in Amsterdam!

One last thing: Check out Colin’s
work to improve integration of PulseAudio and KDE
!

Avahi on your N800

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-n800.html

I’d love to see proper Avahi support in the Nokia N800 (just think of proper
file manager integration of announced WebDAV shares!), but until now Nokia
doesn’t ship Avahi in Maemo. However, there’s now a simple way to install at
least basic Avahi support on the N800. The INdT includes Avahi in their Canola builds. Hence: just install
Canola and your N800 will register itself via mDNS on your network.

In related news: I am happy to see that Avahi has apparently been included in the just announced GNOME Embedded Platform.

Avahi on your N800

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/avahi-n800.html

I’d love to see proper Avahi support in the Nokia N800 (just think of proper
file manager integration of announced WebDAV shares!), but until now Nokia
doesn’t ship Avahi in Maemo. However, there’s now a simple way to install at
least basic Avahi support on the N800. The INdT includes Avahi in their Canola builds. Hence: just install
Canola and your N800 will register itself via mDNS on your network.

In related news: I am happy to see that Avahi has apparently been included in the just announced GNOME Embedded Platform.