The fairphone 2 is "fairly" hacker-friendly. The bootloader is not locked. They provide android stripped of google mobile services, and Ubuntu phone is reportedly 70% ported. Sailfish OS could also be an option if either Fairphone or Jolla port it. All of these setups still require binary blobs for firmware, but that's as good as it gets on mobile I think.

> Sailfish OS could also be an option if either Fairphone or Jolla port it.

It seems to have already happened[1].

[1] - https://wiki.merproject.org/wiki/Adaptations/libhybris/Insta...

yes, but it's not an "official" image yet, meaning it won't receive support from the Jolla developers (and is missing some things like the Android app compatibility layer)

When they release a version of it with US 3G/4G bands, it would be an option.

Ideologically, I like Replicant. Actually free-as-in-freedom version of Android, great!

In reality though, it doesn't really work on most of modern phones, and on the ones it works on, there is no WiFi support. And the latest commit on the Replicant git (excluding website changes) is 8 months ago. And it has just one guy committing.

So it didn't catch world's attention, apparently.

The Replicant project wrote a post in August describing work on Replicant 6:

http://blog.replicant.us/2016/08/replicant-6-early-work-upst...

My phone (Galaxy S3) uses Replicant, and I'm quite excited for the upgrade, which will fix a number of rather unfortunate issues. I'm more than willing to make such sacrifices, but it'd be nice (for example) to be able to take videos of my children, which the current version cannot do.

It's not a shortcoming of Replicant---the fact that these issues exist at all demonstrate how much value is placed on user freedom.

Most unfortunate is that few users will be willing to make these sacrifices.

Yeah. But again, it doesn't seem like there is a huge and vibrant developer community inspecting the code, implementing features and fixing bugs; looking at their gitlab and their redmine, it seems like there is almost no activity.

