I'd pay a lot of money for an actual open linux phone, but nobody wants to make one.
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.
(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.)
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.
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’s the corollary today? What need are Google and Apple underserving, and what company is large enough to mount a challenge to their duopoly?
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).(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.
* 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...
Would have dropped Android for something like Tails or OpenBSD for phones.
[1] granted Mir may have kicked Wayland development into gear
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.
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.
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.
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.
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 think if they'd focused on being better than android, faster and more developer friendly, then they would have had a lot more luck.
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.
The Snappy/Flatpak situation is different because each system has its own advantages and disadvantages and Snappy didn't come years after Flatpak.
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.
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.
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.
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.
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...
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.
> 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.
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
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...
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.