Some time ago, I wrote
how to get GNU on a
smartphone. This is going to be a long discussion
on why and how we should work on more operating systems for more
devices.
On Android
So, why should we bother if we already have Android, some might ask? If
it's just because of some binary blobs, one could just use Replicant,
right?
Well, one of the problems is that Android development is done in hiding,
and pushed downstream when a new version is launched. There is no
community behind that anyone can join. Replicant ends up either
following it or staying behind. It could do a fork and have its own
innovations. And I am all for it. But the lack of manpower for
supporting devices and keeping up with the latest versions and security
fixes already takes most of the time for the one or two developers
involved.
Also, Android has a huge modularity problem, that I will discuss
further below. But it's hard to replace many components in the system,
unless you replace them all. And that also causes the problem that
applications can hardly share extra components.
I would rather see
Debian running on my devices
and supporting good environments and frameworks for all kinds of
devices, like phones, tablets, TVs, cars, etc. It's developed by a
community I can join, it allows a diverse set of frameworks and
environments, and it's much easier to replace single components on such
a system.
On Copyleft Hardware
I get it. Hardware is not free or libre. Its design is. I love the
concept of copyleft hardware, where one applies the copyleft principles
to a hardware design. Also, there is the concept of Hardware that
Respects Your Freedom, that is, one that allows you to use it with only
free software.
Note that RYF hardware is not necessarily copyleft hardware. In fact,
most of the time, the original vendor has not helped at all, and it
required reverse engineering efforts by other people to be able to run
free software on those systems.
My point here is that we should not prevent people from running free
software on hardware that does not RYF or that is not copyleft. We
should continue the efforts of reverse engineering and of pushing
hardware vendors to not only ship free software for their hardware, but
also release their design under free licenses. But in the meantime, we
need to make free software flourish in the plethora of devices on the
hands of so many people around the world.
On Diversity
I won't go into details on this post about two things. One topic I love
is retrocomputing and how Linux supported so many devices, and how many
free or quasi-free operating systems ran on so many of them in the past.
I could mention ucLinux, Familiar, PDAs, Palmtops, Motorolas, etc. But I
will leave it to another time and go from Openmoko and Maemo forward.
The other topic is application scalability. Even Debian with so many
software available does not ship all free software there is available.
And it doesn't support all third-party services out there. How can we
solve that? It has to do with platforms, protocols, open protocols, etc.
I will not go into that today.
Because I believe that either way, it's healthy for our society to have
diversity. I believe we should have other operating systems available
for our devices. Even if application developers will not develop for all
of them. That is already the case today. There are other ways to fix
that, when that needs fixing. Sometimes, it's sufficient that you can
have your own operating system on your device, that you can customize
it, enhance it and share it with friends.
And also, that would allow for innovation. It would make possible that
some other operating system would have enough market share on some other
niche. Other than Android and iOS, for example. But that requires that
we can support that operating system on different devices.
And that is the scalability that I want to talk about. How to support
more devices with less effort.
Options
But before I go into that, let me write more about the alternatives we
have out there. And some of the history around it.
Openmoko
Openmoko developed a set of devices that had some free design. And it
has some free operating systems running on top. The community developed
a lot of their own as well. Debian could (still can) run on it. There
is
SHR, which uses
FSO, a mobile middleware based on D-Bus.
It even spawned other devices to be developed, like
GTA04, a
successor board, that can be shipped inside a
Neo Freerunner
case.
Maemo, Moblin, Meego and Tizen
I remember the announcement of
Nokia N770. During
FISL in 2005, I even criticized a lot, because it
shipped with proprietary drivers. And applications. But it was the first
time we heard of
Maemo. It was based on Debian and
GNOME. The GNOME Mobile initiative was born from
that, I believe, but died later on.
But with the launch of
N900, and later events, like the merge of
Moblin with Maemo, to create
Meego, we all had an
operating system that was based on community developed components, that
had some community participation, and was much more like the systems we
were used to. You could run
gcc on N900. You
could install
Das U-Boot and have
other operating systems running there.
But Nokia has gone a different path. Intel has started
Tizen with Samsung. There is so much legacy there,
that could still be developed upon. I am just sad that Jolla decided to
put proprietary layers on top of that, to create
SailfishOS.
But we still have
Mer,
Nemo. But it looks like
Cordia is gone. At least,
(http://cordiahd.org) seems to have been registered by a domain seller.
Not to forget,
Neo900, a project to upgrade the
board, in the same vein as GTA04.
FirefoxOS and Ubuntu
What can I say about
FirefoxOS and
Ubuntu Phone? In summary, I think we need
more than Web, and Canonical has a history of not being too community
oriented as we'd like.
I won't go too much here in what I think about the Web as a platform.
But I think we need a system that has more options for platforms. I
haven't participated in projects directed by Mozilla either, so I can't
say much about that.
Ubuntu Phone should be a system more like what we are used to. But
Canonical is going to set the directions to the project, it's not a
community project.
Nonetheless, I think they add to the diversity, and users should be able
to try them, or their free parts or versions. But there are challenges
there, that I think need to be discussed.
So, both of these systems are based on Android. They don't use Dalvik or
the application framework. But they use what is below that, which means
device drivers in userspaces, like RIL, for the modem drivers, and EGL,
for graphics drivers. The reason they do that is to build on top of all
the existing vendor support for Android. If a SOC and phone vendor
already supports Android, there should be not much needed to do to
support FirefoxOS or Ubuntu Phone.
In practice, this has not benefited the users or the projects. Porting
should be as simple as getting a generic FirefoxOS or Ubuntu Phone image
and run it on top of your Android or CyanogenMod port.
Porting usually requires doing all the same work as porting Android.
Even though one should be able to take advantage of existing ports, it
still requires doing a lot of integration work and building an entire
image, most of the time, including the upper layers, that should be
equal in all devices. This process should require at most creating a new
image based on other images and loading it on the device. I will discuss
more about this below.
I can't forget to mention the
Matchstick TV
project. It is based on FirefoxOS. I think it would have much more
changes to succeed if it was easier for testers to have images available
for all of their gadgets capable of running some form of Android.
Replicant
And then we have Replicant. It has a lot of the problems Android has.
Even so, it's a tremendously important project. First, it offers a free
version of Android, removing all proprietary pieces. This is very good
for the community. But more than that, it tries to free the devices
beyond that.
What the project has been done is reverse engineer some of the pieces,
mostly the modem drivers. That allows other projects to build upon that
work, and support those modems. Without that, there is no telephony or
celullar data available on any of these devices. Not without proprietary
software, that is.
They also have been working on free bootloaders, which is another
important step for a completely free system.
Next steps
There are many challenges here, but I believe we should work on a set of
steps that make it more palatable and produce intermediary results that
can be used by users and other projects.
One of the goals should be good modularity. The ability to replace some
pieces with the least trouble necessary. The update of a single
framework library should be just a package install, instead of building
the entire framework again. If there is ABI breakage, users should still
be able to have access to binaries (and accompanying source code) and
only need to update the library and its reverse dependencies. If one
layer does not have these properties, at least it should be possible to
update this big chunk without interfering with the other layers.
One example is FirefoxOS and Ubuntu Phone. Even if there is a big image
with all system userspace and middleware, the porting, install and
upgrade process should allow the user to keep the applications and to
leverage porting already done by similar projects. Heck, these two
projects should be able to share porting efforts without any trouble.
So what follows is a quick discussion on Android builds, then
suggestions on how to approach some of the challenges.
On Android build
The big problem with Android build is its non-modularity. You need to
build the world and more to get a single image in the end. Instead of
packages that could be built independently, that generated modular
package images, that could be bundled in a single system image. Better
yet would be the ability to pick only those components that matter.
Certainly, portability would be just as interesting, being able to build
certain components on top a GNU system with GNU libc.
At times, it seems like this is done by design, to make it difficult for
"fragmentation" and competition. Basically, making it difficult to
exercise the freedom to modify the software and share your modifications
with others.
Imagine the possibilities of being able to:
- Build Dalvik and the framework on a GNU system in order to run
Android programs on GNU systems.
- Or build a single framework library that would be useful for your Java
project.
- Build only cutils, because you want to use that on your project.
- Build the HAL and be able to use Android drivers on your system.
- Build only RIL and use the modem drivers with
ofono.
There are some dangers in promoting the use of Android like this. Since
it promotes proprietary drivers, relying on such layers instead of
better community oriented layers means giving an advantage to the first.
So, the best plan would be to replace those layers, when they are used,
for things like ofono and
Wayland,
for example.
But, in the meantime, making it easier for users to experiment with
FirefoxOS, Ubuntu Phone, Matchstick TV, Replicant on other devices,
without resorting to building the entire Android system, would be a very
nice thing.
It is possible that there are some challenges with respect to API and
ABI. That these layers are too intermingled that some changes present in
one port would prevent FirefoxOS to run on top of it without changes in
either of the layers. I can't confirm that is the case, but can't deny
the possibility.
Rooting
One of the challenges we have that may have trouble in scaling is
rooting devices.
Unfortunately, most of the devices are owned by the vendor or carrier,
not the user. The user is prevented from replacing software components
in the system, by removing its permissions from replacing most of the
files in the filesystem, or writing to block devices, or change boot
parameters or write to the storage devices.
Fortunately, there are many documents, guides, howtos, and whatnots out
there instructing on how to root a lot of devices. In some cases, it
depends on software bugs that can be patched by the users as instructed
by vendors.
Certainly, favoring devices that are built to allow rooting, hacking,
etc, is a good thing. But we should still help those users out there who
do not have such devices, and allow them to run free software on them.
Booting
Then, comes booting, which is a large discussion on its own, and also
related to rooting, or how to allow users to replace their software.
First, we have the topic of bootloaders, which are usually not free, and
embedded in the chip, not on external storage. So, there are those
pieces of the bootloader which we can replace more easily and those that
we are not, because they would require changing a piece of ROM, for
example.
Das U-Boot would be one of the preferred options for a system. It
supports a lot of hardware platforms out there, a lot of storage devices
and filesystems, network booting, USB and serial booting, and a lot of
other things. Porting is not an easy task, but it is possible.
Meanwhile, using the bootloaders that ship with the system, when
possible, would allow a path where other pieces of the system would be
free.
One of the challenges here is building single images that could boot
everywhere. The lack of a single ARM boot environment is a curse and a
blessing. It makes it hard to have this single boot image, but, on the
other hand, it has allowed so much of the information for such systems
to be free, to be embedded in copyleft software, instead of having blobs
executed by our free systems, like ACPI encourages.
Device trees have pushed this portability issue from the kernel to the
bootloaders. Possibily encouraging vendors to now hide and copyright
this information in the form of proprietary device trees. But it has
made it easier for single images.
In practice, we still need to see a lot of devices out there supporting
this single kernel scenario. And this mechanism only brings us the
possibility of a single kernel. We still need to ship bootable images
that have pieces of bootloaders that are not as portable.
This has caused lots of operating systems out there to be built for a
single board. Or to support just a small set of boards. I struggle with
the concept. Why are we not able to mix device-specific pieces with
generic pieces and get a resulting image that will boot on our choice of
board? Why does every project need to do all the porting work again,
repeating the efforts? Or have one entier ISO image for every supported
board? Check how
Geexbox does it, for an example.
Fortunately, I see Debian going in a good direction.
Here,
one can see how it instructs the user to combine a system-dependent part
with a system-independent part.
Installation
Which brings us to the installation challenge. We should make this easy
and also customizable by the user. Every project might have its own
method, and that is part of the diversity that we should allow.
The great challenge here is handling rooting and booting for the user.
But it's also possible to leave that as separate efforts, as it would be
nice to have good installers as we have in the desktop and server
environments.
Linux
Linux is one of the most ported kernels out there. Of course, it would
be healthy to the diversity I propose that other kernels and systems out
there should work on those mobile devices.
NetBSD,
for example, has a reputation of being very portable and ported to many
platforms. And GNU runs on many of them, either together with the
original systems, or as the main system on top of other kernels, as
proven by the
Debian
GNU/kFreeBSD port, which
uses GNU libc.
But, though I would love to see
HURD running directly on those
devices, Linux and its derivatives are already running on them. Easier
to tackle is to get
Linux-libre
running on those systems.
But though this looks like one of the easier tasks at hand, it is not.
If you run a derivative version from Linux, provided by the vendor,
things should go smooth. But most of the time, the vendor does not
provide patches upstream, and leave their fork to rot, if you are lucky,
in the earlier 3.x series.
And some times, there is not even source code available. There are
vendors out there who do not respect the GPL and that is one of the
reasons why GPL enforcement is important. I take this opportunity to
call attention to the work of
Software Freedom
Conservancy and
its current efforts to
raise funds to continue their
work.
Running an existing binary version of Linux on your device with a free
userspace is part of the strategy of replacing pieces one at a time
while allowing for good diversity and reaching more users.
Drivers
Then we have the matter of drivers. And in this case, it's not only
Linux drivers, but drivers running in userspace. Though others exist,
there are two important and common cases, which are modem and graphics
drivers, both of which are usually provided by Android frameworks, and
that other systems try to leverage, instead of using alternatives that
are more community friendly.
In the case of modem drivers, Android uses its RIL. Besides not using a
Radio or Modem at all, there are two strategies for free versions. One
is using free versions of the drivers for RIL. That's what Replicant
does, because, well, it uses the other Android subsystems after all. The
other one is using a system that is developed by the community. ofono is
one that, even though it's an Intel iniative, looks more community
governed or open to community participation than any Android subsystem
ever was.
As for Graphics, Canonical even built its
Mir project with the goal of being able to
use Android GPU drivers. Luckily, there has been a lot of reverse
engineering efforts out there for a lot of those GPUs shipped with ARM
SoCs.
Then, we can use
Mesa, Wayland and
X.org. Other option, until then, is just using a
framebuffer driver, possibly one that does not need any initialization,
depending on one done by the bootloader, for example.
Middleware and Shells
Plasma Active, that I just found out now is
Plasma
Mobile, looks like a great system. Built by
folks behind
KDE, we can expect great freedom to
come from it. Unfortunately, it suffers from what we have been
discussing here, which is lack of good device support, or shipping
images that run on top of single devices, without leveraging the porting
that has come before of other systems. Fortunately, that is just what I
want to accomplish with this effort.
FSO, that I mentioned before, is a good middleware, that we should try
to run on top of these devices. Running GNOME or Unity shell, and use
rpm or deb based systems, that's all part of the plan on diversity. You
could use
systemd, or
System V init systems, whatever gives you the kicks.
It's not an easy task, since there are so many new things on these new
kinds of devices. Besides touch, there is telephony, which as I
mentioned, would be a good task for ofono. As for TV sets or dongles, I
would love to see
OpenFlint, created by the
Matchstick TV guys, flourish out there and allow me to flint stuff from
my mobile phone running Debian into my TV dongle running Debian.
Project
So, is there a project out there you can start contributing to? Well, I
pointed out a lot of them. All of them make part of this plan.
Contributing to reverse engineering GPUs, or to Plasma Mobile, ofono,
GNOME, Linux-libre, bootloaders, Debian, and so many other projects.
My plans are to contribute in the scope of Debian and make sure it works
well on top of semi-liberated devices, and make sure there is a nice
user interface and good applications when using either GNOME or Plasma.
Integrating ofono is a good next step, but I am running ahead of myself.
Right now, I don't think there is need for an integrated effort. If you
think otherwise, please let me know. If you are doing something in this
direction, I would love to know.
Paul Wise reminded me to point out to the
Debian
Mobile, where I will probably
contribute any documentation and other relevant results.
Thanks
There are some many people to thank, but I would like to remember Ian
Murdock, who created Debian, one of the projects who inspires me the
most. I think the best way to handle his passing is to celebrate what he
has helped create, and move forward, taking more free software to more
people in an easy and modular way.
I have been wanting to write something like this for a long time, so I
thank
Chris Webber for inspiring me on
doing it.
Issues with sam2p and removal
I have been maintaining the Debian package of sam2p for some time.
Unfortunately, the upstream development of that program is no longer
active, and it is using an old custom build chain that no longer works
with recent version of GCC.
This package is currently failing to build from source, and while I
have been able to patch some issues in the past, and it may still be
possible to fix it again, this is not really sustainable.
I am therefore considering to remove sam2p from Debian, unless
someone has a very good reason to keep it and is able and willing to
maintain it.Alternative
sam2p is a raster image conversion tool that can convert PNG and JPEG
to EPS and PDF while keeping their compression, which is mostly useful
to use them in documents compiled with LaTeX. Fortunately, the same can
be done with ImageMagick. If you want to convert to EPS, you have to
specify that you want EPS 2 or 3, otherwise it would produce EPS level 1
which does not provide native raster compression:
Last week was mostly focused on refactoring. I've completely rewritten user interface language selection and related metadata handling. The code is object based and fully covered by testsuite, what was impossible with previous one.
Besides that, there was usual amount of bug fixes and few improvements to the phpMyAdmin container for Docker.
All handled issues:
About one month has passed and here is the usual updated of TeX Live packages for Debian, this time also with an update to biber to accompany the updated version of biblatex. Nothing spectacular here besides fixes for some broken links of fonts.
As a bonus this time, I provide (auto-generated) links to the packages on CTAN, so that one can check the package descriptions and manuals.
Updated packages
I have just released version 1.19 of Obnam, the backup program. See
the website at 
What happened in the 
When I was thinking about using 
While the details about how to join the set of paid contributors have always been public (
The comparison of Germany and Japan with respect to their recent history as laid out in Buruma s book throws a spotlight on various aspects of the psychology of German and Japanese population, while at the same time not falling into the easy trap of explaining everything with difference in the guilt culture. A book of great depth and broad insights everyone having even the slightest interest in these topics should read.
Those of you not interested in boring and melancholic look-back onto history can safely skip reading this one. For those a bit interested in the history of TeX in Debian, please read on.
Debian releases and TeX systems
The TeX system of choice has been for long years 
Development over the years
TeX Live 2005 was just another TeX system but not the preferred one in Debian Etch and beyond. But then in May 2006, Thomas Esser announced the end of development of teTeX, which cleared the path for TeX Live as main TeX system in Debian (and the world!). The next release of Debian, Lenny (1/2009), already carried only TeX Live. Unfortunately it was only TeX Live 2007 and not 2008, mostly due to me having been involved in rewriting the upstream infrastructure based on Debian package files instead of the notorious xml files. This took quite a lot of attention and time from Debian away to upstream development, but this will be discussed in a different post.
Similarly, the release of TeX Live included in Debian Squeeze (released 2/2011) was only TeX Live 2009 (instead of 2010), but since then (Wheezy and Jessie) the releases of TeX Live in Debian were always the latest released ones.
Current status
Since about 2013 I am trying to keep a regular schedule of new TeX Live packages every month. These helps me to keep up with the changes in upstream packaging and reduces the load of packaging a new release of TeX Live. It also bring to users of unstable and testing a very up-to-date TeX system, where packages at most lack 1 month of behind the TeX Live net updates.
Future
As most of the readers here know, besides caring for TeX (Live) and related packages in Debian, I am also responsible for the TeX Live Manager (tlmgr) and most of upstream s infrastructure including network distribution. Thus, my (spare, outside work) time needs to be distributed between all these projects (and some others) which leaves less and less time for Debian packaging. Fortunately the packaging is in a state that making regular updates once a month is less of a burden, since most steps are automatized. What is still a bit of a struggle is adapting the binary package (
I've been using bridge networking and tap networking for containers
and virtual machines on my system. Configuration for bridge network
which I use to connect containers was configured using
/etc/network/interfaces file as shown below.
During the summer, the private mailing list for a large online community discussed the mental illness of a contributor to a project. Various people expressed opinions that appeared to be generalizations about all those with mental illness. Some people hinted the illness was a lie to avoid work while others speculated about options for treatment. Nobody involved mentioned having any medical expertise.
It is ironic that on the one hand, we have the dramatic example of an aircraft crashing at the hands of somebody who is declared unfit to work but working anyway and on the other hand when somebody else couldn't do something, the diagnosis is being disputed by people who find it inconvenient or don't understand it.
More recently, there has been openly public discussion about whether another developer may have had mental illness. Once again, there doesn't appear to be any evidence from people with any medical expertise or documentation whatsoever. Some of the comments appear to be in the context of a grudge or justifying some other opinion.
What's worse, some comments appear to suggest that mental illness can be blamed for anything else that goes wrong in somebody's life. If somebody is shot and bleeds to death, do you say low blood pressure killed him or do you just say he was shot? Likewise, if somebody is subject to some kind of bullying and abused, does this have no interaction with mental illness? In fact, Google reveals 
Debian LTS
December was the eighth month I contributed to 