I had been using my Samsung Galaxy S Relay 4G for almost three years
when I decided to get a new phone. I would use this new phone for daily
tasks and take the chance to get a new model for hacking in the future.
My apexqtmo would still be my companion and would now be more available
for real hacking.
And so it also happened that its power button got stuck. It was not the
first time, but now it would happen every so often, and would require me
to disassemble it. So I managed to remove the plastic button and leave
it with a hole so I could press the button with a screwdriver or a
paperclip. That was the excuse I needed to get it to running Debian
only.
Though it's now always plugged on my laptop, I got the chance to hack on
it on my scarce free time. As I managed to get a kernel I built myself
running on it, I started fixing things like enabling devtmpfs. I didn't
insist much on running systemd, though, and kept with System V. The Xorg
issues were either on the server or the client, depending on which
client I ran.
I decided to give a chance to running the Android userspace on a chroot,
but gave up after some work to get some firmware loaded.
I managed to get the ALSA controls right after saving them inside a
chroot on my CyanogenMod system. Then, restoring them on Debian allowed
to play songs. Unfortunately, it seems I broke the audio jack when
disassembling it. Otherwise, it would have been a great portable audio
player. I even wrote a small program that would allow me to control mpd
by swiping on the touchscreen.
Then, as Debian release approached, I decided to investigate the
framebuffer issue closely. I ended finding out that it was really a bug
in the driver, and after fixing it, the X server and client crashes were
gone. It was beautiful to get some desktop environment running with the
right colors, get a calculator started and really using the phone as a
mobile device.
There are two lessons or findings here for me. The first one is that the
current environments are really lacking. Even something like GPE can't
work. The buttons are tiny, scrollbars are still the only way for
scrolling, some of the time. No automatic virtual keyboards. So, there
needs to be some investing in the existing environments, and maybe even
the development of new environments for these kinds of devices. This was
something I expected somehow, but it's still disappointing to know that
we had so much of those developed in the past and now gone. I really
miss Maemo. Running something like Qtopia would mean grabing a very old
unmaintained software not available in Debian. There is still matchbox,
but it's as subpar as the others I tested.
The second lesson is that building a userspace to run on old kernels
will still hit the problem of broken drivers. In my particular case,
unless I wrote code for using Ion instead of the framebuffer, I would
have had that problem. Or it would require me to add code to
xorg-xserver that is not appropriate. Or fix the kernel drivers of
available kernel sourcecodes. But this does not scale much more than
doing the right thing and adding upstream support for these devices.
So, I decided it was time I started working on upstream support for my
device. I have it in progress and may send some upstream patches soon. I
have USB and MMC/SDcard working fine. DRM is still a challenge, but
thanks to Rob Clark, it's something I expect to get working soon, and
after that, I would certainly celebrate. Maybe even consider starting
the work on other devices a little sooner.
Trying to review my post on
GNU on
smartphones, here is where I would put some
of the status of my device and some extra notes.
On
Halium
I am really glad people started this project. This was one of the things
I criticized: that though Ubuntu Phone and FirefoxOS built on Android
userspace, they were not easily portable to many devices out there.
But as I am looking for a more pure GNU experience, let's call it that,
Halium does not help much in that direction. But I'd like to see it
flourish and allow people to use more OSes on more devices.
Unfortunately, it suffers from similar problems as the strategy I was
trying to go with. If you have a device with a very old kernel, you
won't be able to run some of the latest userspace, even with Android
userspace help. So, lots of devices would be left unsupported, unless we
start working on some upstream support.
On RYF Hardware
My device is one of the worst out there. It's a modem that has a
peripherical CPU. Much has already been said about Qualcomm chips being
some of the least freedom-friendly. Ironically, it's some with the best
upstream support, as far as I found out while doing this upstreaming
work. Guess we'll have to wait for opencores, openrisc and risc-v to
catch up here.
Diversity
Though I have been experimenting with Debian, the upstream work would
sure benefit lots of other OSes out there, mainly GNU+Linux based ones,
but also other non-GNU Linux based ones. Not so much for other kernels.
On other options
After the demise of Ubuntu Phone, I am glad to see
UBports catching up. I hope the project is
sustainable and produce more releases for more devices.
Rooting
This needs documentation. Most of the procedures rely on booting a
recovery system, which means we are already past the root requirement.
We simply boot our own system, then. However, for some debugging
strategies, getting root on the OEM system is useful. So, try to get
root on your system, but beware of malware out there.
Booting
Most of these devices will have their bootloaders in there. They may be
unlocked, allowing unsigned kernels to be booted. Replacing these
bootloaders is still going to be a challenge for another future phase.
Though adding a second bootloader there, one that is freedom respecting,
and that allows more control on that booting step to the user is
something possible once you have some good upstream support. One could
either use kexec for that, or try to use the same device tree for
U-Boot, and use the knowledge of the device drivers for Linux on writing
drivers for U-Boot, GRUB or Libreboot.
Installation
If you have root on your OEM system, this is something that could be
worked on. Otherwise, there is
magic-device-tool,
whose approach is one that could be used.
Kernels
While I am working on adding Linux upstream support for my device, it
would be wonderful to see more kernels supporting those gadgets.
Hopefully, some of the device driver writing and reverse engineering
could help with that, though I am not too much optimistic. But there is
hope.
Basic kernel drivers
Adding the basic support, like USB and MMC, after clocks, gpios,
regulators and what not, is the first step to a long road. But it would
allow using the device as a board computer, under better control of the
user. Hopefully, lots of eletronic garbage out there would have some use
as control gadgets. Instead of buying a new board, just grab your old
phone and put it to some nice use.
Sensors, input devices, LEDs
There are usually easy too. Some sensors may depend on your modem or
some userspace code that is not that easily reverse engineered. But
others would just require some device tree work, or some small input
driver.
Graphics
Here, things may get complicated. Even basic video output is something I
have some trouble with. Thanks to some other people's work, I have hope
at least for my device. And using the vendor's linux source code, some
framebuffer should be possible, even some DRM driver. But OpenGL or
other 3D acceleration support requires much more work than that, and, at
this moment, it's not something I am counting on. I am thankful for the
work lots of people have been doing on this area, nonetheless.
Wireless
Be it Wifi or Bluetooth, things get ugly here. The vendor driver might
be available. Rewriting it would take a long time. Even then, it would
most likely require some non-free firmware loading. Using USB OTG here
might be an option.
Modem/GSM
The work of the Replicant folks on that is what gives me some hope that
it might be possible to get this working. Something I would leave to
after I have a good interface experience in my hands.
GPS
Problem is similar to the Modem/GSM one, as some code lives in
userspace, sometimes talking to the modem is a requirement to get GPS
access, etc.
Shells
This is where I would like to see new projects, even if they work on
current software to get them more friendly to these form factors. I
consider doing some work there, though that's not really my area of
expertise.
Next steps
For me, my next steps are getting what I have working upstream, keep
working on DRM support, packaging GPE, then experimenting with some
compositor code. In the middle of that, trying to get some other devices
started.
But documenting some of my work is something I realized I need to do
more often, and this post is some try on that.
long time no blog post. & the 
A lovely little game, 
This is about he same you pay for Netflix, or some other streaming service. If you remain on the free side, what remains for you to do is SNS-like stuff, and uploading your papers so that academia.edu can make money from it.
What I am really surprised that they can pull this of at a .edu domain. The registry requirements state
A little while back, in June, I sat my last exam for what I hoped would be the
last module in my degree. For seven years, I've been working on a degree with
the 
The twelveth update in the 0.12.* series of 
The packages on this site are not distributed inside TeX Live proper for one or another of the following reasons:
In addition to
Like 
Previously: 
I've released version 1.6.1 of 
Recently, I and my Co speaker Pranav Jain, got a chance to speak at Open Source Bridge conference which was held in Portland, Oregon!
Pranav talked about GSoC and I talked about Outreachy , together we talked about Free RTC project Lumicall.
We talked and exchanged ideas about the programme. and.. she clicked beautiful pictures of us delivering the talk.
Picture Courtesy Sarah Sharp
Picture Courtesy Sarah Sharp
Thank you Debian for giving us a chance to speak at Open Source Bridge and to meet wonderful people in Open Source. 
Dear all, This would be a biggish one so please have a chai/coffee or something stronger as it would take a while.
I would start with attempt at some alcohol humor. While some people know that I have had a 
It included couple of co-organizers with most people being newbies so while I had thought of showing how to contribute via reporting bugs or putting up patches, had to set that aside and explain how things work in free software and open-source world. We didn t get into the debate of free vs open-source or free/open-source/open-core as that would have been counter-productive and probably confusing for newbies.
We did however share the debian tree structure
I was stumped by /var and /proc . I hadn t taken my lappy as it is expensive (a lenovo thinkpad I love very dearly) and I was unsure if I would be able to take care of it (weight wise). Dhanesh had told me that he had Debian on his lappy + zsh both of which are my favourites.
While back at home I realized /var has been relegated to having apache/server logs and stuff like that, I do recall (vaguely) a thread on debian-devel about removing /var although that discussion went nowhere.
One of the bugs that we hit early on is that nobody had enough space on their hdd to have Debian comfortably. It took a while to get an external hdd and push some of the content from somebody s lappy to the external drive to have space for the installation.
I did share the /. /home, optional swap while Dhanesh helped by sharing about having a separate /boot partition as well which I had forgotten. I can t even begin to remember the number of times having a separate /boot partition has helped me in all of my systems.
That done, we did try to install/show Debian 9 without network but were hit with 
Dhanesh is on the left while I m on the right.
We did have a cute 3-4 year old boy as our guest as well bud didn t get good pictures of him.
Lastly, the Debian cake itself
We also talked about the kernel and subsystem maintainers and how Linus is the overlord.
Look forward to comments. I am hoping Dhanesh might recollect some points that I might have missed/forgotten.
Update 07/07/17 All programming languages stats. can be seen 
