My Ubuntu for mobile devices post-mortem analysis
lieberbiber.de
lieberbiber.de
I'd pay a lot of money for an actual open linux phone, but nobody wants to make one.
I'm not saying I won't try it, but it seems to me like it has a lot going against it already. I'll wait for reviews on this one.
Not that I won't try it, but I don't see it taking off anytime soon.
(For comparison, the Jolla 1 phone has equal or better specs to the Neo900, but its users have been clamoring for better hardware for years now.)
The acid test will be the jump from the legacy image (15.04) to the 16.04 LTS one.
Fingers crossed.
Make it anything resembling viable and I'm there.
I use it as my daily phone, and I've developed apps for it, so feel free to ask me any questions.
SailfishOS should hopefully be available for the Sony Xperia X soon (within a month according to their blog posts).
[1] https://sailfishos.org/ [2] https://git.merproject.org/groups/mer-core/activity
If you have to flash the OS to use it, they've already lost, and I'd argue that was one of Ubuntu Phone's biggest problems too.
I definitely think Canonical bit off more than they could chew:
Mir
Not making use of existing Android drivers (I think they resolved this issue later on)
Building their own app deployment and isolation system (Snappy)
Building their own browser (although they did wisely reuse CEF, or was it WebEngine?)
Convergence
However, I think Jolla/SailfishOS did a number of things better:
They used Wayland.
They used existing Android drivers (using libhybris).
App installation/deployment is done using regular RPM. There's currently extremely minimal app isolation. This is a very hard problem. Let the Flatpak folk solve it, then adopt it.
They used Nokia's browser (based on Gecko) and office suite (based on Calligra). These were used on the N9, which had a larger install base than all existing Linux-on-the-mobile projects.
They used a well-tested ConnMan/ofono combo (these were used on the N9, see above).Would have dropped Android for something like Tails or OpenBSD for phones.
(Apologies for being a bit harsh; I've wasted a ton of time recently hacking on Allwinner and Amlogic chips)
Sony last year announced their intention to "mainline" their Xperia devices (their main phone brand)[1]. This could eventually mean running Android on the latest mainline kernel, and perhaps even GNU/Linux[2].
[1] https://developer.sonymobile.com/2016/02/17/work-on-the-main...
[2] Jolla (developers of SailfishOS, a real-Linux-on-mobile OS) announced in February that they are partnering with Sony to bring SailfishOS to the Xperia X (https://jolla.com/wp-content/uploads/2017/02/Sony_Jolla_pres...), which should hopefully be out this month. It's taken a long time, but real-Linux-on-the-mobile is getting closer.
isn't Android a mobile os running linux?
I hope you meant real-GNU /Linux-on-mobileOS
note: "Android is running Linux" is certified by Linus Torvalds
As a software platform, it isn't even remotely similar.
Linux is a kernel, and Linus has all the right in the world to make that claim. It doesn't in any way strengthen your argument though because of the different userland. You are comparing apples (operating systems) with oranges (kernels).
I tried to tell that his "real-Linux" (kernel) already exists (I don't know if he meant (in another comment, he said that he meant userland) userland e.g gnu, freedesktop.org etc by "real-Linux")
If I'd said "Linux-on-the-mobile", you could just as easily have said "Linux (kernel) is already on the mobile!".
If I'd said "GNU/Linux-on-the-mobile", you could have argued that Termux[1] adds GNU tools to your Android phone.
Half the things you'd expect on a "Linux" system (e.g. systemd, a Wayland compositor, X, DBUS, PulseAudio) are not associated with FSF/GNU at all.
Without nitpicking, when you say "Linux" most people think "Red Hat" (or Debian, Ubuntu, Arch, etc), not "Android".
[1] granted Mir may have kicked Wayland development into gear
* Jolla has always used (and continues to use) outdated hardware, Ubuntu Phone OS shipped with or ran on reasonably performant hardware. Only after several years is Jolla now discussing the possibility of porting the OS to a somewhat modern device (Sony Xperia)
* The Sailfish SDK relies on VirtualBox for the emulator and for native compilation, a drain on resources and memory, and an indication that the development team was not well versed in creating cross compilation ecosystems or tools. Ubuntu Phone SDK was limited to Ubuntu Linux, but ran natively (Sailfish SDK required VirtualBox even on Linux)
* For years, Jolla withheld from or misled the public on the state of internal affairs (Canceled tablet, no refunds for crowdfunders, CEO and key employees quitting, lack of funding, relying on volunteers for key areas of development)
* Sailfish OS has always lacked basic security features for applications (QT Quick embedded in plain text) or for the phone itself (encryption, permissions). Sailfish's security problems may be just as problematic as Tizen's
* Sailfish OS was never true open source, even less so than Android, although it has always been advertised as such.
* Very poor/non-existent developer relations - A few developers attempted to make games for Jolla, but encountered serious problems that the developers weren't interested in fixing (i.e. SDL2 on Jolla not supporting landscape mode, preventing games from being submitted), even worse, the developer for the SDL2 Wayland port flat-out refused to fix the problem or provide the source code for other people to fix the issue. Such problems or resistance from the developers were never encountered on Ubuntu Phone OS.
But Jolla has shipped. Jolla 1, Intex Aquafish, Turing Phone, Inoi R7[1]. Limited runs of Jolla C, Tablet. Sony Xperia X should be coming soon. This is a startup of (these days) less than 50 people, cut them some slack, they're competing with giants.
> The Sailfish SDK relies on VirtualBox for the emulator and for native compilation
It's infinitely more efficient to build and ship 1 VirtualBox OS Bundle, v.s. building and maintaining at least 3 different cross-compilation toolchains (one for each of: Windows, MacOSX, Linux). With limited developer resources, I'd choose the latter route too.
I also prefer this setup to things like scratchbox2 and Android's (or iPhone's) emulator. It's portable between base OS's and it makes use of existing and well-known tools (VirtualBox).
> For years, Jolla withheld from or misled the public on the state of internal affairs
The Tablet fiasco could have been communicated better. At the same time, that's the risk you take with Kickstarter/IndieGoGo. It's a startup.
I don't agree with any of your other points, they're a startup, it's not all smooth sailing.
> Sailfish OS always lacked basic security features for applications (QT Quick embedded in plain text) or for the phone itself (encryption).
In regards to packaging, or app isolation, Jolla's wisely chosen to work on "mobile problems" and leave package management to the heavyweights (e.g. RH with Flatpak).
VPN support was added in the last release. The public git repos show ongoing work to filesystem encryption.
> Sailfish OS was never true open source, even less so than Android
Significant pieces of SailfishOS are proprietary. However, I think it's a more "inclusive" OS than Google's Android. Google develops Android. SailfishOS is GNU/Linux, it's developed by Red Hat (e.g. Linux kernel, systemd), Intel (Connman, ofono), Qualcomm (BlueZ), Qt (Qt Company), Mozilla (Firefox), GNU (CLI tools), KDE (Calligra), Collabora (gstreamer), etc.
I'm hopeful that one day SailfishOS will be fully open source.
> Very poor/non-existent developer relations
Disagree. They hold fortnightly meetings (#mer-meeting on Freenode). Most of the code is public (https://git.merproject.org/). There's a public Bugzilla (https://bugs.merproject.org/). There's discussion boards (https://together.jolla.com/). Community translation portal (http://translate.sailfishos.org/).
[1] https://together.jolla.com/question/136143/wiki-available-de...
Proving my point - all of these devices (except for Experia, and possibly the Tablet) ran on hardware outdated at release time. Ubuntu Phones ran on reasonably performant hardware (Edge, Meizu MX5 and Google Nexus 5) at release time.
Your personal preference for VirtualBox, or VirtualBox being "well known", is irrelevant. Virtualization is unnecessary and a waste of resources compared to cross compilation and emulation via QEMU.
> At the same time, that's the risk you take with Kickstarter/IndieGoGo. It's a startup.
The tablet problem was more than a matter of communication. It demonstrated that Jolla wasn't ready for prime-time the way they advertised. Backers will empathize with a product not ready for prime-time if the people involved are transparent. Whether you like it or not, unaccounted product delays, CEO's quitting without explanation, staff being laid off, and other internal matters do erode consumer confidence and burns bridges.
> VPN support was added in the last release. The public git repos show ongoing work to filesystem encryption.
Perhaps Russian government involvement is finally starting to pay off? They certainly couldn't have been bothered to add these things towards the beginning.
> I'm hopeful that one day SailfishOS will be fully open source.
Sure, with less than 0.1% of the market space, what do they have to lose. They've certainly lost a lot of other things though.
> Disagree. They hold fortnightly meetings
That wasn't always the case, certainly not the case in 2014/2015. Sailfish's lead SDK developer actually spent more time promoting his personal CMake alternative than his work on the Sailfish SDK.
Ubuntu Phone OS developers were always responsive to SDK issues, even when they didn't have the answer.
> It's infinitely more efficient to build and ship 1 VirtualBox OS Bundle, v.s. building and maintaining at least 3 different cross-compilation toolchains (one for each of: Windows, MacOSX, Linux). With limited developer resources, I'd choose the latter route too.
Do consumers really care about monopolies? I believe they don't and I think nowadays Android's reputation is not very good. People have a whole bunch of useless outdated android devices laying around, have some horrible experience with them and could appreciate an ungoogled/unappled linux-like distribution with more control for the user and updates.
I don't think this segment is very large. In fact I doubt most people care about the mechanisms of updates at all. The market of mobile is, as far as I can tell, basically a race to the bottom: consumers expect devices to be (relatively) disposable things, not worth expending too much effort worrying over. They want something that works well enough for their use that they can throw away and replace without being burdened by too much other context.
This dude is at a major disadvantage in absolutely every single way when it comes to access to economies of scale, access to vendor documentation, and sheer manpower, but is still managing to ship a device geeks are clamoring to buy.
I can't help but think one of the big players could serve those same geeks in a much more efficient (and profitable) manner, given their resources compared with what a community project can accomplish.
Similarly, any business model can't rely on handset sales. Apple and Samsung sell them by the millions and we're talking a few hundred here.
Community ROMS such as Lineage OS supporting (per wikipedia) 165 devices suggest that there is grass-roots support for tinkering. Devise a foolproof method for device support on any handset (Halium) and solve the app gap by containerizing Android (Anbox) and the users may follow - but on their own hardware, NOT a custom device.
UBports lives on by the community, for the community - in spite of Canonical abandoning the platform.
I'm saying that approach was never going to work, when even an established vendor like RIM couldn't chisel out a market with their revolutionary BB10 OS.
I think if they'd focused on being better than android, faster and more developer friendly, then they would have had a lot more luck.
It's the same with the GNU/linux desktop. In the overall user population only a tiny fraction of people care about "freedom" and most (including me) are happy to go with Windows or OS-X.
The fraction of people who care about this stuff is vanishingly small.
The truth is, there doesn't have to be conscious effort on the monopolist's side to arrive at a monopoly. If anything, markets tend to award and create monopolies.
Even if it did, the article cites "Mobile data was unreliable, [...] The location service was very unreliable." bodes extremely poorly for the device being usable for mapping services at all.
The GPS problem was with some phone models, not all.
Device trees aren't used on most mobile hardware. Mobile ARM is like the PS4 .. Intel arch chip, but totally not PC compatible.
I feel like Microsoft needs to give out the keys to their phones. Their platform is standardized enough devs could buy up old hardware and make a real oss mobile operating system without having to build totally different kernels per device.
I don't think you understood my comment.
I think this had a lot to do with the cancelling of Unity 8 as well.
Thinking back, I'm impressed with how far they got. If they had collaborated where it didn't help to compete, then I think they would've had a better chance of entering the market. I hope that this experience doesn't steel them against working on ambitious things entirely in the future.
'Community' seems to be a pretty nebulous ill defined term in this context used to prop up whatever argument the poster happens to be making.
If Ubuntu wants to invest in Mir how is that a bad thing, if Redhat invests in Systemd inspite of a multitude of other init options how is that a bad thing? This is usually how progress happens in the diverse and uncontrolled open source ecosystem and failures are part and parcel of this. Using words like 'NIH' seems misplaced here and sounds like some people want to 'control' what other people can do.
For instance who gets to decide what is NIH, given Ubuntu's Snappy is Fedora's Flatpak NIH? But there is no 'community' antagonism towards Flatpak. There appear to be some double standards at play here.
Snappy has higher memory requirements, takes up more disk space. Flatpak is implemented in about half as much code (granted with slightly different feature sets) despite being written in C rather than Go.
And despite these signals, I don't see any broad community "antagonism" towards Snappy at the moment. You can find an angry blog post on almost any topic, doesn't mean the opinions are popular. I don't feel any particular way about it since it seems to do something at least a little different than the competition. For example, Flatpak only really tries to sandbox desktop applications, much like .app directories on OS X.
It is a little suspect that Canonical always shows up with their own version of something which everyone else (SUSE, Arch, Red Hat, [Oracle/Novell]) mysteriously can't even manage to build and package successfully. In the case of Snappy, I think it's more or less a coincidence that it started within seven days of Flatpak. It might turn out to be better (or serve a completely different purpose). Another thing in favour of Snappy is that at least snapd and snap-confine (but not snapcraft!) are widely packaged for distributions other than Ubuntu.
The thing is, the rest of the industry is running on independent contributors. These independents manage to widely distribute and standardize on the best. Meanwhile, Canonical consistently goes off on their own and builds something that ultimately nobody can even package (Mir, AppArmor, Unity), let alone adopt.
Canonical clearly wants to differentiate, and that's entirely their right, but their differentiation factors often seem to wither and die after a couple years of bragging and some small progress.
If it wasn't for Ubuntu, even my travel netbook would run W10 nowadays.
The Snappy/Flatpak situation is different because each system has its own advantages and disadvantages and Snappy didn't come years after Flatpak.
What makes you so sure Mir would not have some advantages? It seems impossible to say either way. For all we know it could offer benefits and choice to the ecosystem. Or die because users would reject it.
Open source has always been about diversity and choice. There is now an unfortunate trend of some commentators misusing words like 'community' to push their own agendas or trying to pass off personal opinion as a widely held fact. This basically challenges open source diversity.
systemd was resented by some users, but for developers it had so many advantages (especially stuff like logind) that a huge part of them just started happily using it.
As for Mir, I cannot think of a single discussion on any communications channel ever where a Non-Canonical developer thought it was a good idea. The GNOME people wouldn't even look at it. The KDE people openly stated that they hated it (http://www.mail-archive.com/ubuntu-devel@lists.ubuntu.com/ms... and https://blog.martin-graesslin.com/blog/2013/05/mir-in-kubunt...). No Non-Canonical developer ever added support for it to any UI toolkit. For me, that's very, very close to 'one voice'.
What I would have done is to focus on apps first, staying on Android. Make worthy competitors for the built-in apps, like GMail.
Then, make it easier to write apps. Mobile app development is a baroque hell. Most apps nowadays are just lists, or maps, with a JSON backend. I don't want to deal with Adaptors and Fragments and Providers and what not for just that, when the app could be done 90% declaratively, and styled with a bit of CSS.
Why did they ditch all the work put into Maemo to make Gtk touch friendly years ago? Merge that stuff, or use modern Gtk, and let me write apps in Python+Gtk.
Then, once you have kick-ass apps, make a great rooting tool. Then, make a great android distribution (don't call it a ROM!). A vanilla android + your apps + a tool to extract drivers from the backup partition, so that it works on dozens of devices. Then add debian in a sub-tree. Then add apps to tie the linux world and the android world together (e.g. a Android terminal, maybe written in your "awesome" framework).
I think a piecemeal solution is the only realistic way to build an android competitor.
Sailfish still seems to be around for Sony's Open Devices, http://www.silicon.co.uk/mobility/smartphones/jolla-sailfish...
Can anyone comment on what the development story is like? It looks like it's just as complicated as android, but I want to be able to just write c++ code and a makefile in vim and not bother with QtCreator and especially all that qml rubbish.
Google is pretty clear that the NDK is only intended for writing games, high performance audio, or making native code available to Java.
I can. I've developed and released an app for SailfishOS, and am currently in the process of developing a second one.
I do all my app development in emacs, and VirtualBox (running an i486 version of SailfishOS). My app's written in Python. The UI parts are written in QML (basically JS). I have a Makefile that does an assortment of things for me (setup dev env, package application, clean up stuff).
My second app is going to be written in Python and Go, with the UI once again in QML.
It's real Linux underneath, so you can write your application any way you like (as long as it runs on Linux/arm). However, it's easiest to write the UI in QML, as it handles all the input/widgets for you.
And do you have the source and Makefiles available? I would really love to see that, and maybe even get going there. I am still in doubt if I should learn Qt or Python.
gPodder (https://openrepos.net/content/thp/gpodder) is perhaps the most popular SailfishOS app written in Python and QML.
You can find a lot of FOSS apps (developed in C++, Python, etc.) on OpenRepos (https://openrepos.net/).
> The phones were slow and had to be rebooted on a regular basis. The Meizu MX4 overheated. The battery indicator tended to show bogus data. Mobile data was unreliable, (national) roaming often didn’t work at all. The location service was very unreliable. The phone didn’t always ring when called, or you couldn’t make an outgoing call because the UI hid the buttons. The alarm didn’t work reliably. Bluetooth only supported audio devices, and later input devices, but not even basic file transfer. WiFi would not connect to WPA Enterprise networks until OTA-5. I think at one point the music player even started deleting files while indexing them. Et cetera.
I understand making an OS for a lot of different devices is hard. But this is just unacceptable regardless of the circumstances.
Jolla, the main developer of SailfishOS, is set to announce an official port of SailfishOS, to the Sony Xperia Z sometime this month (according to their blog)[2].
[1] https://wiki.merproject.org/wiki/Adaptations/libhybris_reboo... [2] https://jolla.com/wp-content/uploads/2017/02/Sony_Jolla_pres...
It turned out to be a completely separate ecosystem that started from scratch. So, there would be no actual advantage in having the Ubuntu name on it. It was just a marketing move, but it had nothing in common with the Ubuntu I know from the desktop
Whose time and resources?
> that would be good enough to challenge Android / IOS
That's a big assertion. What's the basis? Like, time-and-resources went into WebOS, into Windows Phone--what makes this so special?
https://www.theregister.co.uk/2016/12/07/russia_bid_mobile_s...
https://jolla.com/wp-content/uploads/2017/04/China_announcem...
What’s the corollary today? What need are Google and Apple underserving, and what company is large enough to mount a challenge to their duopoly?
Edit: To be fair I saw some phones from Microsoft on my carrier, but their battery life that was advertised was terrible, and there were few of them. If there had been 2 ~ 3 phones and new ones every few months, now we're talking... Ah well. I would prefer to see a Linux phone but I wouldn't mind buying a Windows one if they didn't feel like they could be abandoned like a couple of Microsoft's products wind up.
I never really understood this line of reasoning. Is there a reason why people can't opt to buy an unlocked mobile device online and just put their SIM in it [1]. That's what most people do for other types of hardware like desktops, laptops, and tablets.
[1] I'm not sure how this would work for devices on Verizon or Sprint (which is why I don't do business with them a opposed to AT&T or T-mobile).
But fair point, sheer size isn’t enough to disrupt a market, but it damn well helps. It’s also worth remembering that Apple had to grant AT&T exclusivity to get their way initially. That’s how powerful the carriers were.
Definitely just your opinion. Many people thought WP was a great OS.
It didn't work; third party developers saw that a Windows app could serve both the Windows and OS/2 markets and focused all their energy on their Windows app, usually not bothering to write an OS/2 version at all. The result was that Windows' big moat -- its application library -- actually got deeper. IBM's big plan to kill Windows ended up cementing its position as a dominant platform.
What makes or break a Mobile OS is the availability of the key apps for the market you're going after: whatsapp, FB, Twitter, etc. (that varies based on the region).
Was that ever released? I saw it on Mozilla employees' dev phones, but nowhere else.
You likely saw the other attempt using the J2ME-in-js implementation: https://github.com/mozilla/pluotsorbet
That was too slow and never shipped in commercial devices either.
MS is doing somewhat the IBM thing with their Linux for Windows. I've been curious to see if that would have the same result for them that it had for IBM.
Readers might be interested to know that the Ubuntu for phones [and tablets] project continues as UBports.
Their wiki[1] and latest blog post[2] might also be of interest.
If you check out the blog post you can see that they have been consulting with app developers and are working on a solution to the notifications issue - "To service notifications in the future while improving user privacy, we will implement “headless apps”. The OS will call these every few minutes and allow them to do some work in the background such as check for messages. This will be done with battery savings and user control in mind." There's a more detailed report on the meeting on the forum [3].
Finally HN readers might like to check out the Halium project - which aims "to standardize the middleware software used by various projects to talk with android daemons and make use of hardware". Some details on it's progress in [2].
1. https://wiki.ubports.com/wiki/Home
2. https://blog.ubports.com/qanda/2017/06/14/community-update.h...
3. https://forums.ubports.com/topic/273/june-1-2017-app-develop...
if we had a hackable open source and libre linux phone, even if the user base were 1 percent or .5%, we would likely start to see shifts in user interface and functionality design on the mainstream platforms-- besides, it'd be super rad to be able to actually use my phone for m0re than mindlessly scrolling 'feeds' and messaging.
as a cash-strapped third worlder constantly on the move in a mega-city, termux has been a huge relief for me and postmarketOS and other players looks promising.
i'd seriously be interesting in commercializing such a device to the raspbi/arduino/developr/hacker crowd. it's got lots of money, lots of clout, is clearly identified, growing and diversifying, and has been proven to spend money on interesting and useful tech. Any takers ?
The issue of apps will always be an issue. No matter what commmunity you go to, most people will probably want at least one of a number of popular apps that won't be on this OS. Some can be reverse engineered or use hidden APIs but not always. Examples being: Messenger, Whatsapp, Snapchat, most other messaging apps or video chat apps like Skype or Viber, Instagram (website doesn't have tagged photos of people or uploading), Pandora, Spotify, Netflix, Hulu, basically any tv sort of app, most dating apps like Tinder, Shazam, and any major mobile games.
Now I can finally ditch the mail app and read all my emails in Mutt ;)
I think this is utterly tragic for society. The only way out involves somehow coordinating enough people around rejecting the worst of this stuff (e.g. enough public will to demand that governments outlaw the worst lock-in and privacy-invasion practices etc.) I'm not hopeful.