(It's possible I just don't understand the websites; looking at their GitLab and Redmine, I start to understand why is Github so popular; I cannot find anything there :(( )

Android is Linux on the phone. It's Linux kernel with stuff on top. Check out Replicant. It removes most of the stuff you might find objectionable.

>> Android is Linux on the phone. It's Linux kernel with stuff on top.

Android is just the Linux kernel on the phone -- that's the issue I have with it. It comes with none of the other stuff that makes GNU/Linux great: philosophically/socially it's different, but on a technical level it's missing rest of the GNU/Linux stack (e.g. package management, and the plethora of developer tools -- including languages and libraries). The GNU/Linux stack is developed by a diverse ecosystem of contractors, big and small business, and non-for-profits (e.g. Red Hat, Intel, Mozilla, Samsung, Canonical, Document Foundation, Fujitsu, Google, etc). Android is largely controlled by one company.

The lack of package management and standard kernel/modules is a huge issue from Android. It keeps it from being truly open. I wrote a post about this a while ago:

http://penguindreams.org/blog/android-fragmentation/

The TL;DR, Android needs to be fixed so ASOP can be installed on any phone, just like Linux/Windows. The current state is bizarre for what's essentially now a general purpose operating system.

I think you mean AOSP (Android Open Source Project) not ASOP (the linked article makes the same typo).

Wow...I even spelled it out at one point and still screwed it up while abbreviating it! Thanks man. I'll fix it. :)

I habitually think of it as 'aesop' of the fables fame in my head, even though I know it's inaccurate. Hard habit to break. Like eye-terator instead of it-erator.

And with Brillo and Fuchsia, Google is removing whatever is left of it.

What is Brillo taking away? I thought it was more a standardization of the HAL and Linux kernel?

Imagine Android with the Java Frameworks replaced by a similar C++ Framework, using Android IPC (not UNIX), bionic libc and Android's own Linux kernel fork.

https://www.youtube.com/watch?v=ig9GKAFzDxQ

https://www.youtube.com/channel/UCthvmTSlmIcMH93LIJNe-2w/sea...

Is Tizen any closer to this?

I honestly don't know what's happening with Tizen these days -- Samsung has invested money into it, but it has (IMO) very little to show. Again, my bias is showing, but I think Jolla (SailfishOS) and Canonical (Ubuntu Touch) have achieved infinitely more with smaller teams and less capital.

From what I've read, you want as little as possible to do with Tizen:

https://what.thedailywtf.com/topic/15001/enlightened

Taking away those things doesn't make it not Linux. Adding those things wouldn't make it not Android. These guys could have had the best of both worlds.

He didn't say anything about it not being Linux; he said it isn't GNU/Linux, which it isn't, the GNU parts are missing.

A lot of the things that he mentioned (package management, even development tools) don't necessarily require a GNU stack.

It is, and it isn't. Android has controversial patches on Linux that aren't merged upstream. They are more significant than say the patches Linux distributions maintain in their releases.

If anything, Android is a fork of Linux.

And the android UI framework is still garbage, having to freeze and thaw activity state just to handle screen rotation is the most insane thing I have ever heard of. Hell, even the various Symbians handled this better (I loved my Symbian S60 devices, but programming for them was an exercise in frustration).

I'm assuming you're referring to the behavior where activities are restarted on rotation and onSaveInstanceState() gets called.

This behavior is the default because it prevents developers from needing to think about their UI changing dimensions (including runtime screen size/density changes!)... but it's certainly not required by the framework.

If you set android:configChanges="orientation" in your application manifest, your app won't be automatically restarted. However, you'll become responsible for swapping out any UI resources at that point.

(Keep in mind that Android lets you declare completely different UI layouts and drawables for different device configurations, so depending on how you wrote your app, you may need to re-inflate part of your UI.)

Or just implement onSaveInstanceState() and let the OS do everything for you.

>This behavior is the default because it prevents developers from needing to think about their UI changing dimensions (including runtime screen size/density changes!)... but it's certainly not required by the framework.

No, the framework uses it to let you automatically handle those changes, the reason it's there is because early Android devices were weak (obviously) and the pipe dream was that we'd write apps that didn't mind randomly getting their processes killed as long as we used onSaveInstanceState... man-centuries later and it's clear the dream didn't pan out. I wonder how many billions of NPEs it was worth to be able to say Android does what iOS don't (multitasking) back then.

And that android:configChanges line misses out on many other triggers that cause you to need to handle onSaveInstanceState (like someone plugging in a keyboard). Even with every flag set for configChanges you still need to implement onSaveInstanceState for process death to work as intended.

The Android framework really is garbage. I might be biased though, I spent the day trying to trick it into not going to 7(!) FPS because our designers had the audacity to request we translate a video in an animation (and don't get me started on the insanity that is animations on Android [the X ways we've now gotten to do it which all have their own limitations]).

Yet both Windows Mobile and iOS handle this flawlessly without having to wire all sorts of extra code up. Sure, it's possible to do it with Android, but it's a hell of a lot more work than any other platform.

Android is not GNU

I think @maheart knows that and that is his main problem with Android.

Not really, there are lots of APIs missing from the NDK, UNIX IPC being a set of them.

Unfortunately it's also JVM [edit: Java] on the phone.

It is a fork of the Java language with its own AOT/JIT compiler, nothing to do with a certified JVM.

Larry Ellison doesn't seem to agree with your "nothing to do with [...] JVM" assertion, to the tune of a 9.3 billion USD lawsuit, and indeed Google itself is developing Fuchsia with no java stack at all in it.

Moreover, it's not Linux if you have to use a Java API to do anything useful.

Nothing to do from the point of view of the headaches that brings to those of us that care about Java.

And everything to do regarding being a fork on the Java ecosystem, and I side with Oracle.

It remains to be seen if Brillo or Fuchsia will have any relevance on the market, even when coming from Google.

and I'm not a java lover as you can tell, but I can super-appreciate that for java guys, having some fork that tries to be java-not-java and confuses the ecosystem, is a pain in the butt. Be java fully committed and move it forward, or leave java well alone. Don't sit there and create a java version of the Python 2/3 mess that screws everyting up. I can totally appreciate that. Well put.

The lawsuit was not about the VM.

Look. The gist of the comment is that Android forces you to use java, or at the very least, a java API. You can dance around semantics as much as you like, but it will not change the fact that, unlike Linux, Android is intricately interlinked with java.

It's a subset of Java, with a totally different compiler, JIT, etc. Newer versions don't even use Dalvic, but compile/cache the bytecode into ELF/machine code.

What does it matter what's underneath? At the visible layer which most of us have to use, it's java.

If you haven't already, please consider the Pyra. It's a full Linux desktop in a phone-ish format and supports SIM cards for voice calling and text.

https://pyra-handheld.com/boards/pages/pyra/

You suggest using that monstrosity as a phone?

Yes, of course. I don't remember the last time I made a voice call, so I don't care at all about that functionality.

Really, all I care about is receiving SMS.

This looks like a rehashed Casiopeia. (Actually the Casiopeia looks considerably sleeker in comparison.) This is the clunkiest-looking device I've seen in a long time. At some point can we acknowledge that shrinking a laptop to be palm-sized doesn't make for a good form factor? A tiny keyboard and a resistive 720p 5" touchscreen sounds like a terrible experience. The picture shows it literally rendering a standard desktop UI as if that's appropriate for a pocket device.

Also, does this thing even receive SMS? The page makes no mention of phone support.

http://www.pdastock.com/Casio-Cassiopeia-A-21-651.html

A full Linux desktop screen wouldn't be used for long periods of time. The ideal situation is that we, as hackers, can build our own mobile UI free from the clutches of Apple and Google, and that you can just plug it into HDMI anywhere you are and get a full computer, which is something you can't do with any phone currently.

To your question regarding SMS, there are already people working on it. A Vim plugin sounds especially delicious.

https://pyra-handheld.com/boards/threads/how-to-send-receive...

By full computer, you mean something of 'low-end chromebook' spec. Usable mobile power management and thermal design isn't really going to achieve what you get with a good laptop or desktop.

Very true! This hardly holds up to, say, a CAD$600 laptop. But, it'll be very handy to take traveling around the world or to visit my parents/nephew to play some Minecraft.

You want a free-as-in-freedom portable device so you can play a closed source Microsoft product?

Nobody's perfect :)

I'm preparing him for Minetest, though, if that makes you feel better!

I suppose the concern is more regarding the clunkiness of the design, as in, "it doesn't fit in my jeans pocket", not so much the functionality. Like you say, "phone" today is really just a moniker for "tech device I always carry on me".

Yes, this is a concern for most people, but the GameBoy used to fit perfectly into my pockets, so I really don't care.

It looks ..worse than the phone I used 8 years ago

https://en.wikipedia.org/wiki/LG_enV2_(VX9100).

Extremely interesting.

Please tell us more about the LTE capabilities. Is it provided by a removable board? Which bands are supported??

Based on https://www.dragonbox.de/en/45-pyra it only supports B17 and AWS, which makes it mostly a AT&T compatible device

I wish it would support other bands, B25 for sprint (which has cheaper LTE plans)

Also, the wifi chipset is known. Can you run a hostapd?

You probably know more than me.

Here's what I could find on the wiki.

https://www.pyra-handheld.com/wiki/index.php?title=Modem

and

https://www.pyra-handheld.com/wiki/index.php?title=WiFi

Interesting. The photo looks kinda bulky, but it's pretty zoomed in. I guess it's more DS sized?

That's like the phone equivalent of the F-35

That page implies good battery life:

"A 6000mAh battery means you have a companion that will be there for you, through use and at times other devices have given up long ago."

But if you look deeper you find on their wiki:

https://pyra-handheld.com/wiki/index.php?title=Battery

"Everyday work load: 8 hours (without any power management features, tested on prototype April 2016)"

8 hours? This is a toy. Why is their headline figure "6000mAh" instead of "8 hours"? Because they know it's shit.

I guess you have little experience with embedded bring-up, "without any power management features" is a fairly whopping qualifier, and quoting battery capacity is a far more useful indicator for a prerelease device.

I've been on projects where the dev builds would last 30 minutes on battery right up to days before initial factory run

It's in your own quote - it was on a prototype, without any power management features. Once power management features are enabled, it will last longer.

Yes, I sure hope we can use GNU/Linux on phone one day. It wouldn't be that hard to make, given an unlocked hardware platform and open source drivers for baseband and graphics module. Actually, I have done a device very similar to smartphone in its hardware capabilities, but it was a commercial product limited in functionality. If I could get such hardware at home, I would definitely make some crude, hackish GNU/Linux smartphone.

Right now, thanks to libhybris[1] you can run glibc compiled systems (i.e. regular Linux, aka GNU/Linux) on top of proprietary Android drivers.

[1] https://github.com/libhybris/libhybris

I'd pay for a tutorial that shows how to use libhybris to accomplish that.

True true, I'm craving the day Ubnut Phone runs on my OnePlus 3. But I also used an loved Window Phone (so smooth, so intuitive and beautiful)... But the lack of apps kills you. Start with being able to run APKs, go from there please.

a port for OP3 is currently under development https://devices.ubports.com/#/op3

If only there was any decent hardware for Jolla.

The Fairphone 2 has decent* hardware specs[1] and it can run SailfishOS[2].

* approx. the same as OnePlus One, which partially[3] supports sailfish as well

[1] - https://shop.fairphone.com/en/ [2] - https://wiki.merproject.org/wiki/Adaptations/libhybris/Insta... [3] - https://wiki.merproject.org/wiki/Adaptations/libhybris

And if only Sailfish OS was open source. https://together.jolla.com/question/80676/request-fully-open...

This is true, and I hope SailfishOS will one day be completely FOSS, but please have a look at the bigger picture.

Here's a comment I wrote about the situation on reddit:

---

Yes, I'd prefer SailfishOS to be 100% FOSS, but Jolla is helping GNU/Linux establish its roots on the mobile.

How is it doing this?

* libhybris has opened up a whole new world for GNU/Linux, by allowing programs developed against glibc (i.e. GNU/Linux) to run on top of proprietary Android drivers (i.e. phones).

* Jolla puts a lot of development into lipstick, which makes it easier to develop UXs for phones/tablets/other form factors [This involved developing Wayland support]

* Jolla have opensourced their browser (Qt5 + Gecko engine) and their office suite (Nokia's Calligra Office work, with a QML interface)

* Jolla develops a sychronisation framework (buteo-sync) that can be used for syncing emails, Twitter, CalDav/CardDav, etc (I think Ubuntu Touch might adopt it in the future)

* Want to see how much manpower Jolla dedicates to developing FOSS? Look at the number of @jollamobile.com emails here: https://git.merproject.org/groups/mer-core/activity

* The SailfishOS community has been developing sfdroid. A FOSS application for running Android apps on your GNU/Linux mobile.

So while SailfishOS isn't 100% open source, it's doing a lot of good for the GNU/Linux community on the mobile.

If you're not satisfied with the "official" devices (e.g. Jolla 1, Intex Aquafish, or Jolla C [if you were lucky enough]), then there are a number of community ports at varying levels of maturity[1].

Otherwise, there's the possibility that the Fairphone 2 will receive official SailfishOS support. Finally, there's a number of yet unreleased devices with official SailfishOS support[2]

[1] https://wiki.merproject.org/wiki/Adaptations/libhybris

[2] https://together.jolla.com/question/136143/wiki-available-de...

What's wrong with Android as a hacker-friendly platform?

Android (and Apple) have a relatively rigid development toolkit. For Android you develop using the Java programming language against the Android APIs. The NDK is available, and you can always hack up methods to call the Android APIs from your favourite programming language (e.g. Python) but it's cumbersome.

I develop software for SailfishOS. It's like the Linux desktop. I SSH into my phone. zypper/pkcon install some dev tools (e.g. gcc, make, git). I initialise a Python virtualenv, pull down some libraries (e.g. Flask). I want to query SMS messages? I open an sqlite database on the filesystem. I can define services using systemd files. It really is "just Linux" underneath.

Very interesting! Do you work at Jolla or are there any 3rd party jobs?

I do not work for Jolla. I am in no way affiliated with Jolla, other than being part of the Jolla/SailfishOS/Maemo/Meego community. I try to support SailfishOS development (by buying Jolla devices, developing software for the platform and evangelizing its benefits).

The paid ecosystem around SailfishOS is non-existent, having said that Jolla are looking to hire: http://jolla.com/jobs

Yes, but AFAIK they don't hire remotely, at least for engineering jobs.

Out of curiosity, is there any thorough Qt for mobile tutorial working nicely on Jolla C? I am even willing to pay for it if it teaches me how to do advanced stuff, like getting straight to OpenGL with the least amount of clutter etc. I would love to write some Sailfish-only apps cool enough to attract regular people.

As long as it is systemd based it is not "just Linux".

BTW, it was actually in the Sailfish IRC dev chat that the whole "hire an assassin to take out Poettering" thing was uttered as a late night, off color, joke...

You can do most of that on a jailbroken iOS device as well. It even has launchd which you configure similarly to systemd files.

Drivers, Google Play Services, Googles move towards locking down the OS (now you can't get the local device's Bluetooth MAC address without a system level permission(!)).

I work on Android daily on hardware that is as "hacker friendly" as it comes besides the driver issue, and it fights you tooth and nail.