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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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!
:).

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. 🙂 ]

The collective thoughts of the interwebz